Anthropic's managed Code Review never approves or blocks a pull request. Its check run concludes as neutral or skipped, never as a failure, and the docs say you can merge without responding to a finding unless your repository's own rules require it.
So before you pick how Claude Code reviews your code, decide what the review should be able to stop. You have four paths: managed Code Review through the Claude GitHub App, the Claude Code GitHub Action, the /code-review command, and a local gate that runs your tests and saves a second engine's verdict under the commit before anything merges.
Everything below about the first three comes from Anthropic's docs as of 9 Nov 2026. The fourth is two-engines-gate, the free, MIT licensed version of how I make Claude Code and Codex check each other on my own projects.
The four paths side by side
| Managed Code Review | GitHub Action | /code-review |
Local gate | |
|---|---|---|---|---|
| Started by | Pull request activity or an @claude review comment |
@claude mentions, or a prompt on the GitHub events you configure |
You, on your branch | You, after each commit |
| Runs on | Anthropic infrastructure | Your own CI runners | Your Claude Code session | Your machine |
| Who can use it | Team and Enterprise, once an Owner turns it on | Anyone with a Claude API key or cloud provider credentials | Anyone, on any plan | Anyone with bash 4 or newer and git, plus the Claude Code and Codex CLIs for real reviews |
| Changes code | Read-only, and it doesn't push commits | Can implement changes and push commits | With --fix, through your permission mode |
The builder commits, and the reviewer runs read-only |
Managed Code Review leaves the merge to your team
In managed Code Review, several agents read each change, a verification step checks what they find, and the findings arrive as inline comments ranked by severity, with a summary and a check run named Claude Code Review. By default it looks for bugs that would break production and leaves formatting preferences and missing test coverage alone. It reads the diff and the surrounding code "without building or running your code", and it follows REVIEW.md from the base or default branch, never from the pull request's own changes.
You set how thorough it is with the review level (Quick, Standard or Deep), and in Anthropic's words "a more thorough review costs more". The costs page has the details.
A finished review doesn't fail a required check. To make a finding hold a merge, the docs describe reading the check-run details in your own CI and gating the merge there.
/code-review runs in your own session
/code-review finds bugs in your branch's changes from inside Claude Code, and it counts toward your plan's usage or API billing the same way the rest of the session does. With no target it reviews your branch's commits ahead of its upstream plus your uncommitted changes. You can also point it at a pull request or a path, and /review is an alias.
It follows your CLAUDE.md, including in a non-interactive -p run, and doesn't read REVIEW.md. Without --fix its instructions ask for a report only. With --fix they also ask it to apply the findings to your working tree, through your permission mode.
To review a pull request without managed Code Review or a workflow file, point /code-review at it and add --comment. The findings land on the pull request as inline comments.
The GitHub Action can push commits
The Claude Code GitHub Action runs Claude Code in your GitHub Actions workflows. Mention @claude in a pull request or issue comment and it can analyze code, implement changes and push commits. Managed Code Review never pushes, and the Action's own docs send you to Code Review for automatic reviews without a workflow file.
Setup is /install-github-app, or a manual install of the Claude GitHub App, a secret and a workflow file, and you need admin access to the repository. Its review workflow posts an inline comment on the pull request for each issue, or one summary comment when it finds none.
If you run the Action in interactive mode with its default @claude trigger phrase next to managed Code Review, an @claude review comment starts both. Set the Action's trigger_phrase input to a different phrase to keep them apart.
The local gate ties tests and a verdict to one commit
The local gate saves a test pass and a second engine's verdict under one commit hash, and refuses the merge without both. In the loop, Claude Code writes the code, commits each change on a branch and stops, and Codex reviews that commit read-only. Three scripts do the checking:
-
gate.shruns your test command on a clean checkout and writes.ai/tests/<sha>.passonly when the command passed, left the checkout unchanged and didn't report a run of zero tests. -
review.shsends the commits and the diff to the engine that didn't write them and saves the verdict as.ai/reviews/<sha12>.md, with aHead:line holding the full hash. -
merge-check.shrefuses unless the checkout is clean and HEAD has a pass record and an ACCEPT from a reviewer that isn't the builder. It never merges.
Codex reviews through codex exec -s read-only, so it can read files and can't write them. BUILDER=codex swaps the roles, and Claude Code then reviews with Read, Grep and Glob as its only tools.
These lines are from one run of the repo's demo, where a stand-in reviewer gives canned answers and no model is called:
merge-check: REFUSED: no test pass record for 2cef9bbe04c3; run gate.sh
gate: PASS on 2cef9bbe04c3, record .ai/tests/2cef9bbe04c3dd4727d2455e07c0ec420ecec7af.pass
merge-check: REFUSED: no review verdict for 2cef9bbe04c3; run review.sh
Verdict: CHANGES REQUIRED
- blocker, sum.sh:3: the loop starts at the second argument, so 'bash sum.sh 3 4' prints 4, not 7. test.sh only checks 'sum 0 4', where the bug cannot show.
merge-check: REFUSED: the verdict for 2cef9bbe04c3 is not a single ACCEPT
merge-check: REFUSED: no test pass record for 525000aeac20; run gate.sh
merge-check: OK: 525000aeac20 has a test pass and an ACCEPT from codex (builder claude)
The tests passed on a commit with a bug in it. The review asked for changes, and the fix commit started with no evidence, so it needed its own test pass and its own ACCEPT.
All three scripts also refuse a dirty checkout, because a test can pass on a file that isn't in the commit, and a reviewer can open a file that differs from the commit it judges:
gate: REFUSED: uncommitted changes, untracked files or flagged files (or git failed); commit, remove or unflag them first
Why the verdict is saved under the commit hash and why the gate refuses a dirty working tree go through each check.
What the gate doesn't do
- It doesn't make the code correct. A review can miss things, and tests only check what they test.
- It guards against merging the wrong commit and isn't a security boundary: anything with write access to the repository can write files under
.ai/. - It doesn't push, merge or talk to GitHub.
Should Claude Code and Codex review each other?
Managed Code Review chooses the Claude models it runs on, so a change Claude Code wrote gets reviewed by models from the same company. For my gate I picked a reviewer from a different company because it has different blind spots, and on one pull request the first Codex review came back with 2 blockers and 8 should-fix findings. merge-check.sh refuses a verdict whose reviewer is the same engine as the builder, so no engine approves its own commit. The prompt I send Codex is in how to make Codex review Claude Code's commits.
Which path fits
- You're on Team or Enterprise and want a review on every pull request without maintaining a workflow: managed Code Review, with the merge decision left to your team.
- You want a review of your branch before you push, on any plan:
/code-review. - You want Claude Code to answer
@claudecomments, implement changes and push commits from your CI: the GitHub Action. - You want the merge refused until the commit has its own test pass and an ACCEPT from the other engine: the local gate.
The local gate never talks to GitHub, so you can run it before the push and keep managed Code Review on the pull request.
Set up a local gate
Start with the free gate: clone two-engines-gate and run bash demo.sh. It calls no model and needs no account or network.
If you want the merge itself gated, the Two Engines Kit is the self-install path and the workflow I use on my own projects. On top of the free gate it adds merge-pr.sh, which refuses to call GitHub without a local pass record for the exact commit and tree, then pushes, opens the pull request, merges only if the head hasn't moved, and checks that the merged tree matches the tested one. With the review switch on (REQUIRE_REVIEW=1) it also refuses a commit without a saved ACCEPT. I added that switch after a night in October when I found four test-only commits that had never been reviewed, one of them already merged. The kit is built on information gathered since the first Codex and Claude CLIs.
If you'd rather have the loop configured for you, that's the Codex review setup. I set up Codex to review Claude Code's commits in up to three of your repositories, written from scratch for each one, with none of the kit's files. Your tests run before every merge, and with review enforcement on, a commit Codex rejects doesn't merge. The first review runs on one of your real branches, with a recorded walkthrough of the findings.
Top comments (0)