Root agent gets stuck emitting `wait` instead of a requested second `spawn_agent` call

Open 💬 3 comments Opened Jul 27, 2026 by Userchenentao5

What version of Codex CLI is running?

codex-cli 0.145.0

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Windows, Codex Desktop, PowerShell.

What happened?

After one successful typed subagent delegation, the root agent became stuck selecting the wait tool when it was explicitly asked to spawn a second typed subagent.

The first delegation worked. The full rollout contained a normal call similar to:

response_item.type = function_call
response_item.name = spawn_agent
arguments.agent_type = custom-planner
arguments.task_name = plan_task
arguments.fork_turns = none

Later, the user explicitly requested a second typed checker subagent. The assistant said it was starting that subagent, but the full session rollout recorded wait, not spawn_agent:

response_item.type = function_call
response_item.name = wait
arguments.cell_id = wrong
arguments.yield_time_ms = 1000

The tool then correctly returned:

exec cell wrong not found

This repeated many times with placeholder cell IDs such as wrong, dummy, x, and not-a-cell. Repeating the user request in a fresh turn did not recover tool selection. No second spawn_agent function call, child-start activity, or child thread appeared in the full rollout.

The typed subagent facility itself was available: the earlier spawn_agent succeeded in the same session. The visible schema required task_name; an initial call without it failed as expected, and retrying with task_name succeeded.

This is distinct from #34919. In #34919 the subagent genuinely spawns and the full rollout contains the spawn, while the public exec JSON stream omits it. Here the full rollout itself contains an incorrect wait function call and no second spawn occurred.

Steps to reproduce

Start a Codex Desktop task with typed custom agents available.
Call spawn_agent with agent_type, task_name, and fork_turns: none.
Wait for a relatively long-running child, including one or more wait_agent timeouts.
After the child completes, explicitly request a second typed subagent with a different agent_type and task_name.
Inspect the full session rollout under the Codex sessions directory.
Observe that subsequent attempted delegation may be emitted as function_call.name: wait with a nonexistent cell_id, and repeated requests do not recover.

I do not yet have a minimal deterministic reproduction outside the long conversation, so this may be model tool-call perseveration, app-side tool selection/serialization state, or interaction between the two.

Expected behavior

An explicit request to start the second typed subagent should emit a spawn_agent function call, or return a concrete spawn_agent validation/runtime error.

The root agent should not silently substitute the unrelated exec-cell wait tool, especially with a nonexistent placeholder cell_id.

Privacy note

All agent names, task names, paths, session identifiers, call identifiers, repository details, provider details, and timestamps above are sanitized or omitted. No credentials or user data are included.

View original on GitHub ↗

3 Comments

chen-006 · 1 month ago

I can independently reproduce this issue.

Environment:

Windows, Codex Desktop and standalone CLI
gpt-5.6-sol
Agent V2 / collaboration.spawn_agent
Reproduced on CLI 0.145.x and 0.146.x
Reproduced after Desktop/CLI rollback
Reproduced with a clean CODEX_HOME and the default 4-agent limit
Reproduced on different subscription accounts, including Pro
A separate user also reproduced it independently

Observed behavior:
An explicit request to create multiple subagents may produce one valid
spawn_agent call, but subsequent spawn attempts are emitted as unrelated
exec, wait, or shell_command calls.

Examples include:

exec("noop")
exec("spawn next")
wait with nonexistent placeholder cell IDs
shell_command("Write-Output noop") when Code Mode is disabled

The full rollout confirms that these incorrect tool names are present in
the model response. The client is not rewriting spawn_agent into exec/wait.

Control:
An older successful Agent V2 thread produced 17/17 spawn -> spawn
transitions. Six auditable Sol failure threads after July 26 produced 0
successful spawn -> spawn transitions.

Request comparison:

Same model: gpt-5.6-sol
Same collaboration developer instructions
Same multi_agent_mode instructions
Same additional_tools schema
Same tool schema SHA-256:

368790919f2e5fce565b212b84098e9d1ea1db401320b69334006da446895c62

Example failing server request IDs:

6e668d47-662d-4cc8-b177-c6c2a2ecd6ce
ecbdb7fc-2b02-48da-8e08-00a4ce7c5e41

This appears to be a regression in the Agent V2 consecutive collaboration
tool-selection / recipient-routing path, rather than a spawn executor,
configuration, concurrency-limit, or client-version failure.

Jeze-T · 1 month ago

I observed a closely related failure on Codex CLI 0.145.0 with
gpt-5.6-sol on Linux, using a custom Responses-compatible provider.

After successful subagent activity, explicit requests to dispatch or inspect
another agent were emitted in the full rollout as unrelated tool calls. Two
examples were:

name: exec
input: text("dispatch second");

name: exec
input: text("spawn fresh agents instead of cross-session followup");

I also observed repeated selection of get_goal or the exec-cell wait tool
while the intended action was an agent-management call.

The Codex router appears to preserve the model-emitted tool name
(ToolName::new(namespace, name)), so this does not look like a correct
spawn_agent call being rewritten by the dispatcher. No child thread was
created for these calls.

This is the same class of symptom as #35541, although the incorrectly selected
tool and provider differ. I do not yet have a deterministic minimal repro.
I can provide sanitized rollout excerpts if useful.

skiuniverse · 1 month ago

I encountered the exact same issue using gpt-5.6-sol on codex-cli version 0.145.0 (it just appeared today; the problem did not exist last Friday).

The agent’s hallucinations progressively worsen during a cycle of repeated wait and exec errors, though it seems to briefly return to normal after receiving genuine feedback from a sub-agent.

I tried switching to the third-party multi-agent solution provided by Orca and found that the issue disappeared. Therefore, the problem likely stems from Codex's own multi-agent implementation.