Codex reviews my Claude Code work. Its most useful catches come before any code exists.

TLDR; Between late June and 20 October I ran about 160 Codex cross-checks inside a Claude Code workflow. Codex found real defects in four places: plans and specs before any code existed, security fix loops, code that changes state, and prose checked against its source. It caught a client-approval bug a Claude reviewer had passed, and seven errors in two published guides after my editor had approved them. As a second security reviewer on code Claude had already checked, it mostly agreed with Claude.

Every agent in my Claude Code setup is a Claude model. The planner, the implementer, the code reviewer, the security auditor and the editor all come from one family. I suspected they share its blind spots, so a Claude reviewer reading Claude’s code would miss the mistakes that family tends to make.

So since late June I have sent some of that work to Codex, OpenAI’s coding agent, through its plugin for Claude Code. On 18 October I wrote it into my workflow rules as a required step for every new feature’s plan, every spec before it becomes tasks, and every complex or security-sensitive diff (a diff is the set of changes a piece of work makes to the code). The rule is days old, so nearly all the runs below predate it. The workflow around those rules is the tech-lead pattern. This week I went back through the records to see whether Codex had earned its place in them.

What I counted

No single source holds every run. Codex keeps session logs on each of my two Macs: 127 review sessions between late June and 20 October. About 30 more, code reviews from late June and early July, survive only in my written records: the review files, specs and commit messages that say what Codex found and what happened next. That makes roughly 160. I graded every logged session against the written record: about 870 findings, each traced to a fix, a rejection or nothing at all. About one in ten I could not trace, mostly early runs whose files were never committed. The table counts something coarser: events in the written record, June to October, where one event (a spec, a review round) can span several sessions. It totals 93.

This is a tally of working records. I ran no controlled test. A finding counts as unique to Codex only where a record says a Claude reviewer missed it. Most records don’t say either way, so read the numbers as a floor.

Where it pays

Plans and specs, before any code exists

The highest value per run of anything in the tally. A red-team, where a reviewer’s only job is to attack a plan, takes Codex under eight minutes. It reads the plan, opens the code the plan touches, and argues with it.

Three examples:

• A consumer app’s approved spec synced a guest’s saved data into their account on sign-in. On a shared computer that merges one person’s data into another’s account. Codex flagged it; I chose a confirmation step, and it shipped with one.
• A client-approval portal’s plan marked a request as sent before the email was queued. If the queue went down, the portal would say sent and nobody would get an email. The fix went into two of the build tasks.
• A content tool’s spec tied approval to the item, not the version. An unapproved later version would have published on an earlier version’s approval.

Across twelve plan red-teams I graded closely, I accepted 139 of 144 traceable findings, and about 60% of those have since been built. That rate flatters Codex a little, for two reasons. No Claude reviewer reads my plans at that stage, so anything Codex finds there is unique by construction. And as the section on my side of the loop shows, “went into the spec” often meant nobody checked the finding against the code first. Even so, the catches were the expensive kind: a schema, an auth rule or a state machine is cheap to change on paper and dear to change after launch.

The red-team doesn’t replace the code review that follows. On several features, a Claude review of each task then caught bugs in how the accepted fixes were built.

Security fix loops

My git guard is a hook that stops agents committing to main or skipping checks. In October I hardened it over five rounds, and Codex reviewed each one. Across the first four rounds it found 17 ways past the guard and one crash. Several were new holes opened by the previous round’s fixes. The fifth round found nothing in the change under review.

Each fix came from the agent that wrote the code, and it kept opening the same class of hole. About half of those holes were Codex’s alone: no Claude reviewer found them.

Code that changes state: publishing, approvals, locks

Codex’s unique code findings cluster where data changes hands. In the code reviews where a Claude reviewer had already run, Codex added a new medium-or-higher finding in five of six, every one in lifecycle, locking, race or migration code. On a CMS engine, a Claude review at its second-highest effort setting reported no high or medium findings. Codex’s first pass rated one HIGH: the publish check read values that had not been saved yet, so a page could publish without a required field.

On the approval portal, a card left open on an old revision would record the client’s decision against the newer one. The security auditor’s own note says: “Codex found it; Claude missed it on the first pass.”

Prose checked against its source

Two guides on this site, on hook rules and local transcription, passed my editor. Codex then checked them against the code they describe and found seven errors: wrong command names, wrong behaviour for two commands, a determinism claim the code did not support. All seven were real and are now fixed. Codex now checks every guide against its source as the last step of my content pass.

A training provider’s course page called one qualification “the only route” into counselling. The provider’s own catalogue listed a second route, and the fact-checker and editor had both passed the page. Given the catalogue to check against, Codex found the second route.

Run as the last gate, Codex mostly caught sentences my Claude editor had added after the fact-check: a claim of “broad support across governments” here, a promise about what employers ask for there. Nobody had checked those sentences, because the fact-check had already passed.

Where it pays less

A second security reviewer on the same code

The approval portal had eight security reviews where Codex ran alongside the Claude auditor. Two found defects the auditor had missed: the stale card above, and three race conditions in one review, two of which overturned a Claude reviewer’s written verdict that the code was safe. In the other six Codex confirmed what the auditor found, and often rated a finding one step more severe than Claude did.

So the payoff on this kind of review is lumpy. Six runs added a second opinion on severity and little else. The other two stopped a client’s approval landing on text they had never seen. At two or three minutes a run, I keep it on code that touches state, auth or money, and I expect it to agree with Claude most of the time.

Style and large content batches

On one product’s website I rejected 7 of 11 Codex findings on the first batch of pages and 13 of 15 on the next, each against the code or a source. When the prompt didn’t spell out the house rules, it flagged decisions I had already made. On my own guides it got facts wrong three times: its token maths ignored the time spent reading the prompt, it contradicted the documentation on a keyboard shortcut, and it called two price ratios unsourced when the published prices settle them. The most useful findings I kept were factual corrections. I kept some style edits too, a handful per batch.

The pattern across the content reviews was access. When Codex could read the source of truth (a course catalogue, the app’s code, a statute), its findings mostly held. Most of the content findings I could show were wrong came where the source sat outside its view: copy pasted into the prompt, or a reference it never received. The rest were misreadings of code it had been given. A research check with no network access went worse. Codex called four claims false: two were true, two were false for reasons other than the ones it gave, and it missed the two real errors.

Stuck bugs

One bug, two sessions: a window in a Mac app that kept growing. Codex made two predictions about the cause and both were wrong. Undoing changes in halves until the bug disappeared found it. One case proves little, but I have stopped asking Codex to debug.

Reliability

Until mid-September my agents reached Codex through a connector that hung, then stopped connecting after a Codex update. Usage limits and an out-of-date install blocked other runs. The plugin’s own runner has been steady since, but the workflow still needs a fallback for when Codex isn’t there.

The weak link was my side

The failures were in what happened to Codex’s findings.

On one batch of four specs, 23 of 55 findings were checked against the code before they went into the spec. The other 32 went in on Codex’s word, marked as plausible. In the twelve red-teams above, 41 of the 139 accepted findings have any recorded check. Several accepted specs are still plans with no code, so nobody can yet say whether their findings were right.

Some findings never arrived. On one project the connector hung and about ten security findings never reached Claude. Across the graded sessions, about one finding in ten has no record of what happened to it.

The records also flatter Codex’s approval. Six content reviews ended with Codex still asking for changes, and the state file logged each one as a pass. On one spec, the agent wrote that it had checked every finding against the code; the transcript shows it opened no code between Codex’s answer and its edits.

A second reviewer adds value only if every finding gets a disposition: fixed, with the commit, or rejected, with the reason. Those dispositions have to be written down where the next agent will see them.

How to set up the Codex plugin in Claude Code

The plugin is OpenAI’s, and its README covers installation. Inside Claude Code:

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

It needs Node 18.18 or later and a ChatGPT plan or an OpenAI API key. Every run counts against your Codex limits. You get /codex:review for a standard read-only review, /codex:adversarial-review for one you can point at a risk, and a rescue agent that can delegate work to Codex.

Installing it takes five minutes. The judgement calls take longer. These are mine:

1. Require it where your own reviewers can’t see. Plans before approval, specs before they become tasks, and diffs that touch state, auth or money. Leave it off naming, style and anything a search answers.
2. Keep it read-only. A reviewer should report, and the author should change the code. The two review commands are read-only; the rescue agent writes by default, so don’t use it for reviews.
3. Give it the intent and the source. Without the acceptance criteria, Codex can’t tell a defect from a decision, and without the source of truth it guesses. Paste what isn’t in the repo (the spec, the settled choices, the house rules) and give it a path to what is (the diff, the files, the catalogue or data the copy rests on).
4. Ask for the verdict first, then findings ranked by severity, each marked CONFIRMED (backed by a cited line in the code or source) or PLAUSIBLE (reasoned, with no line to cite). Tell it to say so when it can’t break the design, so it doesn’t invent weak findings.
5. Pin the model and the effort. Without them Codex picks its own defaults, which may not be the settings you want for a review.
6. Write down a disposition for every finding. Check each one against the code or source yourself before you act on it, CONFIRMED ones included, then record it as fixed (with the commit) or rejected (with the reason).
7. Re-verify after the fixes. A second run on the fixed text costs little. Two of those re-runs each found one new issue.

One warning from the README: the optional review gate runs Codex every time Claude stops, and it can loop and drain your limits fast. I don’t use it. I’d rather run Codex at the points listed above than at every stop.

The routing for the Claude side is in the model selection guide, and the review gates Codex plugs into are in quality gates. If you are deciding where a second model fits in your own team’s workflow, discuss a related problem.