Codex code review vs Claude Code /code-review: who can edit
Codex's /review reports findings without modifying your working tree, and codex exec runs in a read-only sandbox by default. Claude Code's /code-review asks the model for a report, and any edit it makes goes through your permission mode. In my review gate Claude Code writes the code, Codex reviews it read-only, and a script refuses the merge unless that exact commit has a test pass and a saved ACCEPT.
How a Codex code review runs
Codex reviews code from the CLI, from a script and on GitHub:
- In the CLI,
/reviewopens four presets: against a base branch (PR style), uncommitted changes, a commit, or custom review instructions. The docs say Codex "reports prioritized findings without modifying your working tree". - From a script,
codex reviewruns a code review non-interactively. You pick a single target,--uncommitted,--baseor--commit, or pass custom instructions as a prompt. - On GitHub, a pull request comment that mentions
@codex reviewasks for a review, and Codex posts it on the pull request. There it flags only P0 and P1 issues and follows the code review rules it finds inAGENTS.mdfiles.
My gate uses none of these three commands. It runs Codex in non-interactive mode with its own prompt on stdin:
codex exec -s read-only --color never --output-last-message <file> -
The - tells codex exec to read the prompt from stdin, and --output-last-message writes Codex's final message to a file. In the read-only sandbox Codex can inspect files but can't edit them. The prompt asks for an answer to every line of the task's definition of done and every house rule, then a single line: Verdict: ACCEPT or Verdict: CHANGES REQUIRED. The script reads the verdict from that file and nowhere else.
The full prompt, with the brief and the round rules that end the loop, is in how to use Codex to review Claude Code commits.
What Claude Code offers for code review
/code-review, with /review as an alias, works on any plan. With no target it reviews your branch's commits ahead of its upstream branch plus your uncommitted changes. It also takes a pull request number, a branch, a file path or a revision range. --fix applies the findings to your working tree, --comment posts them as inline comments on the pull request, and the review follows your CLAUDE.md.
Without --fix, the review's instructions ask for a report only. The docs add: "Either way, any edit goes through your permission mode."
Code Review is the managed service, for Team and Enterprise plans. Several agents read each change, a verification step checks the findings against the code, and they arrive as inline comments ranked by severity, with a summary and a check run named Claude Code Review. Someone with write access can start one by commenting @claude review on a pull request. It reads REVIEW.md and CLAUDE.md.
/code-review ultra sends the review to a fleet of reviewer agents in a cloud sandbox on Anthropic's infrastructure. It is a research preview and needs a claude.ai login.
Is there a Claude Code review mode?
No permission mode has that name. --permission-mode accepts default, acceptEdits, plan, auto, dontAsk and bypassPermissions. Plan mode comes closest: press Shift+Tab, or start with claude --permission-mode plan, and Claude Code reads files, runs shell commands to explore and writes a plan without editing your source.
How they differ
| Codex | Claude Code | |
|---|---|---|
| Review command | /review, four presets |
/code-review, alias /review |
| Edits during the review | none, /review leaves the working tree untouched and the read-only sandbox can't edit files |
report only by instruction, any edit goes through your permission mode, --fix applies the findings |
| From a script | codex review, or codex exec in a read-only sandbox |
/code-review follows CLAUDE.md in a -p run too |
| On GitHub | an @codex review comment, P0 and P1 issues only |
Code Review on Team and Enterprise, or /code-review --comment |
| Rule file it reads | AGENTS.md |
CLAUDE.md, plus REVIEW.md for Code Review |
Read-only by sandbox or by instruction
Claude Code's report-only review rests on an instruction to the model and on your permission mode. Issue #103536 in the Claude Code repository shows what an instruction alone can miss: while re-reviewing pull requests, the model edited a tracked file, CHANGELOG.md, on its own initiative. The issue's environment section says "Auto-approval allowed the Edit and Bash tools, so nothing stopped the write", and according to the issue the rules against editing were loaded every turn from CLAUDE.md and MEMORY.md.
My gate takes the tools away instead of asking. Codex gets the read-only sandbox. When Claude Code reviews (BUILDER=codex), review.sh starts it with --tools "Read,Grep,Glob" and names Edit, MultiEdit, Write, NotebookEdit and Bash in --disallowedTools, which removes those tools from its context. It can't run git either, so the script puts the commits and the full diff into the prompt. After the review, review.sh runs git status and stops with REVIEW VOID: files changed during the review if any file outside .ai/ changed.
Why Claude Code writes and Codex reviews in my gate
Writing is where context piles up: the plan, the briefs, the worktrees and the gate logs. Review needs much less, mostly the diff, the rules and what the change was meant to do. So Claude Code writes in its own git worktree, commits each change on a branch and stops.
I picked a reviewer from a different company because it has different blind spots. On one pull request the first Codex review came back with 2 blockers and 8 should-fix findings.
The gate checks the split too. merge-check.sh refuses a verdict whose reviewer is the same engine as the builder, so no engine approves its own commit. BUILDER=codex swaps the roles.
Where the verdict goes
Codex on GitHub posts its review on the pull request. Claude Code's Code Review leaves inline comments and a check run, and the docs say a review "never approves or blocks the pull request".
In my gate the verdict is a file the merge check reads. review.sh saves Codex's verdict as .ai/reviews/<first 12 characters of HEAD>.md, with a Head: line holding the full 40-character hash. merge-check.sh refuses unless the commit you are on has that saved ACCEPT and a test pass record named after the same commit. A crash, an empty answer or two Verdict lines leave no saved verdict. A new commit starts with no verdict, so every fix needs a new review and a new test run.
How my review gate saves the verdict under the commit hash goes through those checks line by line. The review and the tests also refuse a checkout with uncommitted or untracked files, because otherwise Codex can open a file that differs from the commit it judges. Why my review gate refuses a dirty working tree shows each case.
What this doesn't cover
A reviewer can mark a requirement met and be wrong, and tests only check what they test. The gate checks that the commit you are about to merge is the one that was reviewed and tested.
The kit
If you want a Codex verdict that can block the merge, the Two Engines Kit (v1.1.0) has these scripts ready to install. cross-review.sh runs the read-only Codex review and saves the verdict under the commit it reviewed, your own tests run on that same commit, and merge-pr.sh refuses to push without a pass record for it. With REQUIRE_REVIEW=1 it also refuses a commit without a saved ACCEPT, and it merges the same commit that was checked. One rulebook loads into both engines, the installer previews every change, and uninstall.sh restores your files byte for byte. $29 for the first 30 sales, then $39.
How many of these 10 review gate checks does your setup run?
Answer yes or no for the setup you use today. Each yes means your workflow has one of the checks I run before a merge on my own projects. Answer all 10 to see your score and the gaps.
0 of 10 answered
Answer every question to see your result.
This score counts your own answers. The checker doesn't read your code, run your scripts or audit your setup, and no score here is permission to ship. A local gate like mine guards against merging the wrong commit and isn't a security boundary: anything with write access to the repository can write the records it reads.
If you code with Claude Code and Codex, the Two Engines Kit (v1.1.0) is the workflow I use on my own projects, packed as readable Bash and Python that one script installs. Claude Code writes in its own git worktree, Codex reviews read-only and saves its verdict under the commit it reviewed, your own tests run on that same commit, and merge-pr.sh refuses a commit without a pass record for it. With REQUIRE_REVIEW=1 it also refuses one without a saved ACCEPT. $29 for the first 30 sales, then $39.
Get the Two Engines KitIf you'd rather have a review gate built for you, 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. $390, delivered in 7 days.
See the AI code review setupIf your team runs a SaaS or developer tool with an existing API and needs an MCP server over it, I build that as a separate job: $1,190 fixed, four to six read-only tools, deployed to your infrastructure. It closes none of the gaps above.
See the MCP server buildYour answers stay in this page and clear when you reload or leave it. The checker doesn't send or store them and adds no tracking of its own. The site's existing analytics are separate from this checker, and this note doesn't cover them.