Agent V2 regression: gpt-5.6-sol emits exec/wait instead of consecutive spawn_agent calls

Summary

Beginning around 2026-07-25, gpt-5.6-sol started failing a previously reliable Agent V2 workflow: creating multiple subagents consecutively from one root turn.

The first collaboration.spawn_agent call may succeed. When the root model should create the next subagent, the raw streamed response may instead select an unrelated tool:

• exec with placeholder code such as noop or spawn next
• wait with a nonexistent cell ID such as dummy, noop, or x
• shell_command with placeholder output when Code Mode is disabled

The assistant often says that it is creating another subagent, but no corresponding spawn_agent call is emitted. Repeating the request may produce the same incorrect tool choice indefinitely.

This is related to #35541, but this report has a broader and more repeatable control set. It reproduces in fresh tasks, clean CODEX_HOME environments, the default four-agent limit, multiple account contexts including Pro, and an independent user's environment.

Environment

• Platform: Windows
• Surfaces: Codex Desktop and standalone Codex CLI
• Model: gpt-5.6-sol
• Multi-agent backend: Agent V2
• Collaboration mode: explicitRequestOnly
• Tested CLI versions: 0.145.x and 0.146.x
• Responses API streaming
• tool_choice: auto
• parallel_tool_calls: false

The issue persisted after client rollback, application and OS restarts, restoring the initial configuration, creating fresh tasks, using isolated CODEX_HOME directories, generating a new installation ID, bypassing Desktop/AppX with an unpacked CLI, returning to the default four concurrency slots, and disabling Code Mode.

It also reproduced under a Pro account and in an independent user's environment.

Steps to Reproduce

1. Start a new task with gpt-5.6-sol.
2. Explicitly request several independent subagents in the same turn. For example:

``text
Create several subagents with different reasoning efforts. Have each
independently solve the same small arithmetic task. Create the agents
consecutively, then wait for all results and summarize them.
``

1. Inspect the full rollout rather than only the visible UI.
2. One spawn_agent call may succeed.
3. A subsequent intended delegation may be emitted as exec, wait, or shell_command with placeholder arguments.
4. Repeating the delegation request may continue producing unrelated tool calls without creating another child thread.

The original workflow requested nine or ten subagents, but high concurrency is not required. The failure also reproduces with the default four-slot limit.

Expected Behavior

The root model should emit another valid collaboration.spawn_agent call or return a concrete validation, capacity, or runtime error from spawn_agent. It should not silently substitute an unrelated execution or wait tool.

Actual Behavior

Older successful Agent V2 baseline:

spawn -> spawn -> spawn -> spawn -> spawn -> spawn -> spawn -> spawn -> spawn

Representative failing sequences:

spawn -> exec -> spawn -> exec -> exec -> spawn -> exec
spawn -> wait(dummy) -> wait(none) -> wait(noop) -> exec
spawn -> wait(empty) -> exec -> wait(x)
spawn -> shell_command("Write-Output noop")

The placeholder wait calls do not reference real execution cells. The tool correctly reports that the cell does not exist, after which the model may issue another placeholder call.

Quantitative Comparison

• Older successful Agent V2 baseline: spawn -> spawn transitions were 17/17.
• Six auditable failing Sol root tasks after 2026-07-26: spawn -> spawn transitions were 0.
• Disabling Code Mode did not fix the problem. It only changed the incorrect outlet from exec to shell_command.

Raw Response Evidence

The incorrect tool name and arguments are present directly in the raw streamed server response. The client is not converting a correct spawn_agent call into exec or wait.

Real spawn_agent calls can still succeed immediately before or after an incorrect selection, showing that the spawn executor and available collaboration slots remain functional.

Request-Level Control Comparison

A request following a successful spawn in the older baseline was compared with a request following a successful spawn in a failing task.

The following were identical:

• model, streaming, storage, tool-choice, parallel-tool, reasoning, and text settings
• input item count, types, and role ordering
• collaboration developer instructions
• multi_agent_mode instructions
• spawn_agent parameter schema and successful output structure
• the additional_tools set

Normalized SHA-256 of the complete additional_tools item:

368790919f2e5fce565b212b84098e9d1ea1db401320b69334006da446895c62

Normalized SHA-256 of static top-level POST fields after excluding input, client_metadata, and prompt_cache_key:

0a22ec6ea216fee21323a831ba86b5621a267546d9ce2fc035a513c73a09b318

The collaboration developer instructions and multi_agent_mode instructions were byte-for-byte identical. The HTTP 200 response-header field sets were also identical apart from dates and request identifiers.

Clean-State A/B Tests

Two isolated CLI environments were created using an unpacked older CLI. One reused the previous installation ID and the other generated a new ID. Both started with empty sessions, state, memories, goals, skills, and plugin caches; bypassed Desktop and AppX; and used the default four concurrency slots.

Both reproduced spawn_agent followed by incorrect wait or exec calls.

This rules out the original Codex home directory, installation ID, Desktop LocalState, AppX registration, old session state, plugin cache, fork behavior, and the custom ten-agent limit as necessary causes.

Root-Cause Assessment

The evidence establishes that:

1. The wrong tool choice exists in the raw streamed response before client execution.
2. The spawn_agent executor remains functional.
3. The collaboration schema and static request configuration match the successful baseline.
4. The failure survives fresh tasks, clean local state, client rollback, and independent account/user tests.
5. The affected behavioral boundary is consecutive collaboration tool selection in the Agent V2 request path used by gpt-5.6-sol.

This appears to be a regression introduced around 2026-07-25 in the Agent V2 root-model controller responsible for repeated collaboration tool choice or recipient routing.

Client-visible evidence cannot distinguish among a model checkpoint or alias update, Agent V2 tool-choice policy, recipient-constrained decoding, anti-loop policy, experiment cohort, or service-shard deployment. OpenAI internal tracing is required to identify the exact component.

Related Issues

• #35541 reports Sol emitting wait with nonexistent placeholder cell IDs instead of a requested second spawn_agent. This is highly similar.
• #35506 reports different custom-agent behavior between V1-root sessions and Sol/Terra tool-backed collaboration sessions. It is not the same bug, but it supports the V1/V2 boundary.
• #34301 documents the Sol/Terra V2 and Luna V1 backend mapping. It is mapping evidence, not an identical wrong-tool-selection report.

Requested Investigation

Please inspect the model checkpoint or alias target, Agent V2 tool-choice and recipient-routing decisions, constrained-decoder configuration, anti-loop policy, experiment assignments, service shard, and Agent V2 policy deployments around 2026-07-25.

Server request IDs and sanitized trace correlation have been submitted privately to OpenAI Support. I can provide minimal sanitized rollout excerpts to an OpenAI maintainer if required.