You don’t have to choose between Claude Code and Codex. You have to give them different jobs.

Every few weeks someone asks me which one to drop. Claude Code or OpenAI Codex — pick a lane, stop paying for two subscriptions, commit. I understand the instinct. Nobody wants to be the person juggling two CLIs and two sets of API keys just to feel clever.

But after running both against the same repos for months, I’ve stopped trying to pick a winner. The question “which one is better” turned out to be the wrong question. The right one is: which parts of my week does each one actually own? Once I split the work along those lines instead of loyalty lines, I stopped losing time to either tool’s weak spots.

This isn’t a shootout. It’s a field guide to running Claude Code and Codex in the same codebase without them tripping over each other — where their designs pull in different directions, where they’ve quietly converged on the same ideas, and where pairing them buys you something neither gets you alone.

Why “which one wins” stopped being the interesting question

For most of 2025, the honest comparison was lopsided in one direction or another depending on the week — one model would edge ahead on a benchmark, the other would ship a feature first, and blog posts would declare a winner that expired within a quarter. That race is still running. Both companies ship new model versions on a cadence measured in weeks, and whichever one is “ahead” on SWE-bench this month will likely trade places again before you finish reading this sentence.

Chasing that number is a bad way to plan your workflow. A benchmark score doesn’t tell you which tool should touch your billing service versus your marketing site, and it doesn’t tell you what happens when the agent you’re relying on hits its rate limit at 4 PM with a deadline at 5.

What’s more useful is looking at what each tool is actually built to do well, structurally, independent of which model is winning this week’s leaderboard. That’s a much more stable thing to plan around, and it’s the thing this piece is actually about.

What each one is actually built for

Strip away the marketing and both tools are agent loops wrapped around a frontier model, with tools for reading, writing, and running code. The differences that matter aren’t in the loop — they’re in where each one assumes you’ll be sitting when you use it.

Claude Code was built around the terminal and the IDE. Its core extension model has four pieces: CLAUDE.md for always-on project context, skills for on-demand workflows you trigger with a slash command, subagents for isolating noisy work in a separate context window, and hooks that fire deterministically on lifecycle events like a tool call or a session start. Together they’re designed for a developer who’s present, iterating, and wants fine-grained control over what the agent is and isn’t allowed to touch. The hook system in particular is worth sitting with. A PreToolUse hook can literally intercept a tool call, inspect what Claude is about to do, and block or rewrite it before it executes. That's enforcement, not a polite suggestion in a config file. Claude Code also ships as a desktop app, a web app, IDE extensions, and even runs on iOS now, but its center of gravity is still the live, collaborative session.

Codex was built around the ticket. Its CLI and IDE extension cover the same local, interactive territory as Claude Code, but Codex’s distinguishing surface is its cloud layer. Hand it a task from the CLI, a GitHub issue, a Slack message, or a Linear ticket, and it spins up an isolated sandbox, does the work, and comes back with a pull request you review instead of a live conversation you have to babysit. Mention @codex in a GitHub PR comment and it opens a cloud task using that PR as context. Queue three or four of those before you get coffee and they're often done by the time you sit down. That's a fundamentally different relationship to your attention than a terminal session: Codex is built to be handed work and walk away, not to be watched.

Neither description is a knock on the other tool. Claude Code can run background subagents and, more recently, coordinate multiple independent sessions as “agent teams.” Codex has a full interactive app and IDE extension for the same kind of live pairing Claude Code does well. But watch where each company has actually invested: Claude Code’s hook system and its plugin and skill marketplace, Codex’s cloud environments and its native GitHub, Slack, and Linear integrations. The center of gravity in each case is clear enough to build a workflow around.

The part that used to be annoying and now isn’t

A year ago, running both tools on the same repo meant maintaining two separate instruction files that inevitably drifted out of sync: a CLAUDE.md for one agent, a Codex-specific config for the other, both trying to say the same thing about your test command and your forbidden directories, both eventually saying something slightly different.

That friction has mostly dissolved. AGENTS.md, a plain markdown file for project-specific agent instructions originally proposed by OpenAI and now used across more than two dozen tools, has become the shared substrate. Codex reads it natively. Claude Code now reads it too when no CLAUDE.md is present, and treats it as a baseline that project-specific CLAUDE.md content layers on top of. Practically, that means you can write your test command, your style rules, and your "never touch this directory" list once, in one file, at the root of your repo, and both agents start from the same page.

The same convergence happened with tool access. Both tools now speak the Model Context Protocol, the open standard for connecting an agent to an external system — your issue tracker, your internal docs search, your database schema. Build one MCP server for your ticketing system and both Claude Code and Codex can call it. You’re no longer writing the same integration twice.

Here’s the shape of a repo set up this way:

your-repo/
├── AGENTS.md              <- shared rules: test command, forbidden paths, conventions
├── CLAUDE.md               <- Claude Code specifics: hooks, subagent definitions
├── .codex/config.toml       <- Codex specifics: sandbox mode, approval policy
├── mcp/
│   └── ticketing-server/    <- one MCP server, used by both agents
└── src/

        AGENTS.md (shared)
              │
      ┌───────┴────────┐
      │                │
 Claude Code        Codex CLI/App
 (interactive,      (interactive,
  hooks enforce      cloud queue for
  guardrails)         async tasks)
      │                │
      └───────┬────────┘
              │
     same MCP server
   (ticketing, docs, DB)

That convergence is what actually matters here. It’s not that the two tools do different things architecturally anymore. They’ve converged on nearly identical extension models: skills, subagents, MCP, hooks or their equivalents, plugin systems. The convergence just makes it cheap to run both without doubling your configuration burden. The complementary value now comes from four places: where you naturally sit when you use each one, having a second model family to catch what the first misses, matching each tool’s guardrail philosophy to the risk of the task, and plain redundancy against rate limits and outages. Take those one at a time.

Pattern one: the interactive partner and the cloud fleet

The split I’ve found most effective is also the simplest. Reserve Claude Code for work that benefits from a real back-and-forth: the feature where you’re not sure of the approach yet, the refactor that touches a part of the codebase only you understand, the debugging session where you need to think out loud with something that pushes back. Route everything else, the backlog of small well-scoped tickets, the dependency bumps, the flaky test someone flagged three sprints ago, the “update this error message to match the new copy” tasks, to Codex’s cloud queue.

The mechanics are simple too. At the start of a work session, I go through the backlog and tag anything scoped enough to hand off, usually five or six items, and either queue them from the Codex CLI or tag @codex on the corresponding GitHub issues. Each one runs in its own sandboxed environment with its own git state, so they don't collide with each other or with what I'm doing locally. Then I open Claude Code in the repo I actually need to think in, and work the way I normally would: describing what I want, reviewing what it proposes, correcting course mid-stream.

By the time I’ve made real progress on the hard thing, the easy things have PRs waiting for review. That’s the core trade. Claude Code time is expensive, because it’s your attention spent on the problem that needs it, and Codex cloud time is cheap, because it’s running unattended against problems that don’t need your attention at all. The math only works if you’re honest about which bucket a task belongs in. Handing Codex something genuinely ambiguous just means you get an ambiguous PR back and spend the saved time re-explaining what you actually wanted.

Pattern two: two models catch different bugs

This is the pattern I was most skeptical of before I started doing it, and the one that’s paid off the most concretely. Claude and the models behind Codex are trained differently, by different teams, on different data mixes, with different reinforcement signals shaping what they consider “done.” That means they don’t just perform differently on aggregate benchmarks — they miss different things on any individual piece of code. A model that’s meticulous about null checks might be looser about concurrency edge cases. One that’s excellent at matching existing code style might be more willing to skip an error path that isn’t obviously exercised by the visible test suite.

So the second half of this pattern: whichever tool wrote a given piece of code, have the other one review it before it merges. If Codex generated a PR from a ticket, I’ll paste the diff into a Claude Code session and ask it to review specifically for edge cases, security issues, and anything that looks like it was pattern-matched from similar code rather than reasoned through for this specific context. Codex has the reverse built in more natively — its GitHub integration supports automated code review on pull requests, including ones Claude Code authored, and its dedicated security plugin runs deeper scans for things like injection risks and unsafe deserialization.

I don’t have a controlled study to hand you a precise defect-catch-rate number, and I’d be suspicious of anyone who claims one without publishing their methodology — codebases and bug classes vary too much for a single number to travel well. What I can tell you concretely is what it caught in my own repos: a race condition in a queue consumer that the authoring model’s own test suite passed cleanly, and a case where a refactor silently dropped a finally block that closed a database connection. Neither was exotic. Both were exactly the kind of thing a second, differently-trained reader is more likely to notice than the same model re-reading its own work, because it isn't reviewing against the same blind spots it wrote the code with.

This is the same reason human teams do code review with a different person than the author, and the reasoning holds even better across models than across people, because the “different perspective” is architecturally guaranteed rather than a matter of who happened to be free.

Pattern three: match the guardrail to the risk

Claude Code and Codex sit at different points on the risk-control spectrum for a reason, and once you notice it, it becomes a genuinely useful dial rather than an inconsistency to paper over.

Claude Code’s hooks operate at the application layer with real precision. A PreToolUse hook sees the specific tool call the agent is about to make — which file, which command, which arguments — and can block, modify, or approve it before anything happens. You can write a rule as narrow as "never let a tool call touch anything under /billing without an explicit approval," and that rule holds every single time, deterministically, because it's enforced by code rather than requested in a prompt.

Codex’s sandbox model works one layer down, at the operating system. Sandbox modes like workspace-write and danger-full-access control what the process can technically do — where it can write, whether it can reach the network — independent of what any instruction file says, and its approval policy separately controls when it has to stop and ask before crossing that boundary. It's coarser-grained than a Claude Code hook, but it's also harder to reason your way around, because it isn't a policy the model is choosing to follow — it's a constraint on the process itself.

In practice, that difference tells me which tool to reach for based on how much I trust the task, not how much I trust the tool. For work where I need a specific, narrow policy enforced with surgical precision — “you may refactor this function, but you may not touch the auth middleware it calls” — Claude Code’s hook layer is the better fit, because that’s exactly the granularity it’s built for. For a task I genuinely want to fire off and forget entirely, where I’d rather have a hard OS-level wall than a set of clever rules, Codex’s cloud sandbox running in workspace-write with on-request approval gives me that wall without me having to build it myself.

Neither is strictly safer than the other. They’re different shapes of safety, and matching the shape to the job is the actual skill.

Pattern four: redundancy for the day one vendor has a bad day

The least glamorous reason to run both is also one of the most reliable in practice: usage limits and outages don’t happen to both vendors at the same time.

Both tools meter usage in rolling windows rather than a flat monthly cap. Claude Code plans give you a five-hour session window plus a weekly cap measured in model hours. Codex plans give you a five-hour window measured in messages, plus separate allowances for cloud tasks and code review. Burn through one mid-afternoon on a hard problem and you’re locked out of that tool for the rest of the window, not the rest of the month, but “locked out for the rest of the window” is exactly when you have a deadline. Having the other tool live means a rate limit is an inconvenience instead of a stop.

The same logic applies to outages, which happen to every hosted service eventually. I’ve had a Claude Code session drop mid-task during a provider incident and simply picked up the same work in Codex’s CLI using the same AGENTS.md context, because the shared instruction file meant I wasn't starting from zero. That's a small thing until the one time it saves an afternoon.

This isn’t a reason to run both tools by default if you don’t otherwise need to — it’s a reason not to fully cancel the one you’re using less, even after you’ve settled into a primary. The marginal cost of keeping a second seat active is usually smaller than the cost of being fully blocked at the wrong moment.

What a day like this actually looks like

Concretely, not aspirationally: I start most mornings with fifteen minutes going through the ticket backlog, tagging anything that’s scoped tightly enough to hand off. A dependency bump flagged by a security scanner, a support-reported bug with clear repro steps, a copy fix. Those get queued to Codex, either from the CLI or by tagging @codex directly on the GitHub issues, usually four or five at a time.

Then I open Claude Code in the repo where I’m doing the actual design work for the week, recently, restructuring how a service handles retries across three downstream dependencies. That’s not a task I want to hand off. It’s a task I want to think through, and Claude Code’s back-and-forth, plus a couple of subagents scoped to “trace every current caller of the retry logic” and “summarize how the test suite currently covers failure injection,” keeps that exploration from flooding my main context with file contents I don’t need to see directly.

By late morning, the Codex tasks have PRs waiting. I don’t merge on sight. Each one gets a pass — sometimes from me directly, sometimes by pasting the diff into my open Claude Code session and asking it to review specifically for what the ticket didn’t explicitly ask about: does this dependency bump change any documented behavior, does this bug fix handle the case adjacent to the one that was reported. Most pass clean. The ones that don’t are almost always the interesting kind of wrong — not broken, but narrower than the problem actually was.

The retry redesign takes most of the day and doesn’t get handed to anything. That’s the point of the split: the backlog runs in parallel in the background, cheaply, while the one thing that actually needs a mind gets one.

What breaks when you do this

None of this is free, and the honest version of this piece has to say where it costs you.

The instruction files converged, but they didn’t fully merge. AGENTS.md covers the shared baseline well: test commands, style conventions, forbidden paths. But the moment you want something tool-specific, like a Claude Code hook script or a custom subagent definition, you're back to maintaining a second file. That's a smaller problem than it was, not a solved one.

Neither tool knows what happened in the other’s session. If you spend twenty minutes in a Claude Code conversation talking through why you’re structuring an API a certain way, that reasoning lives in your terminal history and nowhere else, unless you write it down somewhere both agents can see: a commit message, a PR description, an architecture doc, a comment on the ticket. Codex picking up the next related task has no access to that conversation. I learned this the annoying way. A Codex cloud task “fixed” a workaround I’d deliberately left in place after a design discussion earlier that day, because the reasoning behind it existed only in a chat window it had never seen. The fix wasn’t wrong given what it could see. It was wrong given context it had no way to have. The discipline this forces is real and worth naming: decisions that matter need to live in the repo, not in your head or your chat history, or the second tool will happily undo the first tool’s careful work.

Running both means running two of everything else, too: two subscriptions, two sets of credentials, two MCP configurations to keep in sync if you’re not careful, two rate-limit windows to track. That’s not a dealbreaker, but it’s not nothing, and it’s worth pricing in before you commit to this as your default rather than an occasional pattern.

And the guardrail asymmetry cuts both ways. A rule you’ve carefully encoded as a Claude Code hook does not automatically apply the moment Codex touches the same repository. If “never touch /billing without approval" matters, it has to be enforced in both tools' permission systems independently, or it's only a rule half the time.

When it isn’t worth the overhead

If you’re a solo developer working in one repository, the case for running both tools is genuinely weaker than the case for picking one and getting deep with it. The overhead here, two configurations, two credential sets, the discipline of writing decisions down so they survive across tools, has to be paid for by a real gain in throughput or defect reduction. For a single person on a single codebase, that gain is often smaller than what you’d get from spending the same energy mastering one tool’s hooks, skills, and subagent system thoroughly.

Where this pattern earns its keep is different: teams juggling work across many repositories or many tickets in parallel, where the async cloud-fleet pattern turns a backlog into a review queue instead of a to-do list; situations where a second model’s review has caught something expensive enough that the cross-check pays for itself on its own; or organizations that are already paying for both a ChatGPT and a Claude seat for unrelated reasons, where the coding agents come along for free and the only question is whether to use them well or let them sit idle.

If none of that describes your situation, I’d rather tell you to skip this than sell you on complexity you don’t need.

Where to start

You don’t need the full setup on day one. Start with three things.

Write a single AGENTS.md at your repo root with your test command, your build command, your code style expectations, and an explicit list of paths that need human approval before any agent touches them. This is the file that pays for itself immediately, regardless of which tools you end up using.

Pick one tool as your default for anything you’d actually want to sit and watch, and treat the other as your queue for anything you’d rather hand off entirely. Don’t overthink which is which at first — the split matters more than which side gets which tool, and you’ll recalibrate after a week of actually doing it.

Require a second look before anything ships. It doesn’t need to be formal. It can be as simple as pasting a diff into the other tool and asking “what would you flag here that the author might have missed.” The value isn’t in the ceremony. It’s in making sure at least one piece of code that matters gets read by something that didn’t write it.

Everything past that — MCP servers, custom hooks, subagent definitions, sandbox policies — is tuning. Get the baseline habit right first, and the tooling underneath it stops mattering as much as which questions you’re asking before you merge.

If this was useful, consider following for more posts on building with AI in production. If something here is wrong or outdated, I’d rather know — drop a comment.