Head-to-Head, and When to Choose Which

Having seen both harnesses on their own terms, we can now set them side by side — dimension by dimension — and turn the differences into practical guidance. The goal is a fair map of trade-offs, not a winner.

Sources: code.claude.com/docs · developers.openai.com/codex · github.com/openai/codex.

Ground rules for a fair comparison

Two cautions before the table. First, this is a comparison of documented features, not a benchmark: nothing here measures which agent writes better code or solves tasks faster, because that depends on the model, the prompt, and the task far more than on any single harness feature. Second, both tools ship frequently, and details — model ids, exact flag names, preset labels — move between releases. Treat the specifics as a snapshot to verify against the current docs, and the structural contrasts as the durable part.

The comparison at a glance

Context and memory — same idea, different emphasis

This is where the two converge most. Both keep persistent project instructions in a Markdown file merged from the repository root down toward where you are working, so guidance grows more specific as you descend — CLAUDE.md and AGENTS.md are close cousins. The differences are matters of emphasis. Claude Code documents a formal four-level hierarchy that reaches up to organization-managed policy and adds an @path import mechanism and an automatic memory alongside the hand-written file. Codex frames AGENTS.md as an open, tool-neutral format and pairs it with explicit compaction controls (/compact, a configurable auto-compact threshold) you can see and adjust. Neither approach is obviously superior; one leans toward layered governance, the other toward a simple shared file plus visible knobs.

Extensibility — a deep stack vs a central config

Here the philosophies diverge most clearly. Claude Code offers many typed extension points, each with its own shape: Skills for packaged know-how, subagents for delegation, hooks for deterministic lifecycle control, and plugins to bundle them for distribution through marketplaces. It is a broad toolkit that rewards investment — you can encode a lot of team-specific behavior — at the cost of more concepts to learn.

Codex concentrates most configuration in one place: a layered config.toml with profiles, custom model providers, and MCP servers, plus slash commands and skills. There is less surface area and fewer distinct mechanisms, which many will find easier to hold in their head, but correspondingly fewer purpose-built hooks for, say, running a formatter after every edit or blocking writes to a protected path. Both extend the tool interface the same way — through MCP — so third-party tools are portable between them in spirit.

Permissions and sandboxing — the sharpest contrast

This is the most consequential difference. Claude Code's safety model is primarily policy: expressive permission modes and allow/ask/deny rules, reinforced in auto mode by a background classifier that inspects actions and can block ones that escalate or look prompt-injected. It is flexible and fine-grained, and it can be paired with external isolation, but the OS sandbox is not the default centerpiece.

Codex makes kernel-level sandboxing the foundation: by default your commands run inside Seatbelt or bubblewrap, writes are confined to the workspace, and network access is off until you turn it on — enforced by the operating system, not by the model's cooperation. Its elegant move is separating the sandbox ("what is possible") from the approval policy ("when to ask"), so you can, for instance, grant broad autonomy within a tightly walled sandbox. Recalling Chapter 1: Claude Code invests more in expressive manners, Codex more in a hard wall. For running an agent unattended on sensitive machines, that wall is a meaningful advantage; for nuanced, rule-by-rule control, the policy model is attractive.

Multi-agent — built-in delegation vs composable process

Claude Code treats multi-agent work as a native feature: subagents each get a fresh context window, the Agent tool delegates to them, delegation can nest, and built-in Explore and Plan agents come ready to use. This keeps the main window clean while parallelizing research and specialized work — context management as architecture.

Codex approaches the same goal through composition rather than a built-in framework. Because it can run as an MCP server, another agent (including Claude Code, or an SDK-driven orchestrator) can drive Codex as a sub-tool; and codex exec plus /fork support scripted parallelism. If your mental model is "one agent orchestrating many specialized children," Claude Code has more of that out of the box; if it is "a solid unit I wire into my own pipeline," Codex's openness fits well.

Ecosystem and openness — marketplace vs open source

The last dimension is a genuine values trade-off. Claude Code brings a maturing plugin-and-marketplace ecosystem — official, community, and private catalogs — that lets teams share tuned setups with an install command. Codex brings the transparency of open source: an Apache-2.0, Rust codebase you can read, audit, fork, self-host, and embed, which matters for security review and for organizations that prefer to own their stack. You are weighing a richer ready-made ecosystem against an inspectable, ownable core; different teams will rank those differently, and neither ranking is wrong.

When to choose which

With the trade-offs in view, some honest, non-tribal guidance:

• Lean Claude Code if you want a deep, typed extension stack — skills, hooks, plugins — to encode team workflows; if built-in subagent orchestration matters; or if a plugin marketplace and layered enterprise memory fit how your organization works.
• Lean Codex CLI if OS-enforced sandboxing by default is a priority (unattended runs, sensitive hosts); if you value an open-source, auditable, self-hostable agent; or if you prefer one legible config file and want to embed the agent into your own pipeline via codex exec or MCP.
• Consider both. They are not mutually exclusive. Both speak MCP, both read a root-to-leaf Markdown memory file, and Codex can even run under another agent as an MCP server. Many developers keep both installed and reach for whichever suits the moment.

Whichever you pick, the lesson of this handbook holds: the model matters, but the harness around it — its tools, its context discipline, its guardrails, and its feedback loops — is what turns a capable model into an agent you can trust with your codebase. Judge these tools, and any future ones, by those four questions.