Running Claude Code and Codex in the Same Squad

What happens when you run Claude Code and Codex together

Say you have spent twenty minutes in Claude Code working out why a payment webhook retries twice for one customer and never for another. It took reading three files and comparing two code paths, and the answer turned out to be small: an idempotency key gets set after the database write instead of before it. The fix itself is a few lines. The codebase has forty other webhook handlers written the same way, though, and applying the same fix to all of them is a long, mechanical job.

You open a second terminal and start Codex, because it is the tool you reach for on repetitive, well-specified work, and you tell it to apply the same fix everywhere else. Codex has never seen the twenty minutes of reasoning that got you to the fix. It only has the code in front of it and whatever you type into this new conversation. That is the real trouble with running Claude Code and Codex together: not that either tool is weak, but that nothing either one worked out follows it into the other's session.

What Claude Code documents about delegating work

Claude Code ships two ways for one session to delegate inside itself. A subagent starts with a fresh, isolated context window unless the conversation is explicitly forked into it, and which model it runs on resolves in order: the parameter passed with that one call, then the model field in the subagent's own frontmatter (sonnet, opus, haiku, fable, a full model id, or inherit), then the CLAUDE_CODE_SUBAGENT_MODEL environment variable, then whatever model the main conversation is using.

Agent Teams is the second mechanism, and it works differently: experimental and off by default, it puts one lead session and several teammate sessions on a shared task list, able to message each other, with each teammate keeping its own context window.

• By default, up to 20 subagents can run at once, and subagents can nest up to 3 layers deep.
• A subagent's own requests count against the same usage limit as the conversation that spawned it, so delegating does not buy a second budget.
• Both subagents and Agent Teams are documented, real and useful, and both only ever start another Claude Code session.

What Codex documents about delegating work

Codex CLI ships a comparable idea from its own side. Subagent workflows are enabled by default through an [agents] table in config.toml, a Codex subagent can follow delegation instructions written into AGENTS.md, and Codex spawns these in parallel rather than one at a time.

Codex's own documentation is specific about which work suits a subagent. It recommends subagents for read-heavy work to avoid what it names, directly, as 'context pollution' and 'context rot'. It also warns, in its own words, that parallel write-heavy work 'can create conflicts'.

• Codex's [agents] table in config.toml is on by default.
• A Codex subagent reads delegation instructions from AGENTS.md, the same file a human maintains.
• Codex's docs recommend subagents for read-heavy work and warn that write-heavy parallel work can create conflicts.

Why CLAUDE.md and AGENTS.md don't fix this

The obvious objection is that AGENTS.md already solves this: one instruction file, several agents reading it. It genuinely fixes the easy half of the problem. AGENTS.md is a cross-tool convention, stewarded by the Agentic AI Foundation under the Linux Foundation, and read by a growing list of coding agents and tools, Codex among them. Claude Code has caught up too: since version 2.1.277 it reads a project's AGENTS.md directly when there is no CLAUDE.md on the path, so a repository already set up for one tool works for the other without a second file.

That covers what somebody wrote down before either agent started. It does not cover what either agent worked out while it was running. Claude Code keeps its own session learnings in auto memory, a set of files stored under its own project directory that Codex has no way to open, and that even a second Claude Code subagent does not inherit automatically from the session that spawned it. Codex keeps whatever it worked out inside its own session, with no equivalent handed anywhere else. A shared instructions file gives both agents the same rules. It does not tell either one what the other just found out.

• AGENTS.md is a cross-tool convention read by more than twenty coding agents and tools, Codex among them.
• Claude Code reads a project's AGENTS.md directly since version 2.1.277, when no CLAUDE.md is on the path.
• Claude Code's own session learnings live in auto memory under its own project directory, closed to Codex.
• A shared instructions file does not carry what either agent worked out mid-session.

What has to live outside both vendors

Once the written rules are shared, what is left is the plan itself and the running list of who is doing what, and that has to live somewhere neither vendor's tool owns, or a job split between two vendors collapses back into you relaying messages by hand.

The free version of this is a plain file in the repository: before either agent starts, have it write down what it intends to do, what it ruled out, and why, so the next agent, whichever vendor it is, can read it cold instead of being told it conversationally.

Forkbench is a desktop app that runs coding agents in a terminal on your machine, and its board is the tooled version of the same idea. Agents write tasks, progress notes and blockers to it, and it is written to disk, so it survives a closed pane, a context compaction, quitting the app and a reboot. A task on that board records no vendor, which is the specific thing that makes a cross-vendor squad work: a task is just a task, so a Codex session can claim one a Claude Code session wrote, and the other way round.

• A plan file written to the repository before either agent starts costs nothing and reads the same to any vendor.
• Forkbench's board is written to disk and survives a closed pane, a context compaction, quitting the app and a reboot.
• A task on the board records no vendor, so any agent can claim it, whichever one wrote it.

A job split between a Claude lead and a Codex helper

Go back to the webhook fix. On a Thread where you have allowed a Codex helper, so Squad is on, Claude Code stays the lead, because it already did the reading. It writes the real fix and one task to the board describing the pattern, the forty files that need it, and one example diff to copy. It calls a Codex helper for that task, because the job is now read-and-repeat rather than reasoning, which is exactly the shape Codex's own documentation recommends a subagent for.

The helper starts in its own session with no memory of the twenty minutes that found the bug, so it reads the task instead of being told it, applies the pattern across the other files, and reports the task finished, leaving a note on the board about two files that needed a small variation. That report moves the task to awaiting acceptance, not done, because no agent can verify its own work and no tool lets an agent raise its own rank. A human reads the diff and accepts it.

The lead never had to paste its reasoning into Codex's prompt, and Codex never had to guess at a decision Claude Code had already made out loud. Swap the direction and it still works: a Codex lead on a broad, well-specified rename can call a Claude Code helper for the one call site that genuinely needs judgment, because a helper is just a name and the command that starts it, so either vendor can be the one giving out the work.

• A helper is a name plus the command that starts it, so any agent you can launch from a command qualifies, Claude Code, Codex, or otherwise.
• A lead agent can suggest a helper it wants, but nothing is added until a human approves it.
• A claimed task is a lease: closing the helper's pane releases it at once, and a 120-second heartbeat is the backstop if the helper is alive but stuck.
• A report of finished moves a task to awaiting acceptance, not done, until a human accepts it.

When it is still one agent's job

None of this argues for splitting every task across two vendors. The webhook fix worked as a split because the mechanical part was genuinely separable from the part that needed reasoning about the bug. A single, tightly coupled change, say a function signature changing in a way that touches both the caller's logic and the test for it, is usually faster and safer with one agent carrying the whole thing in its head, because splitting it just recreates the handoff problem inside one task.

The honest version of running two vendors together is deciding, task by task, whether the work actually splits cleanly. When it does, write it down somewhere neither vendor owns and let whichever agent is better suited pick it up. When it does not, running two agents on it buys two partial views of the same problem instead of one complete one.