Auto-continue at usage limit never arms when the limit kills only background subagents

What happened

Two background agents died with Agent terminated early due to an API error: You've hit your session limit · resets 12am. The main thread was idle ("Waiting for 1 background agent to finish") and had no in-flight request. At the reset, nothing resumed — no auto-continue, no "press enter to continue" notice.

Expected

Since 2.1.234, auto-continue at usage limit is on by default. I expected the session to pick up after the reset. Instead the work was simply lost until I noticed hours later.

Why (from the 2.1.241 bundle)

Arming has exactly one entry point: the main REPL stream handler, on an assistant message with isApiErrorMessage && error === "rate_limit" && quotaLimits. The quota-rejected subscriber that handles re-arms also requires an active turn claim and returns early unless the rejection origin is main_thread. So a quota rejection that only lands on subagents can never arm — and if the main thread happens to be idle at that moment, the whole episode is silently dropped.

Why it matters

For delegation-heavy workflows most tokens are spent in subagents, which is exactly the case the feature doesn't cover. The workaround is to keep a prompt queued so the main thread also takes a rejection, which isn't discoverable.

Suggestion

Treat a subagent quota rejection as an arming trigger when the main thread is idle. At minimum, arm the "press enter to continue" (stale) path so the session isn't silently abandoned. Ideally the continuation prompt should also name the agents that were killed mid-work, so the main loop relaunches them rather than guessing at "continue".

Version: 2.1.241 · Linux