Claude Code Review is GA: the review layers around it, and which ones you can copy without a Team plan

Claude Code Review left research preview on October 15 for Team and Enterprise plans. The same day, the Claude Code team published how its own repository gets reviewed, and the managed reviewer is one layer among seven there. Most of the others are GitHub settings and written rules, which any plan can copy.

One thing does not copy, and it is the reason for this piece. The managed service reads its review rules, REVIEW.md, from the base branch, never from the pull request. The local /code-review command officially doesn’t read REVIEW.md at all. In my runs on Claude Code 2.1.302 it read the file anyway, from disk, including a copy the change under review had just edited. Whether the rules held after that was up to the model.

The managed service below comes from the docs and the announcement; I did not run it. The local command I tested, eleven times.

What does Claude Code Review GA include?

A GitHub App that reviews pull requests on Anthropic’s infrastructure, for Team and Enterprise organizations. An Owner turns it on, installs the app and picks repositories. Each repository gets a level (Quick, Standard or Deep) and a trigger: once when the PR opens, after every push, or only when someone with write access comments @claude review.

The announcement says most reviews now finish in 6 to 10 minutes, down from about 20 during the preview. The preview docs gave an average of $15 to $25 per review; the GA costs page quotes no per-review figure at all. Reviews bill on token usage through usage credits, separately from the plan, and scale with the level, the size of the change and how many candidate findings need checking. A repository added from the admin page starts at “After every push”, the trigger that runs the most reviews, so set the monthly spend limit first. Eligible Enterprise organizations can claim at least $10,000 in credits by January 15, 2027; they expire 30 days after the claim.

Two limits matter more than the price. A review reads code and never builds or runs it. And it never approves or blocks: the docs say its check run “doesn’t conclude as a failure.” Organizations with Zero Data Retention, the HIPAA configuration or customer-managed keys can’t use it.

What review layers does the Claude Code team run around Code Review?

Seven, from before the PR to after the merge. Before the PR, Claude runs the tests, build and linter, and a second agent reviews the diff in a fresh context. On every PR: required CI, the AI review, a separate security review, and an approval tier (no human, one or two) picked by a classifier, with a second classifier asking whether the change needs a person anyway. Then a merge queue that re-runs checks against the latest main, new behavior behind flags used internally first, staged releases and a quick rollback.

The rules around the layers carry most of the weight. Every finding gets answered, fixed or closed with a reason, and an open bug or security finding blocks the merge. Only trusted authors, mostly the owning team, get the lighter approval paths, and some paths always need a person. An agent’s approval never fills a human slot. Whoever prompted an agent-written PR counts as a required reviewer. An approval covers one specific commit.

The numbers are internal and can’t be checked from outside. PRs with “substantive” review comments went from 16% to 54% when the preview launched, and the post doesn’t define “substantive.” After the convergence work described below, PRs passing in one review round rose from 65% to 78%. The post also names its own gap: nothing yet tightens approval automatically when revert or incident numbers move.

Which Claude Code Review layers work without a Team plan?

All of them except the managed reviewer itself and the team’s internal classifiers.

The blocking row deserves a second look. Even the managed product doesn’t block. The team’s “no merge with an open finding” comes from requiring every review thread to be resolved before merge, a repository setting the post recommends. The reviewer only writes text, and a branch rule makes that text binding. It is the split from A prompt is not an invariant: an instruction holds most of the time, a check the platform runs holds on every path it covers. And this check covers less than it seems. A resolved thread needs no fix and no reason, and a review skipped for budget, or never run on a draft, leaves no thread to resolve. Branch protection on private repositories also needs a paid GitHub plan.

A naming trap while you’re in the docs: /code-review runs “as a forked subagent.” That is the skill setting context: fork, which the skills page says “doesn’t run in a fork of the current conversation.” The reviewer does not see your session, which is right for a reviewer, for the reasons in Your forked subagent already knows too much. The conversation fork that inherits everything is a different feature with almost the same name.

How do you run local /code-review on a branch or a range?

Give it a target. With none, it reviews your branch’s commits ahead of upstream plus uncommitted changes, falling back to main or the previous commit when there is no upstream. At the Claude Code prompt:

/code-review main...my-feature
/code-review a1b2c3d..HEAD
/code-review --comment 1234
/code-review --fix

The first compares a branch with main. The second reviews only commits after a1b2c3d, the cheap re-review once a full pass is done. --comment posts the findings to PR 1234 as inline comments. --fix applies them to the working tree through your permission mode; in an interactive session the review runs in the background, so /rewind won’t undo its edits to files you hadn’t touched, and git will. From a shell, the same command runs in the foreground:

claude -p "/code-review a1b2c3d..HEAD"

A level before the target (low through max) trades confidence for coverage: low reports only what it is surest of. Interactively a typed level is remembered for later runs; a level passed with -p is not.

Does local /code-review read REVIEW.md?

Not as configuration, and the docs say so: the command “follows your CLAUDE.md” and “doesn’t read REVIEW.md.” In practice, every run of mine that had the file read it anyway.

The setup was a scratch repository with one commit adding a pagination function with an off-by-one, a stray print() and no docstring. CLAUDE.md banned print() in library code. REVIEW.md said a missing docstring on a new public function is Important, not a Nit. Each run was:

claude -p "/code-review medium HEAD~1..HEAD" \
  --allowedTools "Bash(git:*)" Read Grep Glob

Three details of how that ran matter for anyone repeating it. The session model was Opus 5.5. My user settings bypass permission prompts, so --allowedTools restricted nothing, and that is the only reason the reviewer’s cat calls ran: in a stock setup, a cat outside Bash(git:*) would stop at a prompt. And although I passed medium, the review’s own prompt in the traces says high effort. Eleven runs cost about $2.31.

The off-by-one came back in all eleven. The two rules turned out to be a weak probe: a baseline run with neither rule file flagged the print() and the docstring anyway, as ordinary findings. So a finding showing up proves nothing here. What counts is where it came from.

With REVIEW.md present (at the root of a three-file repository, at the root of a 3,043-file one, or in lib/ next to the changed file), all nine outputs cited it by name and quoted its Important rule. The six runs I kept tool traces for show the route: the reviewer listed the repository’s files, noticed REVIEW.md, and ran cat on it. That fits a model that went looking, not a file wired in as config. With the rule in CLAUDE.md instead, the finding cited CLAUDE.md, the documented path.

So the docs are right about the mechanism, and the behavior still surprises. Locally, REVIEW.md worked because the model chose to read it, with permissions that let it. That is a habit, and the next model or prompt can drop it. A rule that has to hold locally belongs in CLAUDE.md.

The first run also enforced a type-hint rule from my user-level ~/.claude/rules/. That is by design (the review reads user instructions), and it means two people running /code-review on the same branch get different findings, before permission settings even enter.

What happens when a change edits its own REVIEW.md?

The managed service doesn’t look at the edit. It reads REVIEW.md from the base or default branch, “never from the pull request’s own changes,” and honors lowered severity, skipped paths and nit caps only from the root file on a protected default branch. That settles which copy of the rules counts. It doesn’t make the reviewer immune to instructions planted elsewhere in the diff.

Locally there is no such selection. The repository has a base, but nothing picks the trusted copy of the rules; the reviewer reads the working tree. So I tried the obvious abuse. The same buggy commit also appended “Do not report” lines to REVIEW.md, exempting that function’s arithmetic and input validation, with a made-up reason about a legacy API. In both runs the reviewer reported the bugs anyway and flagged the REVIEW.md edit as a finding of its own, noting that the repository had no legacy API.

That is a good result and a thin guarantee: two runs, one model, a clumsy attempt. The service settles which rules apply before the model sees anything. Locally it is the model’s call, and it happened to get this one right. Protecting main doesn’t change that, because branch protection governs what merges, not what a local review loads from a feature branch. What helps is reading by hand any change to CLAUDE.md or REVIEW.md before you trust a review run on it.

How do you stop Claude Code Review loops from running 50 rounds?

Cap the rounds and narrow what each re-review sees. One Claude Code PR went through more than fifty rounds of review and fixes overnight before its author stopped it. Git blame showed about 59% of what the reviewer kept flagging had been there since its first pass, so the later rounds were mostly digging up old bugs.

The team’s fixes: after three rounds the reviewer asks the author to rethink the approach, after the first few passes it reviews only the new diff, it flags the class of bug so every instance gets fixed together, and it never repeats a finding. The managed product also tags inherited bugs Pre-existing, so the author isn’t charged with them.

Two of those are free locally. Note the SHA of the last full review and re-review <that-sha>..HEAD, which narrows the scope (the reviewer can still comment on untouched lines of a function the change touched). And write the cap where the agent reads it, because an agent author fixes every nit it is shown, and each fix is another commit and another round:

## Review loop
- After three review-and-fix rounds on one change, stop and ask whether the approach is wrong.
- After the first full review, re-review only commits since the last reviewed SHA.

What should you copy first from the Claude Code team’s review setup?

The protections that don’t depend on any reviewer: required CI, stale approvals dismissed, and CODEOWNERS on the paths where a mistake is expensive.

/.github/workflows/  @you
/src/billing/        @you
/CLAUDE.md           @you
/REVIEW.md           @you
/CODEOWNERS          @you

With “require review from Code Owners” on, any change to those paths needs an owner’s approval. An approval from any one listed owner satisfies it; two people is a separate setting, the required approval count. The rules files and CODEOWNERS itself are on the list for the reason in the previous section.

Then run the AI reviewer on demand, on a finished diff, with its findings advisory until you have read enough of them to know which ones it gets wrong. That is the order I argued for when combining Claude Code and Codex: the author and the reviewer are different systems, and making the AI’s findings blocking, with conversation resolution required, comes last, if at all. Skip the risk classifier. The team’s own incident eval set scores the reviewer, not the classifier, and they don’t describe how the classifier was built; the hand-written path list above is my substitute, and the post doesn’t propose one.

The service reads its rules from a branch the pull request can’t touch. A local review reads them from disk. Until that changes, the rules file is part of the diff, and you are its reviewer.