🩹 All GPT-5.6 Sol turns fail because MultiAgentV2 uses reserved collaboration.spawn_agent

You can do this to stay on v1:

# ~/.codex/config.toml
model_catalog_json = "~/.codex/models-v1.json"

[features]
multi_agent = true
multi_agent_v2 = false

Then create ~/.codex/models-v1.json from the current model catalog and change only these fields:

"slug": "gpt-5.6-sol",
"multi_agent_version": "v1"

and optionally:

"slug": "gpt-5.6-terra",
"multi_agent_version": "v1"

You can also optionally instead set version as "null" for all three Sol, Terra, and Luna, so that multi-agent schema version is defined by features config, not model catalog, but that's up to you.

Confirmed: this issue also affected a Codex Desktop setup using a third-party Responses-compatible proxy.

For fresh GPT-5.6 Sol/Terra tasks, an ordinary prompt failed before inference with a proxy-facing 502 Bad Gateway. The proxy masked the upstream validation error, so the useful signal was only visible by replaying the exact request body.

I isolated the failure with A/B tests against the same recorded request:

• Keeping the generated additional_tools namespace named collaboration returned 502.
• Keeping collaboration but setting its tools array to [] still returned 502.
• Removing the namespace entirely returned 200.
• Keeping every tool and changing only the namespace name from collaboration to agents returned 200.

That confirms the collision is caused by the reserved collaboration.* namespace itself, not by a particular child tool schema or the request size.

Applying this workaround fixed new Codex Desktop tasks after a full restart:

[features.multi_agent_v2]
enabled = false
tool_namespace = "agents"

Existing tasks retained their original tool snapshot and continued to fail; newly created tasks succeeded. This is a strong match for the reserved-schema collision described in the issue.

The codebase also has tests validating that the "agents" namespace works, which leads me to believe that that was always the intended namespace, but that refactor never happened.

@jschyz fyi disabling multi_agent_v2 does nothing, as the codex CLI currently ignores this flag if the model catalog defines a value (which it does for Terra/Sol).
I've generally found multi_agent_v2 to be pretty good and I wouldn't recommend disabling it.

Note that you may also want to set this flag to avoid a certain insidious class of subagent delegation bug:

[features.multi_agent_v2]
hide_spawn_agent_metadata = false

Reference #31814 for more on that.

Confirmed on Windows x64 with Codex App 26.707.9981.0 and Codex CLI 0.144.1.

With multi_agent = true, both gpt-5.6-terra and gpt-5.6-sol failed before inference with the exact reserved collaboration.spawn_agent schema error. The same failure reproduced with the 0.144.4 binary.

Adding only this configuration, while keeping multi-agent enabled, fixed both models in a local Codex CLI request:

[features.multi_agent_v2]
tool_namespace = "agents"

The Codex App was restarted to load the same configuration. This confirms the collaboration namespace collision and the agents namespace workaround on a native Windows setup.

Confirmed on Codex for iOS (2026-07-26). An ordinary prompt failed before inference with this exact response:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "Invalid Value: 'tools'. Function 'collaboration.spawn_agent' is reserved for use by this model and must match the configured schema.",
    "param": "tools"
  },
  "status": 400
}

The pr #29067 (tool_namespace: None changed to Some("collaboration"), with the previously-configurable features.multi_agent_v2.tool_namespace removed) appears to be the root cause of a recurring class of bug reports since it merged.

Any provider that reports namespace_tools: true (the default for everything except Bedrock) now has its multi-agent-v2 tools force-wrapped under the collaboration namespace, which requires the model/backend to emit a genuine structural namespace field on function calls - something most non-OpenAI-hosted models/servers (and even some OpenAI-hosted configurations on non-ChatGPT backends) don't produce.

I confirmed this with a direct before/after test: same custom OpenAI-compatible provider, same open-weight model (Qwen3.8-27B), same prompt.

• codex-cli 0.142.0 (last stable release before the PR merged): spawn_agent / wait_agent / list_agents are called flat, all succeed, and the subagent actually runs and replies.
• Current builds (0.147.0+): the exact same setup produces ERROR: unsupported call: collaboration.spawn_agent, because the model has no way to emit the namespace field this now requires.

Open-weight models such as Qwen (and presumably any other model/server not specifically fine-tuned on this namespace-grouped tool-call convention) can no longer use multi-agent-v2 at all, even when tool-calling otherwise works fine for that model (flat tools like shell_command and update_plan are unaffected).

Since tool_namespace was removed as a config surface, there's no way to opt back out to flat tool names to restore compatibility.

Also issue #31882.

Would it make sense to reintroduce a way to disable namespace wrapping (or gate it on a provider capability that reflects actual namespace-tool-call support, not just "is not Bedrock") so non-namespace-capable providers/models can keep using flat multi-agent-v2 tool names?