Repository navigation
MultiAgentV2: Ultra codex exec --ephemeral cannot find root thread, then exhausts agent slots #33672
Description
What version of Codex CLI is running?
codex-cli 0.144.5 (latest stable at the time of reproduction)
What subscription do you have?
ChatGPT-authenticated CLI. Plan tier omitted because this appears to be a local thread-lifecycle issue.
Which model were you using?
gpt-5.6-sol with model_reasoning_effort="ultra".
The model catalog selects MultiAgentV2 for this model. There was no [agents] or thread-limit override in the active user/project configuration.
What platform is your computer?
Debian GNU/Linux 13 (trixie), x86_64, kernel 6.12.95+deb13-amd64.
What issue are you seeing?
An Ultra headless run attempted proactive delegation. The JSON event stream first announced the root thread:
{"type":"thread.started","thread_id":"<root-thread-id>"}
{"type":"turn.started"}About 18 seconds later, Codex emitted this on stderr:
ERROR codex_core::tools::router: error=collab spawn failed: no thread with id: <same-root-thread-id>
Two later spawn attempts in the same turn then emitted:
ERROR codex_core::tools::router: error=collab spawn failed: agent thread limit reached
ERROR codex_core::tools::router: error=collab spawn failed: agent thread limit reached
The ID in the first error was the root ID already emitted by thread.started, not a missing child ID.
No successful spawn event appeared in the JSON stream. Later collaboration wait events had empty receiver_thread_ids and empty agents_states. Nevertheless, new spawns were rejected for reaching the agent-thread limit.
The root continued the audit serially and eventually emitted turn.completed; the process therefore succeeded despite losing the requested Ultra delegation behavior. Automation can only detect the degradation by inspecting stderr.
What steps can reproduce the bug?
This was observed while running a broad repository planning/audit prompt that naturally decomposed into parallel exploration:
codex exec \
--ephemeral \
--sandbox workspace-write \
-c 'approval_policy="never"' \
-c 'model_reasoning_effort="ultra"' \
--json \
- < planning-prompt.mdThe prompt asked Codex to inspect specifications, source, tests, and configuration, compare behavior with requirements, and update planning documentation. Ultra proactively attempted parallel delegation without an explicit spawn instruction.
Observed event ordering:
- Root
thread.startedwith ID A. - Root
turn.started. - Normal root agent message/todo and shell activity.
- Spawn failure:
no thread with id: A. - Two later spawn failures:
agent thread limit reached. - No successful child IDs in the event stream; later waits targeted no agents.
- Root continued serially and completed successfully.
I have not yet run a non-ephemeral comparison because an Ultra audit is expensive. Thus --ephemeral is part of the verified reproduction, but I am not claiming it is definitively the root cause.
What is the expected behavior?
- An ephemeral root thread should be registered with the collaboration router before the model can call the spawn tool.
- Ultra delegation should either spawn children or return one clear, structured failure without leaking/reserving agent slots.
- A failed parent lookup or failed initial message delivery should roll back any reserved residency/thread slots.
- If Codex falls back to serial execution, the JSON event stream should expose that degradation so headless automation does not report an unqualified success.
Additional information
The sequence looks related to, but distinct from:
- MultiAgentV2: queue-only message to a completed agent pins a residency slot #32353 — current MultiAgentV2 residency can produce
agent thread limit reached, but its trigger is a completed agent with queued mail. No child successfully spawned in this reproduction. - close_agent can hang forever after marking a subagent closed if the child thread never terminates #25426 and Completed subagents continue to count against thread limit #22779 — stuck/completed agents retain spawn slots.
- bug: Collab subagents leak spawn slots, lack cascading cancellation, and wait is wait-any #13947 — an older, closed report described a spawn reservation becoming permanent when initial input delivery fails after reservation commit. The
no thread→ immediate thread-limit progression here may indicate a similar path in MultiAgentV2.
The distinguishing symptom is that the collaboration router cannot resolve the already-started ephemeral root thread, and the failed spawn attempts appear to consume all available capacity.
Activity
RajAccellor commentedon Aug 2, 2026
Reproduced the same signature on a newer build, different model, and non-ultra reasoning effort — adding as a data point since this looked like it might be effort/model-specific.
Version:
codex-cli 0.145.0Subscription: ChatGPT-authenticated CLI (same as OP)
Config:
(main thread on
gpt-5.6-sol,model_reasoning_effort = "medium")Command:
No
--json, no--sandbox workspace-writeoverride — so those flags aren't required to trigger it.Observed:
The ID in the error is the root session ID printed in the CLI banner for that same run, same as OP's finding (root thread not yet resolvable by the collaboration router at spawn time).
Difference from OP's report: in three separate runs here (twice with
default_subagent_reasoning_effort = "max", once with"high", all ongpt-5.6-terra), the very next spawn attempt in the same turn succeeded and the turn completed with a correct result — no cascade intoagent thread limit reached. So the failure mode seems to range from transient/self-healing (small number of spawn calls in a turn, as here) to cascading/terminal (OP's broad planning prompt that triggered several proactive parallel delegations under Ultra). Might point to a race in root-thread registration that a single retry usually wins, but repeated/parallel spawns in the same window increase the odds of hitting it more than once and exhausting slots.Happy to share full stdout/stderr from these runs if useful.
aidawilliam41-ops commentedon Aug 21, 2026
Additional Windows reproduction, with a fail-open acceptance symptom that is not covered by the existing reports.
Environment
--ephemeral, read-only sandbox, default model/reasoning; MCP and browser calls forbiddenReproduction
codex exec --ephemeral --sandbox read-only --skip-git-repo-check -C <project>and require exactly one project-local subagent canary.Full-history forked agents inherit the parent agent type; omit agent_type, or spawn without a full-history fork.PROBE=PASS ... SUBAGENT_REPLY=<expected sentinel>A second strict run required an explicit project-agent type, a bounded fork, a returned agent ID, and a terminal wait result. It failed honestly with
AGENT_ID=NONEandcollab spawn failed: no thread with id: <ephemeral-root>. The runtime log showed the same missing-parent lookup.Impact
Headless acceptance automation can report PASS even though the collaboration operation failed and no subagent existed. Inspecting only the final answer is therefore unsafe.
Expected
Both probes exited cleanly with no residual process or project mutation. No project data or external service was accessed.
codex exec --ephemeralfails to spawn a custom subagent withno thread with id; non-ephemeral succeeds after global agent placement #41474 as a duplicate of this issue