codex - 💡(How to fix) Fix Main agent needs subagent capacity/status preflight before spawn_agent attempts [2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#23479Fetched 2026-05-20 03:49:13
View on GitHub
Comments
2
Participants
3
Timeline
5
Reactions
0
Timeline (top)
commented ×2labeled ×2cross-referenced ×1

The main agent needs a reliable subagent capacity/status preflight before deciding to call spawn_agent.

Today, the agent can decide that delegation would be useful, attempt to spawn a subagent, hit a thread limit or stale subagent state, and then degrade into not using subagents at all. The failure mode is especially painful in long engineering sessions where subagents are needed for read-only exploration and parallel investigation.

Root Cause

For large codebases, subagents are not just a convenience. They are how the parent keeps context clean while parallel read-only investigation happens in bounded lanes.

When a long-running session reaches subagent capacity, the current experience can turn into:

need research -> try spawn -> spawn failed -> stop using subagents -> parent context bloats

A preflight/status surface would let the parent agent recover intentionally:

need research -> inspect capacity -> close completed / wait / retry / explain -> continue delegation

Code Example

subagent capacity: 0/6 slots available
active: 2 running, 0 waiting
retained completed: 4
recent spawn failure: thread limit reached
recommended recovery: close completed agents, then retry

---

need research -> try spawn -> spawn failed -> stop using subagents -> parent context bloats

---

need research -> inspect capacity -> close completed / wait / retry / explain -> continue delegation
RAW_BUFFERClick to expand / collapse

Summary

The main agent needs a reliable subagent capacity/status preflight before deciding to call spawn_agent.

Today, the agent can decide that delegation would be useful, attempt to spawn a subagent, hit a thread limit or stale subagent state, and then degrade into not using subagents at all. The failure mode is especially painful in long engineering sessions where subagents are needed for read-only exploration and parallel investigation.

Current behavior

From the user's perspective, the parent agent may not have a clear way to know:

  • how many subagent slots are currently available
  • whether completed subagents are still retained and counting against a limit
  • whether any subagents are running, waiting, completed, or failed
  • whether the last spawn failed because of thread limit, quota, provider failure, MCP startup, or another cause
  • whether closing completed agents would free capacity
  • whether retrying, waiting, reusing, or not delegating is the right next action

When spawn_agent fails, the parent agent may treat the failure as a generic inability to delegate and continue locally, instead of recovering or explaining the precise cause.

Expected behavior

Before or as part of spawn_agent, Codex should expose a compact capacity/status preflight to the main agent.

The exact API shape is flexible, but the agent needs information like:

subagent capacity: 0/6 slots available
active: 2 running, 0 waiting
retained completed: 4
recent spawn failure: thread limit reached
recommended recovery: close completed agents, then retry

The important behavior is:

  1. The parent agent can see whether spawning is likely to succeed.
  2. If spawning cannot succeed, the agent gets an explicit reason.
  3. If there is a safe recovery path, the agent can take it or ask the user.
  4. The agent should not silently abandon delegation just because one blind spawn attempt failed.

Why this matters

For large codebases, subagents are not just a convenience. They are how the parent keeps context clean while parallel read-only investigation happens in bounded lanes.

When a long-running session reaches subagent capacity, the current experience can turn into:

need research -> try spawn -> spawn failed -> stop using subagents -> parent context bloats

A preflight/status surface would let the parent agent recover intentionally:

need research -> inspect capacity -> close completed / wait / retry / explain -> continue delegation

Related issues

This overlaps with several existing subagent lifecycle issues, but the focus here is narrower: parent-agent preflight before delegation.

Related:

  • #22779: completed subagents continue to count against thread limit
  • #16891: subagent quota exhaustion is surfaced as generic no response
  • #16328: after compaction, Codex may keep saying Agent spawn failed
  • #16900: ability to check agent status and parent-child wait mechanism
  • #22321: Agent View for managing multiple Codex agents from the TUI

Those issues cover specific lifecycle or UI failures. This issue asks for a model-visible/runtime-visible preflight so the parent agent can make a good delegation decision before attempting spawn_agent.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Before or as part of spawn_agent, Codex should expose a compact capacity/status preflight to the main agent.

The exact API shape is flexible, but the agent needs information like:

subagent capacity: 0/6 slots available
active: 2 running, 0 waiting
retained completed: 4
recent spawn failure: thread limit reached
recommended recovery: close completed agents, then retry

The important behavior is:

  1. The parent agent can see whether spawning is likely to succeed.
  2. If spawning cannot succeed, the agent gets an explicit reason.
  3. If there is a safe recovery path, the agent can take it or ask the user.
  4. The agent should not silently abandon delegation just because one blind spawn attempt failed.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Main agent needs subagent capacity/status preflight before spawn_agent attempts [2 comments, 3 participants]