Windows: multi_agent_v2 breaks custom Responses provider in Codex 0.139.0

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

Windows: multi_agent_v2 breaks custom Responses provider in Codex 0.139.0

Summary

After upgrading Codex CLI from 0.137.0 to 0.139.0, requests fail when using a custom OpenAI-compatible provider with wire_api = "responses" and features.multi_agent_v2.enabled = true.

Disabling multi_agent_v2 makes the same custom provider work again.

Environment

  • OS: Windows
  • Codex CLI: codex-cli 0.139.0
  • Provider: custom OpenAI-compatible provider
  • Wire API: responses
  • Model: custom model configured as gpt-5.5
  • Plugin state: issue occurs with user config loaded; SessionStart hook failure may also be displayed when a session-start plugin is enabled

Relevant config shape

model = "gpt-5.5"
model_provider = "custom"
model_reasoning_effort = "xhigh"

[features.multi_agent_v2]
enabled = true

[model_providers.custom]
name = "custom"
base_url = "https://<redacted>/v1"
requires_openai_auth = true
wire_api = "responses"

Reproduction

  1. Install Codex CLI 0.139.0.
  2. Configure a custom provider using wire_api = "responses".
  3. Enable:
[features.multi_agent_v2]
enabled = true
  1. Run:
codex exec --skip-git-repo-check "Reply OK"

Observed behavior

With the full user config and multi_agent_v2 enabled, Codex fails with one of these errors:

ERROR: {"error":{"message":"","type":"bad_response_status_code","param":"","code":"bad_response_status_code"}}

or:

ERROR: Reconnecting... 1/5
ERROR: Reconnecting... 2/5
ERROR: Reconnecting... 3/5
ERROR: Reconnecting... 4/5
ERROR: Reconnecting... 5/5
ERROR: stream disconnected before completion: stream closed before response.completed

When a SessionStart hook is enabled, the CLI may also print:

hook: SessionStart
hook: SessionStart Failed

However, manually running the hook exits successfully in under one second, so the hook appears to be a secondary symptom rather than the root cause.

Expected behavior

Codex should either:

  • support multi_agent_v2 with custom responses providers, or
  • ignore/disable the feature for unsupported providers with a clear error message.

Workaround

Set:

[features.multi_agent_v2]
enabled = false

After this change, the same installation and provider can successfully run:

codex exec --skip-git-repo-check -o $env:TEMP\codex-verify-last-message.txt "Reply OK"
Get-Content $env:TEMP\codex-verify-last-message.txt

The output is:

OK

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27331
  • #26753

Powered by Codex Action

ignatremizov · 2 months ago

This looks like the same issue tracked in #27205 / #27331, originally reported in #26753.

Immediate workaround for new sessions:

# ~/.codex/config.toml
[features.multi_agent_v2]
enabled = false

or run Codex with:

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

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.

If you still see the error after disabling it, start a fresh thread/session. Existing threads persist multi_agent_version = "v2" in rollout history, so resumed old threads will keep sending the encrypted spawn_agent / followup_task tool schema even after the feature is disabled. That persistence case is discussed in #27205.

Separate but related: #26210 also made v2 subagent task/message data unreadable in rollouts, which makes these recovery/debugging cases harder. I opened #28058 for that auditability issue, please react if this affects your workflow.