The comparison has to start above the model layer

“Codex versus Claude” can mean at least three different experiments: compare OpenAI and Anthropic model APIs under one controlled agent harness; compare the Codex and Claude Code products with their native harnesses; or compare two organization-specific deployments after configuration and integration. These experiments answer different questions.

This article addresses the second and third. Codex and Claude Code are software-engineering systems, not model aliases. Both can inspect repositories, edit files, execute tools, run tests, connect external services, delegate subtasks, operate across terminal and editor surfaces, and move work into hosted environments [1, 8]. Both products and their model rosters change quickly. A claim verified in August 2026 is a dated configuration, not an eternal property.

Represent a deployed system jj as

ADVERTISEMENT
Aj=(Mj,Cj,Tj,Pj,Ej,Sj,Oj), \mathcal A_j=(M_j,C_j,T_j,P_j,E_j,S_j,O_j),

where MM is model policy, CC context and state, TT tools and extensibility, PP permissions, EE execution isolation, SS surfaces and handoff, and OO organizational controls. Comparing only MM discards most of what users buy and most of what defenders must secure.

Product topology: convergence is the first result

The products have converged more than brand comparisons suggest.

Codex documentation describes local CLI and IDE work, desktop orchestration, cloud environments, subagents, review, skills, hooks, MCP, and automation. The local CLI is open source under Apache 2.0 and implemented primarily as a systems client rather than a thin webpage [7]. Claude Code documentation describes terminal, VS Code and JetBrains integrations, desktop, web, remote access, background agents, routines, an Agent SDK, hooks, skills, plugins, and MCP [8].

In both systems, the same repository task can traverse several surfaces: interactive local exploration, delegated cloud execution, and human diff review. Consequently, a procurement spreadsheet that compares “CLI available” or “supports MCP” finds little. The differentiators are defaults, semantics, maturity of particular control surfaces, provider ecosystem, and how well state survives movement.

Execution and trust boundaries

The clearest documented difference is in default enforcement.

ADVERTISEMENT

Current Codex security documentation describes local command execution inside an OS-enforced sandbox by default, generally limited to workspace writes with network access off. An on-request approval policy mediates attempts to cross the boundary. Enforcement varies by platform—Seatbelt on macOS, bwrap plus seccomp on Linux, and native or WSL mechanisms on Windows [2].

Claude Code’s default permission architecture asks before file modification and non-read-only shell commands, limits writes to the working directory absent additional permission, and can apply fine-grained allow, ask, and deny rules [10, 9]. Its OS-level Bash sandbox is a separately configurable layer; current settings documentation lists sandbox.enabled as false by default and provides filesystem, network, credential, and fail-if-unavailable controls when enabled [10].

This is not “Codex secure, Claude insecure.” Permissions and sandboxes address different failure paths. Claude Code can be deployed with strict OS isolation and managed settings; Codex can be run in dangerous full-access mode. The difference is which boundary is present before an administrator changes configuration.

The same shed opened two different ways, held by a pressed treadle on the left loom and by a fixed lease rod on the right, with a shuttle caught halfway through the left shed
Figure 1. Permission prompts and sandboxes solve different problems; products can expose similar user choices while enforcing them through different defaults and mechanisms.Image prompt and art direction by Brecht Corbeel; image generated to that direction.

For a regulated deployment, compare resolved policy rather than product defaults:

  • Which processes are sandboxed: only shell children or every local tool path?
  • Are filesystem reads constrained as well as writes?
  • Is command networking disabled, proxied, or domain-allowlisted?
  • Can a project configuration expand authority before workspace trust?
  • Which settings can users override?
  • Does failure to initialize the sandbox stop execution or emit a warning and continue?
  • Can hooks themselves escape the sandbox?

That last point matters. Claude’s hook documentation warns that command hooks execute with the user’s permissions [13]. Codex requires hash-based trust review for non-managed command-hook definitions but likewise treats hooks as extension code, not harmless prompt text [4]. A restrictive agent sandbox can coexist with an unrestricted hook supply chain.

Instructions: AGENTS.md and CLAUDE.md are context, not policy

Codex natively uses AGENTS.md as repository guidance. Claude Code centers CLAUDE.md and path-scoped files under .claude/rules/; its documentation recommends importing or symlinking an existing AGENTS.md rather than duplicating shared rules [11].

ADVERTISEMENT

The formats differ, but the deeper semantics align. Instructions are injected context. They can specify build commands, architecture, style, and expected checks; they are not enforcement. Claude’s documentation states this explicitly and points users to hooks or permissions for hard controls [11]. The same principle applies to Codex: an instruction saying “never deploy” is weaker than withholding deployment credentials and tools.

Instruction portability therefore has two levels. The text can be shared through AGENTS.md and an import. The loading hierarchy, path scoping, conflict resolution, and subagent inheritance can still differ. Teams migrating tools should test which instructions actually enter each worker’s context and after compaction, rather than assuming filename compatibility implies behavioral equivalence.

Persistent state: authored rules versus learned notes

Claude Code currently documents two persistent mechanisms: user-authored CLAUDE.md instructions and auto memory written by Claude. Auto memory is repository-scoped, machine-local, shared across worktrees, and loads a bounded MEMORY.md index at session start; subagents can receive separate persistent-memory scopes [11, 12].

Codex exposes repository instructions, skills, transcripts, resumable sessions, and broader ChatGPT memory/customization surfaces. The operational comparison should not ask which product “has memory.” It should classify state:

  1. Normative state: rules humans intend agents to follow.
  2. Episodic state: what happened in a prior run.
  3. Semantic state: durable facts about architecture and commands.
  4. Procedural state: reusable workflows and tool recipes.
  5. Audit state: evidence that must not be silently rewritten.

Automatically learned notes are useful and potentially stale. Human-authored rules are accountable and potentially neglected. Neither should become an invisible source of authority. Require inspectable storage, timestamps, scope, deletion, and a way to run with memory disabled for controlled evaluation.

Hooks: current breadth versus current trust model

As documented on August 8, 2026, Claude Code exposes a broad lifecycle: session, prompt, pre- and post-tool, permission, subagent, task, compaction, file/configuration, worktree, MCP elicitation, and stop events. Handler types include commands, HTTP endpoints, MCP tools, prompt evaluators, and experimental agent verifiers, with event-specific blocking semantics [13].

Current Codex hook documentation covers the core session, tool, permission, compaction, subagent, prompt, and stop lifecycle. It states that command handlers run today while prompt and agent handler forms are parsed but skipped, and asynchronous command hooks are not yet supported. It adds trust review tied to the hash of non-managed hook definitions [4].

The immediate comparison is that Claude’s documented hook surface is broader and more programmable, while Codex’s current hash-based review provides an explicit mechanism for detecting changed hook definitions before execution. Neither fact predicts future parity; both pages are release behavior, not protocol guarantees.

Hooks can improve determinism: run a formatter after edits, reject destructive commands, require tests before completion, or log configuration changes. They can also create a privileged second control plane. Evaluate timeout behavior and whether errors fail open or closed per event. A post-tool hook cannot undo an external side effect in either product.

One waxed cord tied from a heddle shaft up over a bare frame rail and down outside the treadle tie-up, caught taut and lifting that shaft while every treadle below stands level and unpressed
Figure 2. Hooks are extension code rather than prompt text; a second control path can lift a shaft while every treadle stands untouched.Image prompt and art direction by Brecht Corbeel; image generated to that direction.

Subagents: context isolation is the shared primitive

Both products use subagents to move noisy exploration or specialized work out of the main context and to parallelize independent tasks [3, 12]. Both support custom workers with model, instruction, tool, and sandbox/permission choices. Both warn, implicitly or explicitly, that parallel write-heavy work creates coordination overhead.

Claude Code’s current custom-agent schema is especially granular: tool allow/deny lists, permission mode, model, MCP servers, hooks, skills, turn limits, background mode, worktree isolation, and persistent memory. Non-fork workers begin with a fresh context and selected inherited state; forks inherit the parent conversation [12]. Codex custom agents use TOML layers with model, reasoning effort, sandbox mode, MCP, skills, and developer instructions, while subagents inherit the parent sandbox unless overridden [3].

The important metric is not maximum concurrent workers. It is useful independent work per coordination token. For nn workers,

G(n)=Wuseful(n)Cinference(n)+Cmerge(n)+Creview(n). G(n)=\frac{W_{\mathrm{useful}}(n)} {C_{\mathrm{inference}}(n)+C_{\mathrm{merge}}(n)+C_{\mathrm{review}}(n)}.

G(n)G(n) can decline when workers rediscover shared context, return verbose summaries, edit overlapping files, or rely on inconsistent assumptions. Start parallelism with read-heavy mapping, test analysis, security review, and documentation verification. Isolate writers in worktrees and keep a single owner for global invariants.

MCP: a shared protocol does not imply a shared security model

Both products support local stdio and remote HTTP MCP servers, authentication, tool filtering, and project/user configuration [5, 14]. Claude Code additionally documents deprecated SSE support, WebSocket servers, channel-style pushed messages, detailed scopes, and per-tool user-interaction annotations. Codex documents server and per-tool approval modes, required startup, shared configuration among local clients, and plugin-bundled servers [5, 14].

MCP standardizes discovery and invocation. Client policy remains product-specific. The same server can receive different credentials, expose different tools, or trigger different approval behavior under each client. A migration test should enumerate:

  • transport and authentication compatibility;
  • OAuth scopes and token storage;
  • server trust before project configuration runs;
  • read-only versus side-effect annotations;
  • per-tool approval and organizational overrides;
  • output truncation and context consumption;
  • reconnection, timeout, and failure visibility;
  • prompt-injection treatment of server content.

Claude’s security documentation cautions that Directory listing is not a full security audit of arbitrary MCP servers [9]. Codex documentation likewise treats live network and tool content as untrusted [2]. Protocol conformance is not vendor trust.

Skills and plugins: progressive context versus executable supply chain

Both products use skills as reusable packages of instructions and optional resources/scripts. Codex’s current skill format follows an open SKILL.md structure and loads descriptions before full content, using progressive disclosure to conserve context [6]. Claude Code similarly distinguishes always-loaded project instructions from task-specific skills and supports plugins that bundle skills, agents, hooks, and MCP [8].

Skills improve repeatability only if versioned and tested. A natural-language procedure remains probabilistic. A bundled script can be deterministic but becomes executable supply-chain code. Organizations need provenance, pinning, marketplace policy, signature or hash review where available, and staged updates. “Install this skill” should receive closer scrutiny when it includes hooks or servers than when it contains a checklist.

Cloud, remote, and state portability

Both vendors offer hosted execution in isolated environments and ways to start or continue work away from the original terminal [9, 1]. Hosted execution can improve reproducibility and parallelism while changing credential, logging, data-retention, and network boundaries.

Claude’s security page distinguishes Anthropic-hosted VMs from Remote Control, where execution remains on the local machine and the remote interface synchronizes the session [9]. Codex likewise distinguishes local host execution from its isolated cloud task environments. “Web interface” does not identify where code runs.

State portability should be tested artifact by artifact: repository commit, dirty diff, environment variables, installed tools, instruction hierarchy, memory, MCP authentication, pending approvals, terminal processes, and test evidence. A conversation that appears continuous can cross an execution discontinuity.

A pale ash cloth beam with its worn brass ratchet pawl caught lifted just clear of a tooth, the beam beginning to turn and the woven fell sliding back from the reed as the warp threads slacken
Figure 3. A session that looks continuous can cross an execution discontinuity; state portability has to be tested artifact by artifact rather than inferred from an unbroken thread.Image prompt and art direction by Brecht Corbeel; image generated to that direction.

Migration cost lives in the control plane

Switching the model behind a chat endpoint can take one configuration change. Switching an agent platform can require translating instructions, permission patterns, hook schemas, skills, subagent definitions, MCP scopes, transcript workflows, cloud environments, and audit exports. The visible prompt is the least durable part of the integration.

Avoid making either vendor’s directory tree the only source of organizational truth. Keep build and test commands in ordinary project tooling; keep security policy in operating-system, CI, and identity controls; keep acceptance criteria in tests and review checklists. Then generate or import thin Codex- and Claude-specific adapters. Claude Code documents importing AGENTS.md from CLAUDE.md, which can reduce duplicated behavioral guidance [11]. Shared MCP servers can reduce connector duplication, though client policy still requires separate testing.

For teams using both products, assign ownership to each control file and test it in CI where practical. A stale .claude rule and current .codex rule can produce divergent behavior without any model defect. Record platform version alongside agent-produced evidence, because hook and permission semantics evolve. Portability is strongest when replacing the agent changes orchestration but not the definition of a correct build, permitted credential, or accepted patch.

Models: compare under control or compare whole products

If the research question concerns model capability, place OpenAI and Anthropic models inside the same open harness, provide equivalent tools and budget, and run blinded evaluators. If the question concerns product utility, retain each native harness but report its authority, cost, latency, and evidence.

Do not mix the designs. A native Codex result against a Claude model called through a bare API confounds model and harness. A Claude Code result with optional sandbox disabled against Codex in workspace isolation confounds capability and authority. Vendor leaderboards often differ in model snapshot, reasoning effort, task exclusions, and date.

The fair product experiment is paired and randomized where possible: draw tasks from the organization’s backlog before assignment, freeze acceptance criteria, assign equivalent developers and permissions, and measure accepted value after review. Include crossover periods to separate learning from product effects.

A weighted selection framework

Let dimensions dd include local-platform support, isolation, context fidelity, extensibility, enterprise policy, cloud reproducibility, review ergonomics, latency, and total cost. For organization oo, define

Soj=∑dwodzjd−λoCj−μoRj, S_{oj}=\sum_d w_{od}z_{jd} -\lambda_o C_j-\mu_o R_j,

where zjdz_{jd} is measured product performance, wodw_{od} local importance, CjC_j switching and operating cost, and RjR_j residual risk. A startup and a bank should choose different weights. Scores should come from trials, not feature presence alone.

Hanging tension weights on the warp cords of both looms, with one further weight being lowered onto a cord and the beam it hangs from still settling
Figure 4. Procurement is a weighted decision over a local task distribution and threat model, not a universal ranking inherited from a benchmark.Image prompt and art direction by Brecht Corbeel; image generated to that direction.

Use at least these trial families:

  1. focused local bug fixes with rapid steering;
  2. long cloud refactors from clean environments;
  3. multi-language repository exploration;
  4. independent code and security review;
  5. prompt-injection and malicious-repository tests;
  6. MCP workflows with least-privilege credentials;
  7. subagent decomposition and merge;
  8. interrupted, compacted, and cross-surface handoffs;
  9. enterprise policy and audit export;
  10. cost and reviewer-time measurement.

The product with the highest completion count can lose if it generates more escaped defects, review minutes, or policy violations.

Where each system may fit

Based on current documentation rather than an uncontrolled head-to-head trial:

  • Codex is attractive when default local OS sandboxing, an open-source CLI, a shared TOML configuration across OpenAI local clients, and tight integration with the broader ChatGPT/Codex surface are decisive [2, 7].
  • Claude Code is attractive when its current breadth of hooks, fine-grained permission grammar, explicit auto-memory and agent configuration, or deployment through Anthropic and supported third-party provider environments matches organizational needs [13, 10, 11].
  • Either can be the wrong choice when a deterministic workflow, conventional static tooling, or a single model call solves the task more cheaply. Anthropic’s own agent guidance recommends adding agentic complexity only when simpler systems fall short [15].

These are fit hypotheses to test, not purchasing verdicts.

The durable comparison

Codex and Claude Code are converging agent platforms with different defaults and control-plane details. Their model quality, feature surface, and documentation will continue to trade places. A useful comparison survives that motion by asking:

  1. What state does the model observe?
  2. Which actions are technically possible?
  3. Which actions require accountable approval?
  4. Where does execution occur?
  5. Which extension code runs outside the agent boundary?
  6. How do instructions, memory, and subagent state persist?
  7. What evidence reaches review?
  8. What does the organization spend to obtain an accepted change?

The answer is unlikely to be one permanent winner. It may be one product for local pairing, another for a specialized agent service, both behind shared repository standards, or neither for a high-consequence transition. The technically serious choice is the one justified by equivalent authority, representative work, and measured outcomes.