[BUG] Background agent transcripts become unresumable (No transcript found), forcing full-context respawns

Feedback ticket — Background agent transcripts become unresumable, forcing full-context respawns (token burn)

Date filed: 2026-07-15
Reporter: Shawna Cason (Claude Max subscriber)
Product: Claude Code CLI v2.1.209 · model Fable 5 (claude-fable-5) main loop, kaleido custom subagents · macOS (Darwin 25.5.0)
Severity: Medium — repeated forced re-initialization of background agents multiplies token cost of iterative workflows

---

Summary

During a long iterative design session (a custom kaleido agent running successive design rounds against local HTML/SVG files), background agents that had just completed successfully could not be resumed via SendMessage minutes later:

Agent "<id>" could not be resumed: No transcript found for agent ID: <id>

This happened at least five times in one session (~2026-07-14, session 7f97147b-bc98-4424-a1af-fa3f8a54b415, project dir ~/.claude/projects/-Users-shawnacason/). Each failure forced spawning a fresh agent that had to re-read all project state (design-direction logs, session-state handoffs, 15+ reference images, prior render proofs) before doing any new work — an estimated 30–60k tokens of pure re-initialization per respawn, five-plus times over.

A related delivery bug compounded it: a SendMessage to a running agent returned "Message queued for delivery … at its next tool round", but the agent completed without ever receiving the message; the instruction had to be re-sent to a fresh agent (and in one case the un-received instruction concerned user rulings — three kill decisions — which the completed round then visibly violated, requiring an additional correction round).

Observed sequence (representative)

1. Agent a3b6355817ef178bb runs ~14 rounds successfully across several hours (resumed repeatedly via SendMessage — resume works).
2. A completion notification arrives; subagent token counter visible in usage (~450k+ across its lifetime).
3. Next SendMessage minutes later → No transcript found for agent ID.
4. New agent spawned; must re-read SESSION_STATE.md, DESIGN_DIRECTION.md, all reference images, prior proofs (the workflow's own handoff discipline makes this survivable, but expensive).
5. Pattern repeats with the successor agents (ad4fd742…, a0e36471…, a13c6624…, a94043419… — each lost after 1–2 rounds).

Impact

1. Multiplied token burn: an iterative crit loop that should cost one warm-context increment per round instead pays a full cold-start (state files + image re-reads) on every round where the transcript vanished. Rounds were observed at 130k–450k subagent tokens; a large share of the later rounds' cost is re-initialization, not new work.
2. Lost instructions: the "queued for delivery" message that never arrived contained user design rulings; the shipped round contradicted them and had to be redone.
3. Perceived model regression: from the user's seat, this reads as "Claude suddenly burns tokens much faster than a few days ago," even though the proximate cause is harness-side transcript/session lifecycle behavior.

Expected behavior

• A completed background agent should remain resumable (as documented: "a send resumes it from its transcript") for a reasonable window; silent transcript loss should not occur minutes after completion.
• If a transcript is evicted/compacted, SendMessage should say so explicitly (and ideally offer the last-known output), rather than a generic not-found.
• "Message queued for delivery" should be a guarantee or an error — if the agent completes before delivery, the sender should be notified that the message was NOT delivered so instructions aren't silently dropped.

Reproduction shape

1. Spawn a background custom agent that does heavy tool use (many screenshots/file reads → 150k+ tokens per run).
2. Let it complete; receive the task notification.
3. SendMessage to the same agent ID within minutes → observe No transcript found.
4. Separately: SendMessage while the agent is mid-run and about to finish → observe "queued for delivery" followed by completion without the message ever being processed.

Evidence locations (local)

• Session ~/.claude/projects/-Users-shawnacason/7f97147b-bc98-4424-a1af-fa3f8a54b415.jsonl (2026-07-14 → 07-15): contains the SendMessage failures verbatim and the respawn chain.
• Agent output files under /private/tmp/claude-501/-Users-shawnacason/7f97147b-…/tasks/ (per-agent outputs referenced in the session).

Ask

1. Investigate transcript retention/eviction for completed background agents (correlation with very large subagent transcripts, 150k+ tokens, suspected).
2. Make SendMessage delivery outcomes truthful: delivered / not-delivered, never silently dropped.
3. Consider surfacing "this agent's transcript was evicted" in the completion notification so orchestrators can hand off proactively instead of discovering it on the next send.