[BUG] Subagent rate-limit failures are surfaced as a user prompt after the limit has already reset

Summary

When subagents die because the account is over its usage limit, and the limit window then resets, the parent session surfaces the old subagent failure as a decision prompt asking the user how to proceed. That prompt is unnecessary. The parent could only have generated that turn because the limit had already cleared, so the failure it is asking about is provably stale. The correct behavior is to re-dispatch the failed subagents and say so, not to ask.

Reproduction

1. Start a session and dispatch two or more subagents through the Agent tool on a task that runs for a while.
2. Exhaust the rolling usage limit while those subagents are still running. They terminate with a limit error.
3. Wait for the limit window to reset, or add usage so the account is under its limit again.
4. Send any message to the parent session.

Expected: the parent notices that its own request just succeeded, concludes that the limit which killed the subagents is no longer in force, and re-dispatches them (or resumes them), reporting what it did.

Actual: the parent reports that the subagents hit a subscription limit and presents a multiple choice list of options, making the user arbitrate a condition that has already cleared.

Why this is a correctness bug, not a preference

A parent turn cannot be produced while the account is over its limit. So the instant the parent emits text describing a subagent limit error, that error is known to be out of date. Every option in the multiple choice prompt is being offered on the basis of state that the act of offering it disproves. The user is being asked a question the system already holds the answer to.

Observable root cause

From outside the binary, three things appear to be missing:

1. The subagent termination is passed up as an opaque error string. There is no structured reason code distinguishing a limit kill from a tool error or a normal completion.
2. Nothing compares the subagent failure time against the timestamp of the parent's most recent successful request, which is the exact comparison that decides whether the error is live or stale.
3. There is no retry or resume path for a limit killed subagent, so the model has nothing to do except ask.

Proposed fix

1. Tag every subagent termination with a structured reason and a timestamp, for example terminated_by: "rate_limit" | "tool_error" | "completed" and terminated_at.
2. On the parent's next successful request, treat any pending rate_limit termination whose terminated_at precedes that request as cleared.
3. Automatically re-dispatch the cleared subagents, or expose resume so the original subagent session continues instead of restarting from zero, and report the action rather than requesting permission for it.
4. Prompt the user only when the limit is still active, or when a re-dispatch fails a second time.

Step 1 alone would be a real improvement even without the rest, since it lets a parent agent branch correctly instead of pattern matching on error text.

Related issues

• #52864 (closed, not planned) requested resume: session_id on the Agent tool, and as a secondary ask, an explicit rate limit termination signal. That secondary ask is a prerequisite for the fix proposed here.
• #13354 requests wait and resume at the session level.
• #56978 requests graceful handling when a limit is hit mid session.

None of those cover this case, where the limit is already gone and the tool still stops to ask about it.

Environment

• Claude Code CLI 2.1.233, macOS.
• Subscription plan with a rolling usage window, not API billing.
• Seen with parallel general purpose subagents dispatched from one parent session.