Codex vs Claude Code, from someone who wired into both
I run both agents daily and built integrations against both of their extension systems. This comparison skips the benchmark reposts and covers what actually differs when you live in them: automation surface, session signals, workflow shape, and how to pick.
Most Codex vs Claude Code comparisons are benchmark screenshots and pricing tables copied from two landing pages. This one is different in a specific way: I run both agents every day, and I built a product that integrates with both of their extension systems, which means I have read their hook payloads, their config files, and some of their source. That seat shows you differences the benchmark posts never touch.
Quick disclosure up front: I make Unwait, a macOS app that shows flashcards while either agent works. I need both tools to be good, and I have no stake in which one you pick. Where the two differ, I will say so plainly; where they are equivalent, I will say that too.
Where they are the same
Both are terminal coding agents: you describe work, they read your repo, edit files, run commands, and come back. Both handle multi-file changes, both respect project instruction files, both ship permission systems so the agent asks before dangerous commands. Both are bundled with subscriptions you may already pay for: Codex signs in with a ChatGPT plan (Plus and up) and Claude Code with a Claude plan. For day-to-day "implement this function, fix this bug" work, either one is genuinely fine, and anyone telling you one is unusable is selling something.
The differences show up when you push past the chat loop.
The automation surface is not close
This is the gap I know best, because I built against both.
Claude Code exposes a full lifecycle hook system. Dozens of events fire as JSON on stdin: prompt submitted, tool about to run, tool finished, turn ended, permission requested, session started and ended. Hooks can observe, but they can also decide: block a dangerous command, refuse to end the turn until tests pass, inject context. I documented the payload contract and six configs worth stealing in earlier posts. The short version: Claude Code treats external tooling as a first-class audience.
Codex exposes one key: notify. It runs a command when a turn completes, passing JSON as an argv argument. That is the whole documented surface. There is no start event, no tool events, and no ability to veto anything. In Codex's source a richer lifecycle-hooks system exists (notify is now internally a compatibility layer named legacy_notify), so this gap may narrow, but as of this writing notify is what you get, and it has real sharp edges: it must be a top-level TOML key, it executes without a shell, and only one tool can own it at a time.
A concrete consequence: with Claude Code you can measure a wait, because you get a signal when the prompt is submitted and another when the turn ends. With Codex you only learn a turn ended, never when it began. When I built wait-time features for both, Claude Code got the full experience and Codex got a reduced one, not by choice but because the signal does not exist. If you plan to build tooling around your agent, or want the ecosystem of things others have built, this is the single biggest practical difference between the products.
Session signals and multi-session work
Claude Code distinguishes "the turn ended" from "the agent is blocked waiting for your permission", and fires a separate event for the second. Codex's notify cannot tell you an agent is blocked, only that it finished. If you run one session with permission prompts off, you will not care. If you run three sessions in parallel, you will care a lot, because a blocked agent looks exactly like a working one, and unnoticed blocks are the most expensive dead time in a multi-session workflow. Claude Code payloads also carry a session id and working directory, which is what makes per-project, per-session tooling possible at all.
Workflow shape
Differences you feel in the first week, stated without benchmark theater:
- Config and instructions. Both read project instruction files (CLAUDE.md and AGENTS.md respectively); the convention is close enough to maintain both from one source.
- Extensibility beyond hooks. Claude Code has grown an ecosystem layer: skills, plugins, MCP servers, subagents. Codex is simpler by design, closer to "one very capable agent in a box". Whether "simpler" reads as clean or limiting depends on how much you customize.
- Interfaces. Both have CLI and IDE-adjacent options, and both can run in the cloud tethered to their vendor's web UI. Codex leans on the ChatGPT apps; Claude Code on Claude's.
- Models. Each is locked to its vendor's models, so part of this choice is really "whose frontier coding model do you trust this quarter", and that answer has flipped multiple times in the past year. I would not sign an annual contract over a model benchmark.
Pricing
Both come bundled with consumer subscriptions, both meter usage against your plan tier, and both sell API-key escape hatches. The numbers change too often to print here; check the official pricing pages the week you decide. The structural note that stays true: if your team already pays for ChatGPT or for Claude, the bundled agent is effectively discounted, and that gravity decides more purchases than any feature list.
How to actually pick
- You already pay for one vendor: use that one. The bundled agent is good enough that switching subscriptions for the other is rarely justified.
- You build tooling, or want notifications, gates, and integrations: Claude Code, and it is not close. The hook system is the difference between a scriptable platform and a closed loop.
- You want minimal surface area: Codex's one-binary, one-config simplicity is a legitimate preference, especially if you never touch automation.
- You run agents in parallel all day: Claude Code's session signals (start, end, blocked, per-session ids) are the raw material for keeping N sessions honest.
- Either way: they coexist fine. I run both daily on the same machine, and plenty of developers keep the second one around for hard problems, second opinions, or when one vendor has a bad model week.
If the wait time between prompts is the part of agent work that bothers you, that is the exact problem Unwait exists for, on both agents. And if you want the deeper technical dives behind this comparison, the hooks payload reference and the Codex notify writeup are where this post came from.