[FEATURE] Mark a subagent killed by a usage limit as resumable, and keep it listed after a session restart

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When a usage limit kills a background subagent, the work looks lost. It isn't: SendMessage to the dead agent's id resumes it from its transcript, with its original instructions. But nothing tells the user or the orchestrating model that, so the natural move is to spawn a fresh agent and redo the work.

A session restart makes it worse. After /login (or anything else that starts a new session id), ListAgents no longer lists the old agents and their tasks/<id>.output files are gone. The only way back is to have written the id down, or to dig it out of ~/.claude/projects/<project>/<old session>/subagents/agent-<id>.jsonl. With that id, SendMessage still resumes the agent across sessions.

What we observed (v2.1.270, 2026-09-14): a code-review orchestrator and its 6 finder subagents all died on a usage limit. The orchestrating model spawned a fresh review instead of resuming. Later, from a new session id, we sent SendMessage to the old orchestrator's id. It replied "Resuming agent", then resumed its own 6 finders by id: all 6 came back with their original instructions, none was re-spawned, and the 2 that had finished before the limit kept their results. In our one comparison, the fresh re-run reported 4 findings for ~205k tokens, and the resumed run reported 10 confirmed findings for ~166k.

Proposed Solution

1. When a subagent dies on a usage limit, the task notification says so, and says the agent can be resumed with SendMessage to its id once the limit resets.
2. ListAgents and /tasks keep listing agents that a limit killed in a recent earlier session of the same project, marked e.g. "stopped (usage limit) — resumable", so a restart doesn't hide them.
3. Optional: when auto-continue fires at reset (#89263), resume the limit-killed subagents as well. Resuming the parent is enough if it is told to resume its children.

Alternative Solutions

Our workaround today: record every dispatched agent id in a ledger file. After a limit, SendMessage the parent and tell it to resume its children by id. It works, but only for users who already know resuming is possible.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

An orchestrator dispatches implementer, reviewer and finder subagents in the background for a multi-hour plan. A usage limit kills several of them mid-task. After the reset, the notification or ListAgents shows them as resumable, and the orchestrator sends each one a SendMessage to continue. Today it spawns replacements and redoes their work instead.

Additional Context

Related, but not the same request:

• #89263: auto-continue never arms when a limit kills only background subagents.
• #90520: resuming a completed subagent later fails with "No transcript found".
• #76602: the panel for a resumed subagent renders its transcript garbled.