Repository navigation
Windows: multi_agent_v2 breaks custom Responses provider in Codex 0.139.0 #27339
Description
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;
SessionStarthook 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
- Install Codex CLI
0.139.0. - Configure a custom provider using
wire_api = "responses". - Enable:
[features.multi_agent_v2]
enabled = true- 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_v2with customresponsesproviders, or - ignore/disable the feature for unsupported providers with a clear error message.
Workaround
Set:
[features.multi_agent_v2]
enabled = falseAfter 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.txtThe output is:
OK
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
ignatremizov commentedon Jun 13, 2026
This looks like the same issue tracked in #27205 / #27331, originally reported in #26753.
Immediate workaround for new sessions:
or run Codex with:
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.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 encryptedspawn_agent/followup_tasktool 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.