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

What version of the Codex App are you using (From “About Codex” dialog)?

26.814.41957

What subscription do you have?

Pro

What platform is your computer?

Linux 7.0.0-28-generic x86_64 x86_64

What issue are you seeing?

In a long-running Codex task, completed subagent threads stopped being reclaimed correctly after several successful waves of parallel agents.

The Subagents UI showed:

Active: 1
Done: 12

Despite this, every attempt to create another subagent failed with:

collab spawn failed: agent thread limit reached

The failure occurred both when:

1. The root agent called spawn_agent.
2. An active child agent attempted to spawn its own fresh child.

Representative redacted request:

spawn_agent({
  agent_type: "coder",
  fork_turns: "none",
  task_name: "module2_cognitive_obstacle",
  message: "[bounded task packet with repository paths redacted]"
})

Result:

collab spawn failed: agent thread limit reached

No subagent was created, no command was executed, and no files were changed by any rejected spawn.

Some agents that had already returned FINAL_ANSWER later appeared as pending_init:

/root                                  running
/root/bootstrap_guidance_worktrees     pending_init
/root/module2_cognitive_pose           pending_init
/root/module3_gt_firewall              running
...other agents                        completed

Attempting to interrupt these stale entries returned:

{"previous_status":"pending_init"}

but did not close or remove them.

I then sent each stale agent a no-op cleanup follow-up. Both returned:

cleanup complete

Their status changed from pending_init to completed, but new spawn_agent calls still failed with the same thread-limit error.

When the only active child later completed, exactly one new spawn succeeded. An immediate second spawn again failed with:

collab spawn failed: agent thread limit reached

This indicates that the scheduler’s open-thread count did not match the UI Active count.

The official [Subagents documentation](https://learn.chatgpt.com/docs/agent-configuration/subagents) says Codex handles closing agent threads and describes agents.max_concurrent_threads_per_session as a cap on concurrently open spawned-agent threads, excluding the primary thread. The observed behavior appears inconsistent with those semantics.

What steps can reproduce the bug?

1. Enable multi-agent support with a concurrency limit such as:

[agents]
enabled = true
max_concurrent_threads_per_session = 5

2. Start a long-running goal/task.

3. Spawn four independent subagents concurrently.

4. Wait until all four return final results and appear under Done.

5. Spawn additional waves of fresh subagents. In this session, several later waves initially worked correctly.

6. Continue until the UI contains approximately 10–12 Done subagents.

7. Leave one child agent running.

8. Attempt to spawn another fresh agent:

spawn_agent({
  agent_type: "coder",
  fork_turns: "none",
  task_name: "another_independent_task",
  message: "[redacted bounded task]"
})

9. Observe:

collab spawn failed: agent thread limit reached

10. Inspect the agent list. Some agents that already returned final results may appear as pending_init.

11. Attempt to close them using interrupt_agent.

12. If they remain registered, send a no-op follow-up so they return another final result.

13. Retry spawn_agent. In the affected session, the spawn still failed even after the stale agents became completed.

14. Wait for the one active child to finish. One new spawn may then succeed, while an immediate second spawn fails again.

Session/task ID:

01a01a09-e10b-79a3-b71e-15f531937900

Token-limit and context-window usage:

Not captured. No token-limit, context-window, or compaction warning was shown when the scheduling failure occurred.

Additional reproduction detail:

• Earlier waves of four parallel agents and subsequent replacement waves succeeded.
• The failure appeared only after the long-running task accumulated many completed agent threads.
• Raising the persisted concurrency setting from 5 to 10 during the running task did not repair the affected session. This configuration reload behavior may be expected and is not the primary bug.

What is the expected behavior?

When a subagent returns its final result:

1. Its agent thread should transition to a completed and reclaimable/closed state.
2. It should not later reappear as pending_init.
3. Done agents should not consume active concurrency indefinitely.
4. The UI Active count and the scheduler’s open-thread count should agree.
5. A new subagent should be spawnable whenever the number of concurrently open child threads is below agents.max_concurrent_threads_per_session.
6. Asking Codex to close a completed thread should actually release its scheduler capacity.
7. If spawning is rejected, the error should report the relevant counts, for example:

configured_limit
open_spawned_threads
active_threads
completed_but_open_threads
pending_init_threads

Additional information

Environment details:

OS: Ubuntu 24.04 x86_64
ChatGPT/Codex Desktop package: 26.814.41957
Embedded Codex CLI: 0.148.0-alpha.15
Standalone Codex CLI: 0.147.0
Task type: long-running /goal workflow

Observed lifecycle anomaly:

FINAL_ANSWER
    ↓
completed
    ↓
unexpected pending_init

Cleanup attempts:

interrupt_agent(pending_agent)
→ previous_status: pending_init
→ agent remained registered

no-op followup_task(pending_agent)
→ FINAL_ANSWER: cleanup complete
→ state became completed
→ scheduler capacity was still not reclaimed

Impact:

• Parallel execution degraded to effectively one child at a time.
• The UI suggested available capacity that the scheduler would not allocate.
• Workflows requiring fresh agents could no longer follow their configured orchestration rules.
• Restarting or creating a new task was the only reliable way to rebuild the agent registry.
• Rejected spawn attempts caused no repository or filesystem changes.

Possible cause, based only on observed behavior:

• completed agent instances may remain registered as scheduler-open threads;
• FINAL_ANSWER, completed, pending_init, UI Active/Done, and scheduler-open states may not be synchronized;
• reclamation may degrade after repeated waves in a long-running task.

Suggested attachments:

• Screenshot showing 1 Active / 12 Done.
• Redacted list_agents output.
• The exact agent thread limit reached errors.
• Logs showing agents returning FINAL_ANSWER before appearing as pending_init.
• A sanitized config.toml.
• Session/task ID shown above.

Start by reproducing the session with config.toml, max_concurrent_threads_per_session=5, and repeated spawn_agent calls while observing list_agents, interrupt_agent, and follow-up_task states. Trace how FINAL_ANSWER, completed, pending_init, and scheduler-open counts are updated. Done means completed threads are reclaimed, UI and scheduler counts agree, and fresh spawns work below the configured limit.