›_ Codex Issues
Codex Issues / #27331

0.137.0 (ChatGPT account): multi_agent_v2 enabled in config.toml breaks every turn with spawn_agent encrypted-tools 400

Open 💬 4 comments Opened Jun 10, 2026 by MumuTW
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.5 with model_reasoning_effort=high

Config snippet (relevant)

[features]
multi_agent = true

[features.multi_agent_v2]
enabled = true
max_concurrent_threads_per_session = 10000

I do not recall manually enabling multi_agent_v2; it may have been added during a recent CLI/Desktop upgrade (similar reports in openai/codex#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 = false

Legacy multi_agent (v1) subagent flow works after disabling v2.

Expected behavior

Either:

  1. The active model/backend supports MultiAgentV2 encrypted tool schemas, or
  2. Codex should not expose encrypted v2 tools (spawn_agent, send_message, followup_task) unless the backend is configured for encrypted tool use, or
  3. Upgrades should not silently enable multi_agent_v2 while the feature is still under development and incompatible with ChatGPT-account backends.

At minimum, enabling multi_agent_v2 should not make unrelated prompts fail at request validation time.

Related issues

  • openai/codex#26753 (closed as v2 not taking bug reports yet — but issue still affects stable users whose config has v2 enabled)
  • openai/codex#27205 (same root cause, followup_task variant on 0.138.0)
  • openai/codex#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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #26753
  • #27205
  • #27260

Powered by Codex Action

Fearvox · 2 months ago

Same here, looks like someone fat-fingured...

Fearvox · 2 months ago
Same here, looks like someone fat-fingured...

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 · 2 months ago

This looks related to #26753, #27205, and #27260: the same #26210 MultiAgentV2 encrypted-tool capability failure. When multi_agent_v2 is enabled, Codex exposes encrypted spawn_agent / followup_task tool 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:

codex --disable multi_agent_v2
# or for exec:
codex exec --disable multi_agent_v2 ...

Workaround for Codex App users:

  1. Quit Codex App completely.
  2. Edit your Codex config:
# macOS/Linux: ~/.codex/config.toml
# Windows: %USERPROFILE%\.codex\config.toml
[features.multi_agent_v2]
enabled = false
  1. Reopen Codex App and start a fresh thread/session.

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_task schemas. 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.