Repository navigation
0.137.0 (ChatGPT account): multi_agent_v2 enabled in config.toml breaks every turn with spawn_agent encrypted-tools 400 #27331
Description
Summary
With features.multi_agent_v2.enabled = true in ~/.codex/config.toml, every Codex turn fails at API request validation before the model handles the prompt — even when the user does not ask to spawn sub-agents.
Error:
{
"type": "error",
"error": {
"type": "invalid_request_error",
"message": "Invalid Value: 'tools'. Function 'functions.spawn_agent' declares encrypted parameters but is not configured for encrypted tool use by this model.",
"param": "tools"
},
"status": 400
}This blocks codex exec background automation (e.g. dispatching Playwright test fixes) because the session never starts.
Environment
- Codex CLI:
0.137.0 - OS: macOS 25.5.0 (Darwin arm64, Apple Silicon)
- Auth: ChatGPT account (
codex login status— not API key) - Model:
gpt-5.5withmodel_reasoning_effort=high
Config snippet (relevant)
[features]
multi_agent = true
[features.multi_agent_v2]
enabled = true
max_concurrent_threads_per_session = 10000I do not recall manually enabling multi_agent_v2; it may have been added during a recent CLI/Desktop upgrade (similar reports in #27205).
Minimal repro
codex exec --ephemeral --skip-git-repo-check -C /tmp 'Reply exactly: DONE'Fails immediately with the spawn_agent encrypted-tools 400 above.
Workaround (confirmed locally)
Disable v2 for the invocation:
codex exec --disable multi_agent_v2 ...Or in ~/.codex/config.toml:
[features.multi_agent_v2]
enabled = falseLegacy multi_agent (v1) subagent flow works after disabling v2.
Expected behavior
Either:
- The active model/backend supports MultiAgentV2 encrypted tool schemas, or
- Codex should not expose encrypted v2 tools (
spawn_agent,send_message,followup_task) unless the backend is configured for encrypted tool use, or - Upgrades should not silently enable
multi_agent_v2while the feature is stillunder developmentand incompatible with ChatGPT-account backends.
At minimum, enabling multi_agent_v2 should not make unrelated prompts fail at request validation time.
Related issues
- MultiAgentV2 encrypted spawn_agent schema returns 400: model not configured for encrypted tool use #26753 (closed as v2 not taking bug reports yet — but issue still affects stable users whose config has v2 enabled)
- Invalid Value: 'tools'. Function 'functions.followup_task' declares encrypted parameters but is not configured for encrypted tool use by this model. #27205 (same root cause,
followup_taskvariant on 0.138.0) - Major Codex Desktop Regression Makes App Unusable. #27260 (Desktop regression, duplicate)
Impact
Production automation workflows that rely on codex exec (CI agents, Claude Code dispatch, scripted refactors) fail entirely when v2 is enabled — not just when spawning sub-agents.
Activity
github-actions commentedon Jun 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Fearvox commentedon Jun 12, 2026
Same here, looks like someone fat-fingured...
Fearvox commentedon Jun 12, 2026
For me this happens in Codex Desktop after update when the request includes functions.spawn_agent. New thread/model switch may work, but affected threads fail before assistant response. Seems related to multi_agent_v2 / encrypted tool-use capability gating.
ignatremizov commentedon Jun 13, 2026
This looks related to #26753, #27205, and #27260: the same #26210 MultiAgentV2 encrypted-tool capability failure. When
multi_agent_v2is enabled, Codex exposes encryptedspawn_agent/followup_tasktool schemas even if the active model/backend is not configured for encrypted tool use, so the request fails before the assistant can respond.Workaround for new CLI sessions:
Workaround for Codex App users:
If an existing thread still fails after disabling it, the config change is not enough for that old thread. Existing threads persist
multi_agent_version = "v2"in rollout history, so resumed old threads will keep sending the encrypted v2 tool schema even after the feature is disabled. That persistence/recovery case is discussed in #27205.For custom Responses providers, the same underlying problem applies: the active backend/model has to support encrypted tool use before Codex can expose the v2
spawn_agent/followup_taskschemas. This is tracked in #27339.Separate but related: #26210 also made v2 subagent task/message data unreadable in rollouts, which makes recovery/debugging harder when these failures happen. I opened #28058 for that auditability issue, please react if it affects your workflow.
feat(codex): enable multi_agent_v2; collapse duplicate degradations