Repository navigation
[FATAL] Windows Codex APP + Codex CLI subagents freezing when several dozens are running #37748
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.803.41515
What subscription do you have?
GPT PRO
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
I am running a workflow that needs subagent delegation. Gpt 5.6 sol created several subagents and these subagents created several subagents under them. When the total number of subagents is around several dozens, and some agents has finished their jobs (within 10), the whole codex threads will keep running forever but without process for every single subagents in the thread, all of them will stuck at a particular step of their own.
I try to use Codex CLI too, and the same issue happens, and the terminal thread will be freezed/stuck and cannot click at the input field, nothing is moving.
What steps can reproduce the bug?
"Hi, launch a workflow such that one agent per product such that we can populate the images of these product in our db for the 400 products of brand X that we created today"
What is the expected behavior?
The Codex App and Codex CLI will not be usable after some agents are spawned.
Additional information
Fatal, can't use for productive work.
Activity
github-actions commentedon Aug 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
jdcodes1 commentedon Aug 18, 2026
The stall reproduces from the multi-agent capacity design: it fails hard instead of queueing, and nothing retries when capacity frees.
Every turn-triggering inter-agent message first runs a capacity check (https://github.com/openai/codex/blob/1f41cc5d92/codex-rs/core/src/agent/control.rs#L219-L223). At the cap, that returns an
AgentLimitReachederror immediately — there is no wait queue, and releasing a slot wakes nobody (ensure_execution_capacityincore/src/agent/control/execution.rs#L44-L60; the guard'sDropjust decrements an atomic). The only automatic wake,maybe_start_turn_for_pending_work, fires on the same thread's turn end, never on other threads blocked by capacity (core/src/tasks/mod.rs#L449-L492).With nested fan-out, slots fill with leaves; V2 residency then can't reclaim anything because
is_unloadablerequires Completed/Errored + empty mailbox, which no mid-tree agent satisfies (core/src/agent/control/residency.rs#L87-L151). So children's completion reports and parents' follow-ups all bounce withAgentLimitReached, models retry the tool call, and the whole tree livelocks — running forever, zero progress, exactly what you're seeing on both app and CLI.Fix shape: (1) queue capacity waiters and wake them from
AgentExecutionGuard::Drop/residency release; (2) always admit completion-report messages to parents (they unblock capacity); (3) count depth-aware reservations so a parent's pending children can't starve its own wake.