Codex Multi-Agent V2: What Changed for Sub-Agent Delegation and GPT-5.5

Codex CLI's newest delegation system arrived with an odd twist: it's not additive. Multi-Agent V2, shipped in Codex CLI version 0.145.0, restructures how one agent session hands work to sub-agents — and in the same release cycle, OpenAI pulled a model out of delegation entirely. If your feed showed you "Codex ships Multi-Agent V2 to enable delegation to v1-restricted models and GPT-5.5," the accurate version is closer to the reverse: V2 is a hierarchical delegation framework tied to specific frontier models, and it has been actively restricting which models can be delegation targets, not opening the door wider.

Here's what actually shipped, what broke, and how it stacks up against the subagent pattern explainx.ai already covers in Claude Code Subagents and Multi-Agent Workflows.

TL;DR

What Multi-Agent V2 actually changes

V1's delegation model was simple and a little crude: a flat list of opaque sub-agent IDs, a binary fork_context toggle (on or off), and an isolated git worktree per spawned agent. It worked, but it gave you no visibility into how sub-agents related to each other or to the parent thread.

V2, which shipped in Codex CLI version 0.145.0 (documented around July 22, 2026), replaces that with:

• A navigable task hierarchy. Spawned agents get canonical paths — /root/research/api is the example OpenAI's own docs use — instead of opaque IDs, so a parent-child relationship is visible and addressable.
• fork_turns instead of fork_context. V1 was on/off; V2 accepts "none", "all", or a specific recent-turn count, so a sub-agent can inherit exactly as much conversation history as its task needs.
• Split messaging. send_message (deliver information) is now separate from followup_task (trigger new work), plus mailbox waiting and mid-task interruption.
• Shared workspace, not isolated worktrees. V1 sub-agents worked in their own git worktree; V2 agents share the parent's workspace.

That's a genuinely more capable orchestration primitive — closer to a task-tree scheduler than a flat spawn list. The friction is in who gets to use it.

The model-gating problem

Multi-Agent V2 isn't opt-in per session — it's tied to the model you're already running. In Codex's tagged model catalog, GPT-5.5 and GPT-5.6 Sol/Terra select V2, while other models stay on V1. And per GitHub issue #31097, that assignment sits in model_info.multi_agent_version, which takes precedence over your local config — setting multi_agent_v2: false doesn't stop a GPT-5.5 thread from running V2 anyway. Once a thread starts on GPT-5.5, it's pinned to V2 for that thread's lifetime; switching the same thread to GPT-5.4 doesn't revert it.

That precedence bug is where "restricted" actually bites: V2's schema doesn't support the custom agent profiles V1 had. In V1 you could pin a named profile like harness_reviewer to a sub-agent type, carrying a specific model, reasoning effort, sandbox policy, and developer instructions. V2 replaced agent_type/fork_context with task_name/message/fork_turns — and per the same issue thread, that swap dropped the ability to select those custom profiles at all. You get the new hierarchy; you lose the pinned-model workflow.

Then came the second-order restriction: on August 16, 2026, developers reported (Hassan on X; GitHub issue #35097) that OpenAI removed GPT-5.6 Luna from V2's spawn_agent tool outright. Luna was the model teams reached for as the cheap, fast, high-volume delegation target — Codex's own docs describe it as built for "narrowly scoped agents handling clear, repeatable, or high-volume work." With Luna gone from V2, Multi-Agent V2 now supports only Sol and Terra as delegation targets. Two documented workarounds:

1. Set "multi_agent_version": "v1" explicitly in Codex config to force the old flat-ID system back on.
2. Phrase the request as "delegate new thread" rather than "delegate sub-agent" — developers report this routes around V2's spawn_agent path.

So the practical shape of the news is: a genuinely better delegation data model, shipped attached to a subset of frontier models, that has been actively losing model coverage rather than gaining it. If your reader was expecting "now Codex can delegate to more models," the accurate framing is "Codex changed which models it will delegate to, and it isn't more."

Why this matters if you're choosing a delegation model tier

Delegating to a cheaper, faster model for a bounded sub-task is the entire point of subagent patterns — you don't want your primary reasoning model burning tokens on a read-heavy file scan or a repetitive lint pass. Codex's own subagent docs frame it exactly this way: gpt-5.6-terra for "faster, lower-cost" exploration and document review, gpt-5.6-luna for "fast, narrowly scoped agents handling clear, repeatable, or high-volume work," and gpt-5.6 (full) for "ambiguous, multi-step work that needs planning, tool use, validation, and follow-through."

Losing Luna from V2 delegation doesn't remove that tier from Codex — it removes it from the new hierarchical delegation path specifically. Teams that built workflows around cheap Luna sub-agents inside Multi-Agent V2 threads now have to either force V1 (losing the task-tree benefits) or restructure delegation as separate threads instead of true sub-agents.

Token cost is the other half of the calculus explainx.ai has covered before with jcode's swarm coordination: every sub-agent spawned does its own model and tool work, so delegation workflows consume more tokens than a comparable single-agent run. That trade-off is worth it when the parallel or cheap-model work outweighs the overhead — and it's exactly why the model tier a sub-agent runs on matters as much as whether delegation exists at all.

How this compares to Claude Code's subagent pattern

explainx.ai has covered Claude Code's Agent tool and subagent delegation extensively, along with the newer cross-session messaging between Claude Code sessions. The structural difference from Codex's V1/V2 split is worth naming directly:

• Model choice stays with you. Claude Code's Agent tool lets you specify which model handles a given subagent call in the invocation itself — there's no separate delegation-framework tier that a primary-model choice silently forces you into.
• No config-override bug class. Because model selection for a subagent isn't gated by which "version" of a delegation system your primary model happens to be tagged for, there's no equivalent to Codex's multi_agent_v2: false setting being ignored for GPT-5.5 threads.
• Consistent behavior across sessions. A Claude Code subagent invocation behaves the same way regardless of which Claude model is running the parent session; Codex's V2 pinning means the same delegation request produces different available models and different schema depending on whether the thread started on GPT-5.4 or GPT-5.5.

That's not a knock on the underlying V2 data model — the task-hierarchy and fork_turns design is a real improvement over V1's flat IDs, and it's the direction most serious agent harnesses are heading. The lesson for practitioners is narrower: when a harness ties its newest orchestration primitive to a specific model tier, check whether your cheap-model delegation path survives the upgrade before you build a workflow on it.

What to do if you're on Codex today

• Check which model your thread is pinned to before assuming multi_agent_v2: false in config is doing anything — it isn't, for GPT-5.5 threads, per OpenAI's own tracker.
• If you rely on Luna for cheap sub-agent work, either force "multi_agent_version": "v1" or use "delegate new thread" phrasing until V2 restores Luna support.
• Don't build workflows around V1 custom agent profiles inside V2 threads — the schema doesn't carry them over yet.
• Track the open issues (#35097, #31097, #31864) if this is load-bearing for your setup — this is an actively-changing area of Codex, not a settled feature.

Related on explainx.ai

• Claude Code Subagents and Multi-Agent Workflows (2026)
• Claude Code cross-session messaging: sessions can now talk to each other
• Steering Claude Code: CLAUDE.md, Skills, Hooks, and Subagents
• Top 10 open & closed agent harnesses (2026)
• jcode agent harness: swarm coordination and memory graph
• OpenAI Codex Plugin for Claude Code — setup guide
• Codex crossed 15M users — Tibo's reset tease
• YC open-sources QM: company-wide multi-agent harness
• Dictionary: subagent
• Dictionary: multi-agent system

Sources

• GitHub issue #31097 — GPT-5.5 forces MultiAgentV2 despite disable
• GitHub issue #35097 — gpt-5.6-luna marked MultiAgent V1, V2 spawn_agent rejects it
• GitHub issue #31864 — MultiAgentV2 collaboration.spawn_agent conflict
• Hassan (@buildwithhassan) on X — Luna removed from Codex sub-agent delegation
• Codex Agents V2 in 0.145.0 — Oleh Vanin
• ChatGPT Docs — Subagents (agent configuration)

Version numbers, GitHub issue states, and workarounds reflect Codex CLI as reported through August 16, 2026. Multi-Agent V2 is an actively changing area of Codex — verify current behavior against ~/.codex/config.toml and the linked issues before building a production workflow on it.