Using Codex as the Read-Only Reviewer for Claude Code
Not a benchmark: Claude Code writes and orchestrates, Codex reviews. The split, the verdict contract, and one case where the gate said no.
If you are weighing Codex vs Claude Code, my answer is to use Claude Code to write and Codex to review, and never let the author approve its own change. In my setup Claude Code plans, edits and dispatches work, and Codex is the independent reviewer that ends with VERDICT: PASS or VERDICT: FAIL. This is one observed workflow, not a benchmark: I did not measure speed, cost or capability.
What each one does in my setup
Claude Code is where the work happens. A session plans a slice, writes the brief, edits files, runs subagents, and dispatches a worker with a bounded task. It does not approve its own result, because the agent that wrote a change is the one most likely to believe it is done. The reasoning is in How I Review AI Changes in a Production Mobile App.
Codex is the other seat. I run it read-only, so it cannot edit the repo, and the prompt forces a verdict contract. The shape is simple:
Review this diff against the request. Check the evidence, not the summary.
Reasoning first, numbered. The final line must be exactly
VERDICT: PASS or VERDICT: FAIL.
No final line means no verdict, and a run that produced nothing is never read as a pass.
One case where the gate said no
A change to my ChatPing iOS app came back from the worker reporting 768 passing tests. Codex did not rerun them. It returned VERDICT: FAIL with two High findings:
1. Concurrent opens can mix chat identity and transcript.
2. Reopening a failed reply changes recency and rewrites the file.
Tests cover only a sequential open and a completed reply.
The count of passing tests was real. The right tests were missing. The fix took two more review rounds before the same reviewer passed it. The full account is in Don't Trust an Agent That Says the Tests Passed.
Choosing by seat, not by tool
I pick by what the task is.
| Situation | What I use | Why |
|---|---|---|
| Planning a slice, writing the brief | Claude Code | Holds repo context and sets the branch |
| Implementing a bounded change | A dispatched worker, never the reviewer | Follows an exact brief and reports with evidence |
| Judging whether the change is done | Codex, read-only | Did not write the code and ends with a binary verdict |
If one tool wrote the change, it should not be the one that signs it off. Which tool plays which seat is a choice; keeping the seats apart is the part that paid off for me.
Calling Codex without it hanging
I never call codex exec directly for a review: in my setup a bare call has hung indefinitely at about 0% CPU, which looks exactly like thinking. The review goes through a wrapper with a hard cap per attempt, 900 seconds by default. My wrapper also accepts image files, so Codex can look at a screenshot in the same call. When Codex is out of quota, the wrapper reruns the same prompt as a Claude Opus review and labels the output as a substitute gate; I treat that as a stand-in, not a Codex result.
Keep reading
- CLAUDE.md File: What to Put In It and What to Leave OutWhat a CLAUDE.md file costs, what the docs say belongs in it, and the size history of mine: 3,639 words, then 512, then 9,555.
- Claude Code vs Cursor: What I Measured Running Both as Coding WorkersNot an editor review: a dated tally of the log rows where I handed a bounded task to the Cursor CLI and to Claude Code, what finished, what did not, and what I did not measure.
- Claude Code Subagents: When One Beats Doing It InlineWhat a subagent is, how to define one, when to delegate and when to stay inline, and the brief I hand over.