SendMessage cannot resume an orphaned background subagent whose transcript exceeds ~5 MiB: "No transcript found for agent ID"

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 1 comment · opened Aug 2, 2026

Summary

Resuming an orphaned background subagent via SendMessage after a Claude Code restart fails with

Agent "aXXXXXXXXXXXXXXXX" could not be resumed: No transcript found for agent ID: aXXXXXXXXXXXXXXXX

even though the transcript file exists and is intact. It reproduces reliably once the agent's transcript
~/.claude/projects/<project>/<session>/subagents/agent-<id>.jsonl grows past roughly 5 MiB; below that
size the identical flow resumes fine.

The restart notification that instructs you to do this appears to check only that the transcript file exists
and is non-empty, so the harness advertises a recovery path that cannot actually be honored for any
long-running agent — and the longer (i.e. more valuable) the orphaned agent's context, the more certain the
advertised recovery is to fail.

Environment

  • Claude Code 2.1.220 (also reproduces on 2.1.218), native installer, Linux x64.

Repro sketch

  1. Launch a background subagent (Agent tool) and let it run long enough that

subagents/agent-<id>.jsonl exceeds ~5 MiB (a few hours of tool-heavy work; mine was 663 lines / 14.1 MiB).

  1. Kill or exit the Claude Code process while the agent is still running.
  2. Restart. The orphan notification says:

> No completion record was found for background agent "…" from the previous session. It may have been
> stopped, or it may have been running when the previous Claude Code process exited — either way its
> transcript is saved on disk, so its progress is not lost. Resume it by sending it a message with
> SendMessage
, or check its worktree/output for partial work before assuming the task landed.

  1. SendMessage(to: "<agentId>", …)could not be resumed: No transcript found for agent ID: <agentId>.

Control: the same flow with a transcript under ~5 MiB resumes normally
(Agent X had no active task; resumed from transcript in the background with your message.).

Evidence for the size threshold

In one workstream, four background agents were orphaned by the same process exit and I attempted to resume
them the same way. Sizes below are the transcript sizes at the moment of the resume attempt, reconstructed
from the per-line timestamps in each .jsonl:

| transcript size at resume | result |
|---|---|
| 0.93 MiB | resumed ✅ |
| 0.97 MiB | resumed ✅ |
| 3.1 MiB | resumed ✅ |
| 14.1 MiB | failed ❌ "No transcript found for agent ID" |

Nothing else distinguished them: same project, same session directory, same agentType, all had their
.meta.json present, all had live worktrees, all were spawned by the Agent tool. Only size correlates.

Nothing appears to be wrong with the failing file itself — it is well-formed JSONL and parses cleanly.

Impact

  • The advertised SendMessage recovery is a dead end exactly for the agents whose lost context matters most.
  • The automatic orphan re-dispatch on startup appears to go through the same resume path, so it silently

fails for these agents too.

  • There is no in-product way to recover the context: the transcript lookup is keyed by agent id and session

directory, so the file cannot be relocated or re-registered.

Workaround

Starting Claude Code with CLAUDE_CODE_DISABLE_PRECOMPACT_SKIP=1 makes the resume succeed for these
large transcripts. That suggests the large-transcript loading fast path is what discards the agent's
messages — a subagent transcript consists entirely of sidechain messages, which may be a case that path
does not expect. (The tradeoff is losing the large-transcript loading optimization process-wide.)

Failing that, the only recovery is to read subagents/agent-<id>.jsonl manually and hand the relevant
content to a fresh agent.

Suggested fix

  1. Make the large-transcript loading path handle an all-sidechain transcript (or skip that optimization

entirely for subagents/agent-*.jsonl, which is all-sidechain by construction).

  1. Have the orphan notification validate resumability with the same loader the resume path uses, so it stops

promising SendMessage in cases where the loader will return nothing.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗