Claude Code vs OpenAI Codex CLI: A Practical Comparison

How each agent actually works

Both tools install as a CLI, sit in your terminal, and work agentically: they assemble context from the repository, plan, call tools (shell, MCP servers, web search) and write changes back. The difference a developer feels day to day is the model family and the surrounding ergonomics; the difference a platform team feels is where configuration and credentials live.

Claude Code runs on Anthropic’s current models — Opus 5.5, Sonnet 5.5 and Haiku 5.5 — with extended thinking on by default and a model picker (/model) to trade cost for capability. It reads a hierarchy of CLAUDE.md instruction files (enterprise, project and user scope) and settings.json, ships an IDE extension alongside the terminal, and exposes subagents, skills and hooks. Codex CLI runs on OpenAI’s Codex-family models, is open source, and is driven by a ~/.codex/config.toml that names a model provider; it reads an AGENTS.md for repo-level instructions and runs edits inside a sandbox with an approval policy. In both, the agent holds a long-lived credential, reads whole files, and spends per token — the three properties that make a coding agent the hardest thing in your estate to govern.

Capabilities and architecture, side by side

The two agents converge on the same loop — context in, plan, tool calls, diff out — but the way each handles context, tools and safety is where the day-to-day feel diverges.

Context handling

Claude’s models carry a context window of roughly 200,000 tokens (larger in preview on some tiers), and Claude Code manages it actively: it compacts earlier turns as the window fills, lets you steer scope through CLAUDE.md, and treats prompt caching as a cost lever — on a subscription the cache lifetime is about one hour, on the API or a cloud provider around five minutes, and cached reads land roughly ten times cheaper than fresh input. Codex CLI assembles context from the working tree and AGENTS.md and relies on its model’s window plus summarisation. The upshot is the same for both: the more context you feed, the more each turn costs, so context discipline is a spend decision, not just ergonomics. For the arithmetic, see the Claude prompt-caching cost math.

Tool calling and MCP

Both agents speak the Model Context Protocol, so the same MCP servers — a database reader, a ticketing bridge, an internal API — plug into either. Claude Code defers MCP tool definitions by default (not loaded into context until needed) and layers subagents and on-demand skills on top, which keeps the token overhead of a large tool catalogue down. Codex CLI is an MCP client too and can itself be exposed as an MCP server. The governance consequence is identical and easy to miss: an MCP server is a second credential and data path the agent’s managed config does not police, so tool allowlisting is a separate control for both. We cover that surface in the best MCP gateway for Claude Code.

Safety model and approvals

Codex CLI leans on an explicit sandbox with modes from read-only to workspace-write to full access, plus an approval policy for when the agent may act without asking. Claude Code gates shell and file actions through permission prompts and hooks that can veto a tool call before it runs. Both put a human in the loop by default and both can be loosened to run unattended — and an unattended agent with a shared key is exactly the configuration that erases attribution, which is where the gateway earns its place.

Feature comparison

On pure coding, both are strong and the gap narrows with every release; benchmark leads trade back and forth. For most teams the choice is not which model is two points higher this month — it is which one your developers prefer and whether you can govern it. We cover the tool-level comparison with Cursor in Cursor vs Claude Code.

Pricing and auth

The billing models are shaped differently, which matters more than the headline rates when you multiply across a team.

Claude Code’s subscription allowance is shared across Claude Code, Claude chat and Cowork on a five-hour and weekly window; Codex usage draws on the developer’s ChatGPT seat or an API key. Auth itself is the governance fork in the road: a subscription or a personal sign-in ties usage to an individual but hides it inside a seat, while a single shared API key is cheap to set up and impossible to attribute. For the full Claude Code breakdown, see Claude Code pricing explained; for what coding agents cost in general, AI coding agent pricing.

Running both agents and tired of two bills, two model policies and two audit trails?

Put Claude Code

Governance: where the real difference is

Both agents live on endpoints you do not own, so the only durable control is an admin-owned config read at higher precedence than the developer’s, a file lock, and short-lived credentials. The path and shape differ. Claude Code reads a managed settings.json that your MDM writes to a system location the developer cannot edit — on macOS under Application Support, on Linux under /etc — and that layer outranks the user’s own settings. Codex enforces through a managed config whose path, schema and precedence change by operating system and CLI version — a sharper edge that has caught fleets out when a release moved the precedence. We go deep on the Codex side in OpenAI Codex governance, and on the Claude side in Claude Code governance with an AI gateway.

The three controls that actually hold, for either agent:

• An admin-owned config at higher precedence. Written by MDM to a path the user account cannot modify, so it survives a developer editing their own settings. Without this, every other control is advisory.
• A pinned base URL. Point the agent at your gateway rather than the vendor endpoint, so every request leaves the laptop through a control point you own.
• Short-lived, per-developer credentials. Tokens issued to an identity and refreshed on a schedule — never one tenant-wide API key — so revocation and attribution both work.

The point both agents share: enforcement that depends on the developer not editing a file is not enforcement. What makes it real is a control point on the network path — which is the gateway, adding only a few milliseconds of overhead and emitting OpenTelemetry so your existing observability sees both agents the same way. For the token-accounting side, see Claude observability and token accounting.

When to pick which

If you are forced to lead with one agent, the signal is rarely the benchmark — it is the surrounding stack, the auth model you can live with, and where your developers already are. This matrix captures the usual deciders.

Note the last row. For most enterprises the honest answer is that the decision is close enough that standardising on one costs more in developer friction than it saves in simplicity — which is the case for running both.

The answer most teams actually want: run both

Developer preference is real and not worth fighting. Some engineers are faster in Claude Code, others in Codex, and a year from now the leader may have flipped. Routing both through the TrueFoundry AI Gateway makes the choice reversible: each request resolves to an individual, you set which models each tool may reach, spend is attributed per developer, and audit is produced on the path rather than requested from a laptop. You get one cost view across Claude Code, Cursor and Codex instead of three.

A worked example

Fifty engineers, split roughly evenly between the two agents. Instead of standardising on one and forcing the other half to switch, the platform team points both at the gateway: Claude Code and Codex each get a managed config over MDM that targets the gateway base URL, a model policy that keeps the most expensive tier a deliberate choice, and short-lived tokens refreshed on a schedule. Security gets one audit trail with the real developer on every request; finance gets one per-team number; developers keep the tool they like. The verdict stops being Claude Code or Codex and becomes a routing decision you can change without touching a laptop.

Migration and coexistence: a rollout path

Whether you are moving a fleet from one agent to the other or deliberately keeping both, the gateway turns a disruptive migration into a routing change. A practical sequence:

1. Put the gateway in front first. Before changing any agent, stand up the AI gateway and route existing traffic through it. Nothing about the developer experience changes yet, but you now have attribution and a control point.
2. Pin the base URL over MDM. Push a managed config to both Claude Code and Codex that targets the gateway and locks the file, so a developer cannot quietly point back at the vendor endpoint.
3. Replace shared keys with per-developer identity. Swap any tenant-wide API key for short-lived tokens issued per engineer; this is what makes the per-team spend numbers and the audit trail real.
4. Set model policy per tool. Keep the Opus-equivalent top tier a deliberate choice rather than a silent default, and let cheaper models handle routine work — the single biggest lever on cost for either agent.
5. Let developers switch agents freely. With identity, policy, spend and audit on the path, moving an engineer from Codex to Claude Code (or back) is a preference, not a project. If you ever do standardise, the migration is already done.

The same sequence works for coexistence: never force step five. Both agents run side by side behind one control plane, and the organisation stops caring which one any given engineer opened this morning.

Gotchas worth knowing

• Codex enforcement is version-sensitive. The managed-config file, its schema and its precedence have changed between releases and differ on Windows; verify the CLI version before claiming a fleet is governed.
• A shared API key destroys attribution for either agent — one tenant-wide credential cannot answer “who sent that prompt.” Issue per-developer identity instead.
• Benchmarks are a snapshot. Picking a tool on this quarter’s leaderboard locks you into a decision the next release can invert; keeping the choice reversible is worth more than two benchmark points.
• Neither agent’s MDM setup governs its MCP servers by default — tool allowlisting is a separate control, so don’t tell an auditor the config covers it.
• Model defaults drive cost. Opus-equivalent tiers left as the default are the usual source of surprise spend; cap them with policy.
• Cloud-provider billing bypasses the vendor dashboard. Run Claude Code through Bedrock, Vertex or Foundry and the spend lands on your cloud bill with no per-developer breakdown — attribution has to come from OpenTelemetry or a gateway.

Related reading

• OpenAI Codex Governance — enforcing Codex across a developer fleet
• Cursor vs Claude Code — the IDE-agent angle
• Centralising Cost Control for AI Coding IDEs — one cost view across agents
• Claude Code Pricing Explained — plans, token costs and how to cut spend
• The Best AI Gateway for Claude Code — where to route it

Conclusion

Claude Code vs OpenAI Codex CLI is a genuine toss-up on coding, and that is exactly why standardising on one is the wrong instinct. The models will keep leapfrogging, and your developers already have preferences. What does not change is the need for identity, model policy, spend attribution and audit on every request — and none of those belong in a TOML or JSON file on a laptop.

Pick the agent your developers like. Then make the choice reversible by putting it behind a control plane, so switching is a routing change and not a migration.

Govern Claude Code and Codex from one place.

Start free on TrueFoundry