Let Claude Code write, and Codex check it

After Anthropic’s recent moves – higher prices, hard-trimmed limits – a question I keep hearing more and more comes back: “Codex or Claude Code?”. And to me it’s the wrong question. Because you can have both. More than that – they complement each other beautifully, the moment you stop thinking of them as competitors.

OpenAI made an interesting move: instead of fighting Claude Code with knives out, it shipped an official plugin that wires Codex right into Claude Code (open repo openai/codex-plugin-cc on GitHub, already past 25k stars as I write this). It sounds odd – OpenAI building a tool that makes a competitor’s product better. But it’s the same move you see across the whole industry: the AI war stopped being about building walls and started being about being everywhere. If you can’t beat them, join them – OpenAI would rather you use Codex even while you’re sitting inside Claude Code than not use it at all.

And for you it boils down to something simple: one console, two brains. Claude writes – because it’s great at writing code. And Codex does the thing where it actually pays to have someone from the outside: it checks, audits, points at holes. A second pair of eyes, except they’re the eyes of a different model. And this isn’t only a coding thing – in general, if you hand the same query to different tools, you often get slightly different results, and that difference is exactly what you want here.

Why this makes sense at all (and this is the crux)

The most important thing in this whole game isn’t technical, it’s common sense: review by the same model that wrote the code is weak. Anthropic puts it dryly in their Claude Code best practices: “a fresh context improves code review since Claude won’t be biased toward code it just wrote.” I’d put it less politely: Claude, checking its own code, treats it like its own – “well, I wrote it myself, so it’s fine” – and quietly skips over things.

That’s not a flaw in Claude. It’s a flaw the model inherited from us during training. Anyone who’s ever done a code review of their own code two days later knows you catch more then than you do “in the heat of the moment” – because you stop being the author and become a reader. A different model does exactly that: it looks without any emotional attachment to how “cleverly I came up with this.”

I see this from the Refio side and the benchmark I run. Different models have different strengths – I push them through the same tasks and I see that where one consistently passes, another falls apart, and vice versa. Two models looking at the same code isn’t redundancy. It’s two different bug readers. (I wrote separately about how far “same task, different approaches” can drift apart – back when I benchmarked small models.)

What you get in the plugin

Three commands that do the work (I’m describing the plugin version I ran myself – 1.0.4):

• /codex review – a calm, neutral pass. Read-only, doesn’t touch the code, looks at your current changes (you can point it at a branch) and tells you what it thinks. It reads every line outside Claude Code and returns the result split into critical / warning / information plus a short summary. Simplest way to put it: like hiring a senior dev for thirty seconds to look at the code with fresh eyes.
• /codex adversarial-review – and this is the interesting one. Codex doesn’t so much check as attack your design decisions. It doesn’t ask “does it work”, it asks what you didn’t foresee: auth, data loss, rollback, race conditions, version mismatches, no observability. Classic example: you assume a webhook or an API response arrives on time, and that once the button is clicked everything just works right away – but what if it doesn’t arrive? That’s exactly the kind of thing that blows up at 2 a.m., with your biggest client onboard. Result split by severity. You can also point it at something specific – “focus on caching” or “on user logging.” It works more like a devil’s advocate – a trick I use a lot when working with agents: I make them tear down what’s been built and really pick it apart.
• /codex rescue – you delegate the whole task to Codex and keep working, because it runs in the background. Handy when Claude gets stuck and spins in circles, or – quite prosaically – when you want to save Claude’s limits and offload the work to Codex. Importantly, rescue can take a previous adversarial review’s result as context, so it doesn’t start from scratch. What you get out isn’t “there’s a problem somewhere”, it’s a concrete root cause: file, lines, and a proposed fix.

On top of that, commands to manage what’s running in the background: codex status (where is it), codex result (grab the output), codex cancel. And a practical detail that changes how you work: you can stop Claude while the Codex process keeps grinding in the background – so you genuinely have two agents working in parallel on one codebase, while you keep building.

Where you can see it in practice

Plain review behaved like a calm reviewer. It flagged two things, both about loading existing projects – with file and line numbers, not generalities:

• renumbering the enum breaks saved SDF scenes, because the serializer reads the raw operation number from the JSON. The old value (in my case SMIN was number 41) loads as a completely different operation after renumbering. So old projects quietly drift out of alignment.
• a shared shader (several effects pointing at the same source) gets wrapped multiple times – the second effect wraps an already-wrapped shader and produces invalid source.

That was already valuable. But then I ran adversarial-review on the same code – and this is where it got interesting. Verdict: needs-attention, no-ship. It caught the same thing review did (the SDF renumbering, this time with a ready recommendation: add a migration for old opcodes and a test that loads the old values), but it threw in something plain review never even touched:

The export path drops the effect’s inputs. A shader that samples the uChan0 channel renders fine in the editor preview – because the editor passes inputs. But the exporter calls the same function without inputs, so the exported build has no sampler declaration. Result: looks great in the editor, but in the final demo the shader either won’t compile or comes out as a black screen.

And that’s the whole point of adversarial review: it doesn’t check whether the code does what it was meant to. It checks what can go wrong when nobody’s watching. Review asks “is this code consistent.” Adversarial asks “what happens when I ship it” – and it found a preview-versus-export mismatch, a bug that doesn’t fire on my machine, only on someone who runs the finished build.

Honestly, so this doesn’t read like a puff piece: in my case these were mostly things I already knew about, because they surface during testing anyway – the “why isn’t this working” kind. But that actually says something. First: the tool doesn’t make things up and doesn’t spray false alarms, it hits real spots with line numbers. Second: if on code that’s foreign to it – because the models had never seen this code before – it caught exactly what the author already knows, then on code the author doesn’t remember by heart it has a real shot at catching what the author doesn’t see.

Setup in a nutshell

The whole install is literally two minutes. You need: Node.js, Claude Code installed, and a ChatGPT account. Then: add the OpenAI marketplace, install the plugin (global scope recommended – available across all projects), reload via /reload-plugins, run codex setup to check whether anything’s missing (usually it’s the login). You do the login in a separate, clean terminal, without Claude – codex login opens authorization through your ChatGPT subscription, you click through and that’s it. The plugin repo (openai/codex-plugin-cc) is open – you can peek at how these commands work under the hood, what the prompts look like, and the rescue agent itself.

One honest note on cost: the plugin itself is free, but it burns your ChatGPT limit. For a calm review, a free account or Plus for 20 bucks is plenty. But if you want to lean on adversarial-review over a bigger codebase, 20 dollars can run short – it’s a command that eats noticeably more.

What the author meant to say…

I buy the concept in full, because it’s exactly what I do on the Refio benchmark: I test how different models behave, and sometimes you can see they act alike.

Two concrete upsides I see:

1. A second pair of eyes from a different model – it catches bugs Claude won’t spot in its own code, because it counts it as its own.
2. Saving limits – by delegating part of the work to Codex, you don’t burn Claude’s tokens. After the recent limit cuts, that’s not a trivial argument.

After actually using it, my takeaway is this: review is a quick, calm check, and adversarial-review is the one I reach for before sending something out. That second mode found me a mismatch that wouldn’t have blown up on my machine, only on someone with a finished build – and that’s exactly the species of bug that costs the most. It stays wired in – I use it surgically, on specific changes, not as a permanent sieve over every commit.

Before you wire this into a company project – where your data goes

And here’s one thing the enthusiastic videos usually skip, and it matters. Normally, working in Claude Code, your code goes to Anthropic. Once you wire in Codex, the same code additionally goes to OpenAI – because it’s their model reading it. For my demo engine after hours, that’s no problem at all. But in a company or client project it’s no longer a technical decision, it’s a data policy question – and it depends on the specific company. Before you run review on someone else’s code, check whether the contract and the policy even allow sending it to a second provider. Convenience is convenience, but data is data – worth keeping in mind.