Running Codex inside Claude Code

Claude writes the code, then Claude reviews the code, then Claude tells me it looks good. That loop always sat a little wrong with me. A model reviewing its own work grades on the same instincts it wrote with, so it waves through the exact assumptions it baked in. The bug and the sign-off come from the same place, which is why the sign-off keeps missing the bug.

The fix I have settled on is to put a second model from a different family in the loop, and to do it without leaving Claude Code. OpenAI ships a plugin, codex-plugin-cc, that lets Claude hand work to Codex, your own local install of it, for a review or a fix, then hand the result back. I run it on a Claude Max plan plus a ChatGPT Plus subscription, which is two separate quotas doing two different jobs. Here is how it fits together and whether it earns the setup.

Why bother running a second model

This has nothing to do with Codex being smarter than Claude. On any given change either one might catch more, and which one wins flips by the task. What earns the setup is that the two fail in different places.

Claude and Codex were built by different labs on different data, so their weak spots do not line up. When Claude reviews its own diff it re-derives the same reasoning that produced the bug, recognizes it as normal, and moves on. A model from another family has no such memory of writing it. It has to trace the logic from scratch, and that is where it stumbles onto the thing Claude glossed over. The overlap between what the two flag is smaller than you would guess, and the non-overlapping half is the part worth reading.

There is a second, more boring reason, and on my plan it matters as much: Codex runs on my ChatGPT usage, not my Claude usage. Delegating a chunky review or a stubborn fix to Codex spends the OpenAI quota and leaves the Claude quota for the work I want Opus doing. Two subscriptions, two limits, and the plugin lets me choose which one to draw down.

Getting Codex into Claude Code

The plugin does not bundle its own copy of Codex. It drives the codex binary already on your machine, with the same login, the same config.toml, the same sandbox and AGENTS.md you would get running Codex on its own. So the prerequisites are Codex itself (Node.js 18.18 or later, and a ChatGPT subscription or an OpenAI API key) and then the plugin on top.

Inside a Claude Code session:

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

/codex:setup checks whether Codex is installed and logged in. If Codex is missing and you have npm, it offers to install it (npm install -g @openai/codex). If it is installed but not signed in, run !codex login (the ! runs it in your shell from the prompt). When it is done you will have the /codex:* commands and a codex:codex-rescue subagent in /agents.

One step the setup will not do for you: pick your model. As of July 2026 Codex runs the GPT-5.6 family, which comes in three tiers, gpt-5.6-sol (the flagship for hard problems), gpt-5.6-terra (the everyday default, and the natural replacement for anything you used to give 5.5), and gpt-5.6-luna (fast and cheap). On a Plus plan you can select any of the three. The plugin reads whatever your Codex config points at, so set it once in ~/.codex/config.toml:

model = "gpt-5.6-terra"
model_reasoning_effort = "medium"

If your config still says gpt-5.5, that is why Codex has not moved on its own. A pinned model does not auto-upgrade; you name the new one. Terra is the right default to leave there, and I reach for Sol only on the changes that deserve it.

The commands you'll actually use

There are more /codex:* commands than you need day to day. Three carry the weight.

• /codex:review runs a normal, read-only Codex review of your current changes. It reviews the working tree by default, or a branch against a base with --base main. It is deliberately not steerable, no custom focus text, a solid second pass looking for bugs, edge cases, and missing tests. Multi-file reviews take a while, so run it with --background and check back with /codex:status and /codex:result.
• /codex:adversarial-review is the steerable one. It challenges the design rather than only hunting defects: the assumptions the change depends on, the tradeoff you made, where it falls apart under real load. Unlike the plain review it takes free-text focus after the flags, which is the whole point. Save it for the changes that scare you.

/codex:adversarial-review --base main challenge whether this caching and retry design is right

• /codex:rescue is the only command that writes. It hands a bounded task to the codex:codex-rescue subagent to investigate a bug, try a fix, or continue a previous Codex thread. It is also the only command that takes --model and --effort per call, so this is where you escalate on purpose. spark is a shorthand for a fast, cheap pass (gpt-5.3-codex-spark).

/codex:rescue investigate why the auth tests started failing
/codex:rescue --model gpt-5.6-sol --effort high --background redesign the retry logic to be idempotent
/codex:rescue --model spark fix the lint errors

The asymmetry trips people up, so state it plainly: the two review commands do not take --model or --effort. They inherit whatever is in your config.toml. Only /codex:rescue is steerable per call. If you want your reviews on a heavier model than your default, pin one with review_model in the config rather than reaching for a flag that the review commands quietly ignore.

The workflow

None of these commands are the workflow on their own. The loop is what makes it pay off.

I plan and write with Claude as usual, Opus 4.8 for the everyday work and Fable 5 when a task is long and architectural. When a change is ready, before it becomes a commit, I kick off /codex:review --background and keep working. When it lands I read Codex's findings against what Claude already told me, and I only care about the disagreements. The places both models flag are usually real and usually already handled. The places one flags and the other missed are the reason I am running two.

For a risky change, auth, a migration, anything touching data I cannot get back, I add an adversarial pass with a focus line naming the risk. That one is not looking for typos, it is trying to talk me out of the approach, and sometimes it should.

Then the escalation. When Claude has failed the same fix twice, or when I can see my Claude usage running low and I would rather spend the OpenAI side, I hand the problem to /codex:rescue. A fresh model from another family unsticks a loop more often than a third attempt from the same one. The rule I hold to: whatever Codex writes, Claude reads the diff before it gets accepted. The second engineer proposes; it does not merge.

Two skills that make it a habit

Left to willpower, I forget to run the review until after I have pushed. So I wrote two small skills that turn the routine into something Claude reaches for on its own. A skill is just a SKILL.md file in its own folder under ~/.claude/skills/, and Claude loads it when the moment fits. If you want the fuller picture of how skills work, I went into it in how to build a Claude Code plugin.

The first is a router. It encodes the decision I keep making by hand, when to stay in Claude and when to hand off, so I do not have to remember the policy every time.

---
name: delegate-to-codex
description: Decide when to hand work to Codex versus handle it in Claude. Use when finishing an implementation, before opening a PR, when a bug survives two fix attempts, or when the user asks for an independent or second-opinion review.
---

You have the Codex plugin available. Codex is a different model family, so it
is a decorrelated second opinion, not a smarter clone. Use it for cross-checks
and to spend the ChatGPT quota instead of the Claude quota.

## Handle it in Claude
- Planning, first-pass implementation, routine edits.
- Anything where a second opinion adds nothing.

## Hand off to Codex
1. Before a PR: run your own review of the diff, then run `/codex:review
   --background` for the cross-family pass.
2. For risky or irreversible changes (auth, migrations, cache invalidation,
   money, deletes): also run `/codex:adversarial-review` with a focus line
   naming the specific risk.
3. When a bug survives two Claude fix attempts, or the user is low on Claude
   usage: `/codex:rescue` to investigate root cause.

## Reporting
Compare the Codex findings against your own review and surface only the
disagreements. Agreement is not interesting; the gap between the two is.
Never accept a Codex diff without reading it first.

The second is the pre-PR check, split out because it is the one I want to fire the same way every time. It runs Claude's own review first, then the Codex one, and reports where they differ.

---
name: pre-pr-review
description: Two-model review of a diff before opening a PR. Runs the built-in Claude review, then a cross-family Codex review, and reports only where the two disagree. Use before opening a pull request or when asked to review a branch for merge.
disable-model-invocation: true
---

Run before a PR. Do not fix anything during this skill; report only.

1. Review the current diff yourself for correctness, edge cases, security, and
   missing tests. Hold the findings.
2. Run `/codex:review --background` for the same diff (use `--base <branch>`
   for a branch review). Wait for it with `/codex:status` and `/codex:result`.
3. Produce one short report with three buckets:
   - **Both flagged** (high confidence, fix these first)
   - **Only Claude flagged**
   - **Only Codex flagged** (the decorrelated catches, read closely)
4. Stop there. The human decides what to fix.

I set disable-model-invocation: true on the pre-PR one so it only fires when I type /pre-pr-review. Anything that spends the other quota, I would rather trigger on purpose than have trigger itself. The router I leave open so Claude can consult it at the natural moments. If you want to see how far a three-sentence skill can go, the grill-me skill is a good reminder that the prompt is doing the work, not the plumbing.

What it costs on two quotas

The honest catch is that you are now managing two budgets that do not know about each other. A few habits keep it sane.

Leave the Codex default on Terra. Reviews and routine delegation do not need the flagship, and pointing your config at Sol means every /codex:review runs on the most expensive tier. Escalate to Sol only where it pays, on a hard /codex:rescue or an adversarial pass on a genuinely risky change, and do it per command so the default stays cheap.

Keep the review gate off. /codex:setup can install a Stop hook that reviews every response and blocks Claude until issues are addressed. It is a legitimate feature, but OpenAI's own warning is blunt: it "can create a long-running Claude/Codex loop and may drain usage limits quickly." I would rather run /codex:review when I mean to than have two models ping-ponging while I am not watching. Turn it on for a monitored release audit if you like, then turn it back off.

And watch both dashboards, because nothing shows you a combined number. Claude's /usage covers one side; the Codex usage view covers the other. The first month you will misjudge the split, then it settles.

Worth it?

For solo throwaway work, no. The setup is overhead you will not recoup on a script you run once.

For anything you are going to ship, yes, and more than I expected. The reviews I act on are the ones where Claude and Codex disagree, and I would not have those without a second family in the loop. The rescue path has pulled me out of more than one two-attempt spiral in a single pass. And on a Max-plus-Plus setup the quota math works in your favor: the expensive Claude model plans and decides, while the second engineer does the independent read and the grunt fixes on a different meter. If you already lean on Claude Code, this is the same instinct behind getting more out of Claude Code, aimed at review instead of writing. The disagreements are the payoff, and a reader from another family is the only way I have found to get them.