[FATAL] Windows Codex APP + Codex CLI subagents freezing when several dozens are running

Open 💬 2 comments Opened Aug 10, 2026 by henry9207

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 18 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#37018

Powered by Codex Action

jdcodes1 · 9 days ago

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 AgentLimitReached error immediately — there is no wait queue, and releasing a slot wakes nobody (ensure_execution_capacity in core/src/agent/control/execution.rs#L44-L60; the guard's Drop just 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_unloadable requires 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 with AgentLimitReached, 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.