MultiAgentV2: Ultra `codex exec --ephemeral` cannot find root thread, then exhausts agent slots

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.md

The 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:

1. Root thread.started with ID A.
2. Root turn.started.
3. Normal root agent message/todo and shell activity.
4. Spawn failure: no thread with id: A.
5. Two later spawn failures: agent thread limit reached.
6. No successful child IDs in the event stream; later waits targeted no agents.
7. 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:

• #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.
• #25426 and #22779 — stuck/completed agents retain spawn slots.
• #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.