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

Confirming this on 2.1.223, and I think I can supply the exact mechanism — including why your CLAUDE_CODE_DISABLE_PRECOMPACT_SKIP=1 finding works and why your sidechain hunch is right. I traced it through the shipped bundle. Symbol names below are the minified ones from the 2.1.223 artifact.

The threshold is exactly 5 MiB, and it's a hard file-size gate

_Be = 5242880

In the transcript loader (RMe):

if(!tr(process.env.CLAUDE_CODE_DISABLE_PRECOMPACT_SKIP)){
  let{size:Z}=await uu.stat(e);
  if(Z>_Be){ let oe=pDb(e,Z,q,...); ... return ee(cXo(r)); }
}
let B=await uu.readFile(e);   // ← normal full-read path, skipped when over threshold

This is a pure function of file size, which is why it's perfectly deterministic and survives restarts. My failing transcript was 5,251,451 bytes — 8,571 bytes over the line. A control agent in the same session directory, same agentType, same spawn mechanism, at 2,711,993 bytes resumed fine. That 8.5 KB was the only difference.

Why the fast path returns nothing for a subagent

pDb is the >5 MiB scanner. It picks its walk root like this:

let oe=-1;
for(let ne=C.length-1;ne>=0;ne--) if(!R[ne]){oe=ne;break}   // last line WITHOUT isSidechain
...
ae(oe>=0?oe:void 0);          // walk the parentUuid chain up from there
let B=W??new Set(C);          // B = set of line offsets to actually parse

R[n] is true when line n contains "isSidechain":true. So it scans backwards for the last non-sidechain line to use as the root of the chain walk. Exactly as you suspected: every line of a subagent transcript is isSidechain:true, so that scan never matches. In my file, 1508 of 1508 lines carry the marker.

oe therefore stays -1, ae(undefined) walks nothing, and W ends up an empty but non-null Set. That last part is the actual defect — because W is non-null, B = W ?? new Set(C) does not fall back, and pass 2 parses zero lines.

I reimplemented the selection logic and ran it against the real file:

indexed lines C: 1508   unparsed L: 0
lines with isSidechain flag true: 1508   false: 0
last NON-sidechain slot oe = -1
selected line set size B = 0

The two escape hatches that normally save this are both absent from a subagent transcript by construction: 0 last-prompt entries (which would be force-added via for(let oe of L)B.add(oe)) and 0 compact_boundary entries (which would set M=true and bypass pruning entirely).

Empty map → Dvt returns null at its if(i.length===0)return null guard → the resume path throws No transcript found for agent ID. The message is literally true about what the loader returned, which is what makes it so misleading: the file is intact, it just never got parsed.

Why it's invisible in telemetry

Worth flagging separately, because it's why this is hard to catch: the loader returns empty rather than throwing. RMe has real error handling for unreadable/permission cases, but "selected zero lines" isn't an error condition — it's a successful load of nothing. On my side the SendMessage tool call was even recorded as "success":"true" with a 33 ms duration; the failure surfaces only as tool content. I checked my local OTEL log and found zero occurrences of the subagent_resume_transcript_missing telemetry code that the throw site emits.

The one-line fix — and there's already a precedent for it in the same file

pDb should fall back to loading everything when the walk root is never found:

if(oe<0){ W=null }   // no non-sidechain root exists (all-sidechain transcript) → load all lines

W=null makes B=W??new Set(C) select every line, which is the correct conservative behavior. pDb already does exactly this one branch over, for the phantom-parent case:

if(se)$("tengu_transcript_phantom_parent",{...}),W=null;

So the fix is the existing bail-out extended to one more unsatisfiable-root condition.

Independently, the sibling in-memory truncator O2p — same job, buffer instead of file — already guards this exact case:

let _=-1;
for(let R=p.length-3;R>=0;R-=3){ ... if(k===-1||k>=p[R+1]){_=R;break} }
if(_<0)return e;      // ← no root found: return the WHOLE buffer untouched

O2p returns the entire input when it can't find a root. pDb returns nothing. Same intent, and only one of the two is safe — which suggests pDb just missed the guard rather than there being a design reason for the difference. O2p also has a second sanity check pDb lacks (if(g-S<g>>1)return e — bail out if pruning wouldn't drop at least half the file).

Scope

This isn't an edge case that needs an unusual transcript — it's every subagent over the threshold, since all-sidechain is structural for subagents/agent-*.jsonl. In one session of mine, 25 of 550 subagent transcripts were over 5 MiB; every one I sampled showed the identical fingerprint (all lines sidechain, no last-prompt, no compact_boundary). They're all unresumable once the in-memory mirror is gone.

That in-memory mirror is worth noting as the reason this only bites after a restart. Immediately above the throw there's a fallback:

if(!q){ let Ke=g.getTranscript(e)?.messages;
  if(Ke&&Ke.length>0)T(`[resumeAgentBackground ${e}] disk transcript missing; using ${Ke.length} in-memory messages mirrored during the run`) ... }

Within a single process that rescues the resume and the disk bug stays hidden. Restart and the mirror is gone, so the broken disk path is all that's left.

I can confirm the workaround recovers real data, not just a clean error: with the full-read path forced, my file parses to 1508 entries, and the chain walk from the selected leaf reaches 1498 messages. So the content was fully recoverable the whole time.

Two smaller notes in the same area:

• The _Be constant is shared with the session-loader path in #55700 (closed), which reports a different failure mode — pre-boundary scrollback loss — from the same threshold. Different code path and different symptom, but a fix that only touches the session loader wouldn't address this one.
• Agreed on your point 2. Worth adding that the orphan notification's promise is correct about the data being recoverable — it's the loader that can't deliver it. Fixing pDb makes the existing notification honest, so validating with the real loader is a good belt-and-braces measure rather than the primary fix.

Independent confirmation on macOS with native runtime 2.1.237, with additional evidence for the mechanism described above. I also inspected the installed official 2.1.247 runtime and found the same selection logic; I have not end-to-end retested that version.

Three useful additions:

1. A restart is not required. This also affected completed general-purpose agents in the same continuing session. Their exact returned IDs, transcript metadata, and existing valid JSONL agreed. Completed-task eviction can remove the in-memory transcript mirror without deleting the disk transcript, exposing the faulty disk reader during a later SendMessage.
2. Preserved compaction explains successful oversized controls. Subagent transcripts can contain compaction boundaries. A boundary with preserved-message/segment metadata bypasses this pruning, so an oversized subagent can still resume successfully. Standard compaction without preserved metadata does not provide that protection. This is not a blanket transcript-size limit.
3. The missing-leaf guard works in isolated parser-level validation. I extracted the installed runtime's streaming selector and executed its unmodified selection logic with read-only/memory-backed I/O and diagnostic stubs. A candidate that preserves the indexed records when no non-sidechain leaf exists was tested only in memory; no installed binary or transcript was patched.

A minimal synthetic text-only fixture establishes the exact boundary:

| Fixture | Bytes | Original records selected | Candidate records selected |
| --- | ---: | ---: | ---: |
| Two-record, all-sidechain transcript | 5,242,880 | 2 | 2 |
| Same shape, one byte larger | 5,242,881 | 0 | 2 |
| Above-threshold main-conversation transcript | 5,242,881 | 2 | 2 |
| Above-threshold sidechain transcript with preserved compaction | 5,242,881 | 3 | 3 |

The fixture consists of a root user record and its child assistant record, with ordinary UUID/timestamp/parent linkage; the user text is padded to the specified serialized JSONL byte length. It contains no images. The preserved-compaction case adds a boundary record. This isolates serialized size and leaf selection from image handling, provider behavior, or permissions.

Nine synthetic cases passed after the in-memory correction: exactly at/above the threshold, explicit keep-all mode, normal main chains, rewind pruning, trailing sidechains, both compaction forms, and last-prompt metadata. Existing main-chain pruning behavior remained unchanged in those cases. This is parser-level proof, not a patched live-app or full cold-resume test.

The owner-level fix should make the streaming selector preserve records when it has no eligible main-conversation leaf, matching the buffered selector's existing behavior. It should not require truncating user history, changing permissions, or disabling the optimization process-wide. Please include native cold-resume coverage after completed-task eviction as well as restart coverage.

No original session/agent IDs, transcript contents, local paths, or configuration are included here.

Corroborating data for the ~5 MiB threshold, from one project over 2026-08-29 → 2026-09-01.

Seven background subagents were each sent a follow-up via SendMessage after they had finished and reported. Resume outcome vs. the size of the agent's own subagents/agent-<id>.jsonl at the time:

| Transcript size | Image-heavy? (many Read calls on PNG/JPG) | SendMessage resume |
|---|---|---|
| 0.46 MB | no | resumed |
| 1.37 MB | no | resumed |
| 4.49 MB | no | resumed |
| 6.31 MB | yes | No transcript found for agent ID |
| 8.21 MB | yes | No transcript found for agent ID |
| 10.13 MB | yes | No transcript found for agent ID |
| 17.27 MB | yes | (not attempted — pattern already clear; committed the agent's worktree directly) |

Every transcript under 5,242,880 bytes resumed; every one over it failed with the "no transcript" message, though each file was present and intact on disk. Size was the only predictor we found — the failing agents were not orphaned by a restart; they had simply finished, in the same session, minutes earlier. All three large ones got there by reading images (rendered map crops during a georeferencing task), so their token usage was ordinary; the file size was not.

Two things that would have saved us time:

1. An error that says "transcript is N MB, above the load threshold" rather than "no transcript found" — the current message reads as a wrong or expired ID.
2. Some way to resume past the threshold (or at least to read the transcript's final report), since the agents most likely to cross it are the long, valuable ones.

Environment: Linux, native install; the observations above were on the release current as of 2026-09-01 (we have since updated to 2.1.258 and have not yet re-tested on it).