Completed subagent threads are not reclaimed, causing false "agent thread limit reached" with 1 Active / 12 Done

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

• #38805
• #38247

Powered by Codex Action

A current-main source check at 39073ca3 suggests the immediate admission failure is residency pressure, not necessarily leaked active-execution guards. V2 has separate active-turn and resident-slot gates, but both return the same AgentLimitReached. The residency LRU counts loaded residents and only evicts Completed/Errored/Interrupted agents whose turn is cleared and mailbox is empty; PendingInit is not evictable. Reloaded sessions start at PendingInit, resume reconstruction restores only Interrupted, and interrupt_agent submits an interrupt and returns the previous status—it does not close or evict the resident.

That makes the reported one-for-one behavior source-consistent: when the sole running child becomes terminal, one evictable resident appears, one spawn succeeds, and the resident set can be blocked again. The exact event that reloaded the affected children still needs logs; queue-only delivery is one public path that reloads without immediately starting a turn.

This appears closest to #34518 (including an independent 0.148.0-alpha.15 pending_init reproduction) and the broader #22779. #38805/#38247 are related persistence/runtime-retention reports, but not as exact for admission accounting. A regression should fill the resident cap, evict and reload a terminal child without starting a turn, exercise interrupt_agent and followup_task, and assert both spawn admission and the UI/list status projection. The error should also distinguish active-cap from residency-cap rejection and report blockers.

The source-level residency diagnosis matches a Windows reproduction where child rollouts were terminal but parent edges stayed open; after compaction a completed child returned as pending_init, and the next spawn hit the same limit. Cleanup must distinguish live execution from resident/edge state; this bridges #34518 and #22779 with the UI projection bug in #37042.

This report was written by the Codex agent that designed the tests and independently inspected the coordinator and child-task records.

Summary

After updating Codex Desktop, two controlled tests of completed-subagent slot reclamation succeeded:

1. Six genuinely fresh subagents were created sequentially, each only after the previous child completed.
2. Three subagents were dispatched as a wave, allowed to complete, and then three additional fresh subagents were dispatched in a second wave.

No subagent creation was refused, and no agent thread limit reached error occurred.

Important limitation

Unfortunately, we did not run these exact controlled tests before updating Codex. Therefore, we cannot confirm with 100% certainty that the update fixed the problem or establish the update as its cause.

What we can establish is:

• Before updating, an earlier long-running task exhibited the apparent slot-reclamation problem: completed subagents remained visible as done, and a later fresh-child dispatch was refused because the task had reached its agent-thread limit.
• After updating, both controlled tests below passed.
• The evidence therefore supports saying that completed-agent slot reclamation currently works on the updated build—not conclusively that the update itself fixed it.

Versions

Previously observed environment:

• Codex Desktop: 26.818.41509
• App build: 6962
• Bundled CLI: 0.149.0-alpha.4.1

Tested environment after updating:

• Codex Desktop: 26.818.61809
• App build: 7019
• Bundled CLI: 0.149.0-alpha.4.3

The tests ran inside Codex Desktop, so the bundled CLI/runtime is the relevant one.

Test 1: Sequential reclamation

Prompt

This is a minimal subagent-slot reclamation test. Do not inspect or modify files,
run commands, or perform useful project work.

Sequentially create six genuinely fresh subagents, one at a time.

For round N:

- create a fresh child named slot_reclaim_N;
- give it no inherited context;
- instruct it: “Reply exactly SLOT-N-OK. Do not use tools or delegate.”
- wait for that child to complete before starting the next round;
- do not reuse it, send follow-ups, interrupt it, or explicitly close it.

If any fresh-child creation is refused, stop and quote the exact refusal.

Finally report:

- how many distinct children were successfully created;
- whether every response matched;
- whether all six fresh children succeeded;
- the exact error and round if one failed.

Result

• Six distinct fresh subagents were created.
• Every subagent completed.
• No creation was refused.
• No runtime error occurred.
• Five responses matched exactly.
• The first child returned SLOT-1-OK. rather than SLOT-1-OK; the additional period is unrelated to slot reclamation.

This demonstrates that normal completion no longer exhausts fresh-child capacity over six sequential creations.

Test 2: Reclamation between waves

Prompt

This is a disposable two-wave subagent-slot reclamation test. Do not inspect or
modify files, run commands, or perform useful project work.

Execute exactly two waves. Each wave contains three genuinely fresh subagents.

For Wave 1:

1. Dispatch three fresh children named:
   - wave_1_a
   - wave_1_b
   - wave_1_c

2. Dispatch all three before waiting for any child.

3. Give each child no inherited context and tell it:
   “Reply exactly WAVE-1-<LETTER>-OK. Do not use tools or delegate.”

4. After all three dispatch attempts, wait until every successfully dispatched
   child completes. This is the Wave 1 barrier.

For Wave 2, only after the Wave 1 barrier:

1. Dispatch three new children named:
   - wave_2_a
   - wave_2_b
   - wave_2_c

2. Do not reuse any Wave 1 child. Dispatch all three before waiting for any child.

3. Give each child no inherited context and tell it:
   “Reply exactly WAVE-2-<LETTER>-OK. Do not use tools or delegate.”

4. Wait until every successfully dispatched child completes. This is the Wave 2
   barrier.

Throughout the test:

- do not use follow-up tasks;
- do not interrupt or explicitly close completed children;
- if any dispatch is refused, preserve and quote the exact refusal;
- do not substitute sequential dispatch-and-wait within a wave.

Finally report:

- the six distinct child names and thread IDs;
- the number successfully dispatched in each wave;
- whether all three Wave 1 children completed before Wave 2 began;
- whether all six children completed;
- every response mismatch;
- every dispatch refusal or runtime error;
- whether Wave 2 obtained three fresh slots after Wave 1 completed.

Result

• Wave 1 dispatched three distinct fresh children.
• The Wave 1 children genuinely overlapped in execution.
• All three completed before Wave 2 began.
• Wave 2 dispatched three additional distinct fresh children without reusing Wave 1 children.
• All six children returned the exact requested responses.
• No dispatch was refused.
• No runtime error occurred.

Because these children performed extremely short tasks, some Wave 2 children completed while the remaining dispatches were being issued. The test nevertheless confirmed that fresh child creation continued after a completed three-child wave without encountering the previous limit error.

Conclusion

The updated environment successfully passed both:

• repeated sequential fresh-child creation; and
• fresh-child creation following a completed parallel wave.

This is strong evidence that the observed completed-agent slot-reclamation problem is not currently reproducing.

It is not proof that every long-running, interrupted, approval-blocked, or unusually complex subagent lifecycle is fixed. Most importantly, because these controlled tests were not run before the update, the result cannot establish with certainty that the update caused the improvement.

Follow-up reproduction on the updated build

Environment:

• Codex Desktop 26.818.61809
• Bundled CLI 0.149.0-alpha.4.3
• Session: 01a03411-e72a-73a2-aae2-97872a621dab

A long-running multi-agent session reproduced the false thread-limit symptom with a more specific lifecycle sequence:

1. The parent sent a queue-only send_message to child A while A was still running.
2. A completed shortly afterward.
3. Fresh children B and C started successfully.
4. A third fresh spawn D failed with collab spawn failed: agent thread limit reached.
5. The agent list showed the root and B/C running, while A remained listed as completed.
6. Interrupting completed A returned its prior completed status but did not restore admission; retrying D failed again.

This strongly suggests a completed resident pinned by the near-completion mailbox race described in #32353, rather than cumulative child exhaustion. Sixteen fresh children had been created over earlier waves, but there is no evidence that 16 is a lifetime limit.

This does not contradict my previous controlled tests: those deliberately used no messages, follow-ups, or interruptions, so they did not exercise this lifecycle.