[CLI] GPT-5.5 forces MultiAgentV2 despite disable and hides documented custom-agent controls

[Alek2077]

What version of Codex CLI is running?

codex-cli 0.142.5

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.5

What platform is your computer?

Linux 6.18.33.2-microsoft-standard-WSL2 x86_64 x86_64

What terminal emulator and version are you using?

VS Code 1.127.0 under WSL (Ubuntu 22.04); no terminal multiplexer.

Codex doctor report

codex doctor --json confirmed Codex 0.142.5, valid configuration, ChatGPT authentication, reachable HTTP/WebSocket endpoints, and gpt-5.5 as the configured model. The report's overall failure was caused by the expected side-by-side npm test executable differing from the global npm installation. The full report is omitted here because it contains local filesystem paths and unrelated local session inventory; it can be provided in redacted form if needed.

What issue are you seeing?

GPT-5.5 forces the MultiAgentV2 tool surface even when MultiAgentV2 is explicitly disabled in both config.toml and command-line overrides.

The effective feature listing says:

multi_agent       stable             true
multi_agent_v2    under development  false

Adding or removing those persistent [features] entries produces no observable difference in the tested sessions: fresh GPT-5.4 threads use V1 in either case, while fresh GPT-5.5 threads use V2 in either case. The entries are accepted by configuration loading and reflected by features list, but multi_agent_v2 = false is not effective for GPT-5.5.

The current model catalog says:

gpt-5.5       multi_agent_version: v2
gpt-5.4       multi_agent_version: null
gpt-5.4-mini  multi_agent_version: null

In a fresh GPT-5.5 thread, spawn_agent exposes the V2 parameters task_name, message, and fork_turns. A V1 call fails with:

failed to parse function arguments: missing field task_name

Changing that existing thread from GPT-5.5 to GPT-5.4 does not change its tool surface; it remains V2. In contrast, a fresh GPT-5.4 thread exposes the V1 schema and successfully spawns gpt-5.4-mini with an explicit reasoning effort.

This matches the 0.142.5 implementation: model_info.multi_agent_version takes precedence over config.multi_agent_version_from_features() and the selected version is pinned to the thread:

https://github.com/openai/codex/blob/rust-v0.142.5/codex-rs/core/src/session/mod.rs#L2954-L2968

This makes the local feature listing misleading for GPT-5.5 and prevents users from following the published recommendation not to use MultiAgentV2 while it remains under development.

It also removes documented custom-agent functionality. The current Subagents documentation says Codex identifies custom agents by their name, and that agent files may pin model, model_reasoning_effort, sandbox_mode, and developer_instructions:

https://developers.openai.com/codex/subagents

For example, valid personal profiles named reviewer and harness_reviewer exist under ~/.codex/agents/. In a fresh GPT-5.4/V1 thread, spawning agent_type: "harness_reviewer" succeeded and returned role harness_reviewer, displayed model gpt-5.4, displayed reasoning effort medium, and the expected child response. In a GPT-5.5/V2 thread, the callable schema does not expose agent_type, model, or reasoning_effort. A task named reviewer is only a generic task identifier and does not activate the configured reviewer profile. The profile's pinned model, reasoning effort, read-only sandbox, and developer instructions therefore cannot be selected through the available tool surface.

Operational impact

• Users selecting GPT-5.5 cannot opt out of an implementation the same CLI still labels under development, even with both persistent and command-line disables.
• features list reports V2 as disabled while the active GPT-5.5 thread uses V2, so the reported feature state does not describe effective behavior.
• Documented custom reviewer profiles cannot be selected, including their pinned model, reasoning effort, sandbox policy, and developer instructions.
• A reproduced V2 child run failed during encrypted communication, so this is not only a schema or presentation difference.
• Switching an affected thread from GPT-5.5 to GPT-5.4 does not recover V1 because the selected multi-agent version remains pinned to that thread.

What steps can reproduce the bug?

1. Configure:

   [features]
   multi_agent = true
   multi_agent_v2 = false

2. Launch Codex 0.142.5 normally with GPT-5.5:

   codex -m gpt-5.5

3. Observe that the persistent multi_agent_v2 = false setting does not change the GPT-5.5 tool surface.

4. As an independent confirmation, launch with explicit command-line overrides:

   codex -m gpt-5.5 -c 'features.multi_agent_v2=false' -c 'features.multi_agent=true'

5. Ask Codex to list the exact spawn_agent schema, or call it with V1's fork_context argument.

6. Observe that both launch paths require V2's task_name and fork_turns, despite the persistent and command-line disables.

7. Run codex debug models and observe that GPT-5.5 carries multi_agent_version: v2 while GPT-5.4 does not.

8. Start a fresh GPT-5.4 thread with the same feature configuration and observe that V1 works normally, including selection of a configured harness_reviewer profile with its pinned GPT-5.4 medium settings.

What is the expected behavior?

An explicit local features.multi_agent_v2=false should take precedence over model metadata. If GPT-5.5 cannot operate with V1, Codex should reject the incompatible configuration or clearly warn that selecting GPT-5.5 overrides the local setting and mandates an under-development feature. features list should report the effective per-model behavior rather than saying V2 is disabled while the active thread uses it.

If GPT-5.5 must use V2, the V2 tool surface should retain the documented ability to select custom agents and their configured model, reasoning, sandbox, and instructions, or the documentation should clearly disclose that these capabilities are unavailable with GPT-5.5.

Additional information

This is related to, but distinct from:

• MultiAgentV2 encrypted spawn_agent schema returns 400: model not configured for encrypted tool use #26753: encrypted MultiAgentV2 schema/backend failures.
• Regression: encrypted MultiAgentV2 messages remove readable task audit trail #28058: encrypted V2 messages remove the readable local delegation audit trail.
• Encrypt multi-agent v2 message payloads #26210: the encryption implementation.

When V2 metadata was explicitly exposed during testing, a spawned GPT-5.4-mini child also failed with:

stream disconnected before completion: Encrypted function output content could not be decrypted or decoded

The central issue here is configuration precedence: GPT-5.5 makes V2 effectively mandatory even though the CLI still labels V2 under development.

[spadaval]

GPT-5.5 no longer has a defined multi_agent_version, so this is likely out of date.

But, GPT-5.6-Sol does, so the broader point is still true.

[ignatremizov]

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.

[antoinezambelli]

Additional deterministic reproduction from Codex CLI/TUI 0.144.1. This appears to narrow the model-switch behavior to the first submitted turn, rather than session creation, dropdown selection alone, or MCP initialization.

Environment

• Codex package: 26.623.19656.0 x64
• CLI/TUI: codex-cli 0.144.1, originator codex-tui
• OS: Windows 11 Home x64, build 26200
• Provider: openai
• Launch: codex --yolo (approval_policy=never, sandbox=danger-full-access in rollouts)
• Default config: model = gpt-5.6-sol, model_reasoning_effort = high
• No explicit multi-agent override in config.toml
• codex features list: multi_agent=true, multi_agent_v2=false
• Current catalog: Sol=v2, Terra=v2, Luna=v1, GPT-5.5 has no multi_agent_version

Personal TOML roles used as controls:

• cheap_explorer: gpt-5.6-terra, medium, read-only
• ticket_worker: gpt-5.6-sol, high, workspace-write

Session 1: first submitted turn on GPT-5.5

Session 019f4a75-8d31-7620-8be5-fae49ac41a39:

1. Launch codex --yolo, initially showing the default GPT-5.6-Sol.
2. Switch to GPT-5.5 before submitting a prompt.
3. First recorded turn_context: model=gpt-5.5, multi_agent_version=v1.
4. Custom agents are visible. cheap_explorer is dispatched through multi_agent_v1.spawn_agent(agent_type=cheap_explorer).
5. Child 019f4a77-1e18-7a90-a8a8-677e83512996 records agent_role=cheap_explorer, model=gpt-5.6-terra, effort=medium, matching its TOML.
6. Switch the parent to GPT-5.6-Sol. Subsequent parent turns record model=gpt-5.6-sol, but remain multi_agent_version=v1.
7. Custom agents remain visible. ticket_worker is dispatched through multi_agent_v1.spawn_agent(agent_type=ticket_worker).
8. Child 019f4a7b-0dda-7a90-bcf4-f86f938992e9 records agent_role=ticket_worker, model=gpt-5.6-sol, effort=high, also matching its TOML.

Session 2: no submitted turn while GPT-5.5 is selected

Session 019f4a7b-c48d-7e00-b0bd-32ccb4899ca2:

1. Launch on GPT-5.6-Sol.
2. Switch to GPT-5.5, then switch back to Sol without submitting a turn on GPT-5.5.
3. The dropdown-only changes produce no rollout turn/settings events.
4. First submitted turn records model=gpt-5.6-sol, multi_agent_version=v2, multi_agent_mode=explicitRequestOnly.
5. Custom agents are not exposed.

Session 3: commit one ordinary GPT-5.5 turn first

Session 019f4a7c-bc64-7163-aff8-62546ade4e0a:

1. Launch on GPT-5.6-Sol and switch to GPT-5.5.
2. Submit hi and receive the reply.
3. First recorded turn is model=gpt-5.5, multi_agent_version=v1.
4. There was no tool call or MCP event during this turn; it was an ordinary model response.
5. Switch to GPT-5.6-Sol.
6. Subsequent turns record Sol but remain multi_agent_version=v1.
7. cheap_explorer successfully dispatches through multi_agent_v1.spawn_agent; child 019f4a7e-7a95-7883-9f38-1932ad75be6e again records Terra/medium and the correct custom role.

Inference from the three controls

The reproducible rule appears to be:

first actual turn on GPT-5.5 -> thread selects/pins V1 -> custom TOML roles survive later switch to Sol
first actual turn on GPT-5.6-Sol -> thread selects/pins V2 -> custom role selector is hidden

So the apparently relevant hi is not initializing MCP. It commits the first GPT-5.5 turn and causes the thread to select V1. Model dropdown changes before any submitted turn do not appear to initialize or change the multi-agent version.

This also gives a stronger control for the custom-agent portion of this issue and the tool-backed mismatch in #15250: TOML discovery, role resolution, and role-specific child model configuration all work when the thread selects V1. The missing capability is specific to the Sol-selected V2 tool surface.

I can provide sanitized rollout excerpts if useful.

[dupu222]

I can reproduce this on macOS arm64 with Codex CLI 0.144.1, and the impact also includes agent-scoped MCP configuration.

Environment

• Codex CLI: codex-cli 0.144.1
• Platform: Darwin 25.5.0 arm64
• Model: gpt-5.6-sol
• codex features list reports:
  • multi_agent = true
  • multi_agent_v2 = false

Reproduction

I have two valid personal custom agents under ~/.codex/agents/:

1. A documentation agent with a stdio Context7 MCP server.
2. An issue-tracking agent with an HTTP MCP server.

Sensitive command arguments, URLs, headers, and credentials are omitted.

Both custom agent TOML files parse successfully and declare name,
description, developer_instructions, and agent-specific mcp_servers.

The Context7 MCP server itself was tested independently using only
initialize and tools/list:

INIT_OK True
TOOLS_LIST_OK True
TOOL_NAMES ['query-docs', 'resolve-library-id']

However, when Codex delegates through the V2 subagent tool surface:

spawn_agent(task_name, message, fork_turns)

the resulting child is generic:

multi_agent_version = "v2"
agent_role = null

The child tool registry contains no Context7 MCP tools. The same behavior occurs
with the HTTP-backed custom agent: its agent-specific MCP tools are absent and
no request reaches that MCP server.

Using the custom agent name as task_name only changes the task path; it does
not resolve or apply the custom agent TOML.

Expected behavior

The current Subagents documentation says custom agent TOML files are loaded as
configuration layers for spawned sessions and may contain mcp_servers.

Selecting a custom agent should therefore apply:

• developer_instructions
• sandbox/model settings
• agent-specific mcp_servers
• non-null agent role metadata

Actual behavior

The V2 tool surface provides no custom-agent selector. The spawned child records
agent_role = null, inherits generic parent behavior, and does not load the
agent-specific MCP configuration.

This confirms the issue on macOS arm64 and shows that the regression affects
agent-specific tool isolation in addition to model/reasoning configuration.