Skip to content
AgentThread
← All posts
Comparison#loop-engineering#claude-code#codex#agent-harness#developer-tools

Loop Engineering: Codex CLI vs Claude Code

Both harnesses run the same canonical loop. The interesting engineering — hooks, verifiers, execution locus, sandbox model — is where they disagree, and the disagreement tells you which tool fits which team.

AgentThread6 min read
Share

If you read the loop engineering post from earlier this week, the shape of the modern agent loop is settled: gather context, take action, verify work, repeat. What's not settled is the opinion layer above the loop — how each harness decides where the agent runs, what it's allowed to do, and who gets to intervene.

The two harnesses that matter most right now sit on opposite ends of that opinion axis. Claude Code, from Anthropic, treats the loop as a fine-grained pipeline running on the developer's machine, with 26 hookable events per turn. Codex CLI, from OpenAI, treats the loop as a fire-and-forget cloud task that ships with an OS-level sandbox and expects to run without you. Both are correct. They just make different bets about which trade-offs a serious team wants.

What each harness actually is

Both tools are coding-focused agent harnesses. Both run against frontier models (Claude Opus 4.7-4.8 and GPT-5.4-5.6 respectively). Both operate the same canonical loop underneath — a Composio deep-dive on Claude Code vs Codex traces both back to nearly identical Python-shaped pseudo-code: while needs_follow_up: history → model + tools → tool_calls → verify → continue or exit.

Where they stop resembling each other:

  • Execution locus. Claude Code runs on your machine, in your terminal, against your working copy. Codex CLI runs in cloud containers OpenAI manages — you kick off a task and disconnect; the task keeps running.
  • Sandbox layer. Claude Code enforces safety at the application layer via 26 programmable hook events (pre-tool, post-tool, pre-file-write, etc.) — fine-grained but developer-visible. Codex CLI enforces safety at the OS kernel layer using Seatbelt, Landlock, and seccomp — coarse-grained but harder to escape.
  • Verifier posture. Claude Code makes the verify step explicit and hookable, so the developer can inject a linter, a test run, or a custom check between actions. Codex CLI runs until the model returns text-only and considers that "done."
  • Tool discovery. Claude Code calls /mcp at runtime and reads live tool schemas — it writes against actual response shapes. Codex CLI reads static tool declarations.

What the loop actually does — side by side

Watch a serious contributor use each and the daily rhythm is different:

Claude Code: paste a bug into the terminal, watch the loop gather repo context (usually 2-6 files it decides are relevant), propose a change, prompt the developer to approve before writing, run the test suite, revise if red, prompt again, commit. The developer is in the loop by default; making it autonomous is a config choice.

Codex CLI: describe a task in one prompt, hit send, close the laptop. The cloud container clones the repo, runs the loop against a sandbox, opens a PR (or updates one), reports status when you re-check. The developer is out of the loop by default; making it interactive is a config choice.

Two harnesses. Two opposite defaults. The name of the discipline — loop engineering — hides a real architectural decision: is the loop primarily a programmable pipeline or a durable cloud task?

Why the disagreement matters

The old prompt-engineering framing was that the model is the product and the wrapper is incidental. Loop engineering rejects that. Both Anthropic and OpenAI have said, explicitly, that the wrapper is the product — the model is a component. What each ships as the "wrapper" reveals their assumptions.

  • Anthropic's assumption: the developer is present. Loops should be composable — hook a verifier here, gate a write there, block on approval when it matters. The 26-hook surface is that assumption made concrete.
  • OpenAI's assumption: the developer left. Loops should be durable — survive disconnects, run for hours, produce a PR at the end. The cloud container is that assumption made concrete.

Both cover the same theoretical ground. In practice, they build for different personas. A senior dev fixing bugs in her own repo wants Claude Code. A platform team dispatching background work to 40 agents at once wants Codex CLI.

The Firecrawl comparison of coding agents makes the practical case bluntly: "what makes a harness good or bad is the unglamorous stuff: context management, truncation, sandboxing, and error handling." Model quality is roughly a tie. Harness quality is where the deployment decision actually happens.

Where each is strongest — and the numbers

The public benchmark numbers as of mid-July 2026:

  • Terminal-Bench 2.0: Claude Code hits 92.1%; Codex CLI hits 77.3%. This benchmark leans on interactive fix-and-verify loops — Claude Code's home turf.
  • SWE-bench Verified: Claude Opus 4.8 reports 88.6%, the highest published figure among these agents. Codex on GPT-5.4-5.6 lands lower.
  • Context: Claude Code on Opus 4.7 exposes 1M tokens at standard pricing. Codex CLI on GPT-5.4 exposes up to 1.05M tokens with a 128K max output cap.

Numbers-only reading: Claude Code wins on interactive coding. Codex CLI wins on autonomous run duration (no comparable public number here — the "you can disconnect" property is the whole benchmark).

The Blake Crosley teardown adds the architectural point that's underappreciated: Codex CLI's cloud-container model means OpenAI is on the hook for the runtime — if it breaks, they fix it. Claude Code's local model means Anthropic ships the code and you own the runtime — if it breaks, you diagnose it. Enterprise procurement teams read that difference in opposite directions depending on their security posture.

How to evaluate which loop fits your team

Ignore the demos. Ask the same seven questions of each:

  • Is the developer in the loop or out of the loop by default? Not "can you configure it either way" — the default reveals what the tool was designed for. Match the default to your team's rhythm.
  • What's the verifier? Explicit and hookable (Claude Code) or implicit / model-decided (Codex CLI)? For any workflow that touches production code, "the model decided it was done" is not a satisfactory verify step.
  • Where does the sandbox live? Application-layer hooks give you fine-grained control but require developer discipline. OS-layer sandboxing gives you coarse control but is much harder for the model to escape.
  • Who owns the runtime? If the tool runs in the vendor's cloud, you pay in latency and lose local-only file access, but the vendor is on the hook for uptime. If the tool runs on your machine, you own everything, including the operational cost of debugging its runtime issues.
  • What happens when you disconnect? For any loop expected to run more than 30 minutes, this is the deciding question. Cloud-persistent loops are strictly better for long tasks. Local loops are strictly better for interactive ones.
  • How does the loop discover tools? Static declarations are simpler but rot. Live MCP discovery is more work upfront but writes against reality.
  • What's the cost accounting model? Per-token, per-turn, per-container-hour? Cloud loops can rack up container time even when the model is idle. Local loops only cost when the model runs.

The correct answer for most teams is not "pick one." It's: run Claude Code for interactive fix-and-review work, and dispatch Codex CLI for the multi-hour autonomous work that doesn't need supervision. The Composio 100-hour writeup and the Jock.pl harness comparison both land on the same "both, for different jobs" answer.

Loop engineering is the discipline. Claude Code and Codex CLI are two opinionated answers to the same design question. Knowing which one fits your team means knowing what you'd have decided if you'd been designing the wrapper yourself.