Make yourself
at home.

01 / CONNECT

Choose which repositories to review.

1. Open the customer workspace and sign in with GitHub.
2. Select Add repositories, then choose the GitHub account or organization that owns your repository.
3. Grant the CodLab GitHub App access only to the repositories you want reviewed.
4. Return to the workspace and select Sync from GitHub.

Repository access remains controlled by GitHub. Start with a repository your team is authorized to connect.

02 / REVIEW

Follow the change through to evidence.

1. Open or reopen a non-draft pull request, mark it ready for review, or push a new commit in a connected repository. Editing the title or description does not trigger a review.
2. Wait for the codlab-ai[bot] comment and the CodeCR Review check.
3. Read the decision, finding locations, evidence, and suggested actions. The summary comment is updated as reviews complete.
4. In the customer workspace, select View evidence for the review record, or follow the check’s evidence link.
5. Resolve findings, check the new result, and obtain the human approvals required by your team.

A passing automated review is not proof that a change is safe. Consider its scope and limitations alongside tests and human review.

03 / DECIDE

Understand what the result means.

The current GitHub integration returns a failing check only for deterministic BLOCKING findings. Advisory AI findings and a REVIEW result do not by themselves fail the CodLab check. GitHub prevents merging only when your branch rules require that check and it is not bypassed. Configure required human reviews separately.

AI findings remain advisory evidence for reviewers. Inspect separate rule, AI and context coverage; malformed or unavailable analysis cannot establish a clean change. CodLab does not grant human approval or override repository permissions.

FIX / APPROVAL FIRST

Inspect the patch before publishing.

1. Open a completed review and choose Fix in CodLab. Select findings, docstrings, tests, or failing CI as the goal.
2. Inspect every proposed file change. Generation does not run repository commands or tests. Cancel while the proposal is queued or generating.
3. As a current workspace owner or administrator with repository access, explicitly approve the displayed patch. Your organization may require two distinct approvers.
4. Choose a commit to the current branch or a new draft pull request. Approval is bound to the patch hash and reviewed commit.
5. Validate the new revision with your CI and human review. Recent approval, cancellation, and publication receipts are visible to authorized administrators in workspace audit history.

If publication reporting fails, GitHub may already contain the approved commit. Check GitHub before starting a second fix.

SECURITY / IMPACT

Understand the scope of the finding.

Security sections label observations, inferences, and proposed hardening. Blast-radius analysis includes supplied changed paths and bounded static JS/TS imports, callers, aliases, re-exports and relevant tests at the reviewed commit. Select a file to inspect its source relationships. It does not establish a complete dependency graph, runtime permissions or production deployment reach.

Skipped or unavailable checks never count as passes. An evidence score measures available context, not merge safety. Explore a synthetic sample report.

04 / SCOPE

Keep review policy in trusted code.

Repository owners can use .codecr.yml to configure the review file limit, minimum reported severity, and ignored paths. The GitHub App considers the first 100 changed-file entries and applies a configured limit of 30 files by default, up to 100.

Reviews analyze bounded patches, not the full codebase: up to 20,000 characters per available patch, and up to 60,000 combined patch characters for the AI pass. Ignored files and files without a patch are outside the analyzed scope.

Policy is loaded from the trusted immutable pull-request base. A proposed policy change does not weaken the policy used to review itself.

The public review tool has a separate limit of 30 files and accepts public GitHub pull-request URLs. Use the connected workspace for repositories authorized through the GitHub App.

05 / ACCESS

Adjust the installation when your scope changes.

Select Add repositories in the workspace to change the GitHub App’s repository access. Then sign in again or choose Sync from GitHub to refresh the workspace.

For missing repositories or a review that needs attention, follow the support guide. Include the evidence ID and approximate time when using your agreed support channel.

06 / SECURITY & DATA

Know what the review processes.

• Automated reviews use short-lived GitHub installation tokens.
• CodLab does not persist GitHub user access tokens.
• Only a hash of each random session identifier is retained.
• When AI review is enabled, bounded source patches are processed by Cloudflare Workers AI. Supporting helper, guard and test excerpts require a separate current owner/admin repository opt-in and an enabled operator gate; the default does not share this supporting context.
• Raw patch payloads are not stored in the customer database. Review metadata and findings are retained; finding text may include source excerpts.

See Security for the published security model. The hosted data map distinguishes raw patches processed for review, retained finding excerpts and structured reports, and temporary old/proposed fix content. Proposal expiry and administrator preview-and-apply retention have different scopes. The optional pilot notice covers its separate contact and email workflow.