Set up Claude Code Review

The GA announcement is dated 15 October 2026. It applies to Team and Enterprise organizations. A personal paid plan alone does not qualify. The availability reference excludes organizations using Zero Data Retention, HIPAA configuration or customer-managed encryption keys. It includes GitHub Enterprise Server and GitHub Enterprise Cloud data residency, with their additional admin setup. Developers using another cloud provider still need an eligible Claude organization.

These are separate checks; being a GitHub maintainer does not grant Claude Owner access. Setup permissions · Comment permissions.

Use an approved repository and agree on a spend limit before the pilot. The official setup sequence is:

1. As the Claude Owner, open Admin settings → Claude Code → Code review and select Allow code review.
2. Connect the intended GitHub account. If the repository is missing, have the GitHub organization owner install the Claude GitHub App with access to that repository and finish linking the installation to Claude.
3. Select the repository, continue, and click Finish. Closing the dialog another way can leave repositories added while the service remains off.
4. Inspect Review runs immediately: a newly added repository normally starts at After every push. For a bounded pilot, our recommendation is Manual or Once after PR creation.
5. Set the review level below, then verify a permitted test PR. This is a procedure for your administrator, not an action performed by this guide.

Review the GitHub App permission list before approval. The app has broader permissions shared with other Claude features. The review itself reads code and posts PR feedback; it does not push code, build it or execute your test suite. Review access boundary.

The official levels express relative depth, speed and cost; they are not fixed dollar prices or separate selectable models. The use cases in the last column are our recommendations, not official guarantees. Review-level contract.

An Owner selects the organization's Review level and confirms Change level. For one repository, use its row's Edit → Review level; Default inherits the organization. The per-repository choice saves when selected and applies to reviews started afterward. There is no admin model selector. Where to configure depth.

Anthropic reports that most reviews at GA take 6–10 minutes, compared with roughly 20 minutes in preview. This is a vendor-reported overall comparison, not a per-level SLA or a promise for your PR. GA announcement.

Set Review runs on the repository row. Frequency is a second cost control, independent of depth. Trigger settings.

Automatic reviews skip drafts and forks. A human with write/maintain/admin permission can request a single review of an open PR, including those cases, using a new top-level comment beginning with:

@claude review

An edited comment, inline diff comment or bot comment does not qualify. On eligible non-draft, non-fork PRs, @claude review always also subscribes subsequent pushes; do not use it when you only want one billable review. A request for the same latest commit while a review is running does not start a second one. Comment rules and exceptions.

Look for Claude Code Review in the PR checks: queued, then in progress, then a completed result for the intended commit. An eyes reaction alone is insufficient. Inspect inline findings, the review summary and the check details. A completed no-findings result says Code review found no issues; a missing or failed result is not zero findings. Read the result.

The check does not itself fail a PR or approve a merge. A clean result is not proof of security or correctness. Our acceptance record would contain the repository, PR and commit, depth, trigger, check status, findings disposition, CI result and responsible human approver. Record actual values after a real pilot; none are fabricated here. Service behavior.

Use these focused checks if it does not work:

• Repository absent: verify connected account write access, app repository access and installation linkage.
• No check: confirm Allow code review is on, the repository is enabled, and the trigger/draft/fork conditions fit.
• Budget skip: inspect the PR message; check service cap, organization cap and credit balance before requesting anything again.
• Failed or timed out: read check details and the documented retry state before rerunning; interrupted sessions can receive one automatic retry.

Official troubleshooting.

Code Review consumes usage credits based on tokens, billed to the organization separately from included plan usage. There is no flat price per review. Depth, diff size, surrounding complexity and finding verification affect cost. A developer's manual request still bills the organization. Billing basis.

Set the service's monthly limit in Admin settings → Usage. Reviews can be skipped for a service cap, organization cap, exhausted credits, or too little remaining budget for the expected next review. Start with one repository and inspect actual average cost before widening coverage. The analytics view is at Analytics → Code review; estimates before discounts or credits can differ from the invoice. Limits and usage.

The GA promotion says eligible Enterprise organizations can claim at least US$10,000 in Code Review credits by 15 January 2027, expiring 30 days after claim, with terms. It is not automatic free usage for every Team or Enterprise account. Confirm eligibility and terms in your organization before relying on it. Promotion source.

Choose the execution path before copying a setup recipe:

Current /review is an alias of /code-review; before v2.1.223 it was a different single-pass PR command. It does not enable this managed organization service. Local command reference · GitHub Actions.

Anthropic's 15 October engineering article describes about 90% of Claude Code's own code being written by Claude. That is a specific internal statistic, not an efficiency forecast for other teams.

For a small pilot, turn the method into a reviewable record:

1. State the changed behavior, tests run, remaining risk and rollback in the PR. Classify risk from the change, not who wrote it.
2. Give independent reviewers a narrow question and request a file/line, concrete failure path and verification evidence for each finding. Reproduce or reject findings before editing.
3. Keep CI and runtime checks separate from managed Review, which does not execute the code. Recheck the relevant behavior after a fix.
4. Keep authentication, billing, release/CI controls and installers under explicit human approval using existing ownership and branch rules.
5. Bound review rounds; focus follow-ups on the new diff. Preserve a rollback and use incidents to improve the checks.

These are editorial pilot steps informed by that article. Maintain shared review expectations in REVIEW.md / CLAUDE.md; the review instructions are read from trusted base/default branches rather than a PR's proposed REVIEW.md changes. A bot finding or approval never replaces your required human decision.