Completed background subagents unresumable after background-session fork: "No transcript found for agent ID" (transcript exists in pre-fork session dir)
Environment
- Claude Code v2.1.216, macOS (darwin 25.5.0)
- Background session (job) started via
claudeas a background job, with subagents dispatched in background
Summary
After a background session forks (SessionStart:fork fired mid-conversation, session UUID rotated), SendMessage to a subagent that had completed before the fork fails with:
{"success":false,"message":"Agent <id> could not be resumed: No transcript found for agent ID: <id>"}
The transcript is not lost — it still exists on disk, in the pre-fork session's subagents/ directory. The fork carry-over mechanism symlinks running agents' transcripts into the new session dir, but does nothing for completed agents, and the resume lookup only searches the current session's subagents/. Resuming completed agents from transcript is a documented feature ("names keep working after an agent completes — a send resumes it from its transcript"), so this looks like a path-resolution gap in the fork, not GC.
Timeline (single occurrence, fully reconstructed from transcripts)
Local time; old session bc552010-…, new session 29a1e714-… (= the job id).
- ~11:55 — subagent A dispatched in background. Completes ~12:01, completion notification received with full result.
- 12:02:20 —
SessionStart:forkhook runs mid-conversation; all MCP servers disconnect/reconnect. Old session JSONL ends 12:02:19, new session JSONL starts 12:02:26 (first entry:queue-operation— the fork coincided with delivery of a queued user message to the job; the job'sstate.jsoncarriesrespawnFlagsincl.--reply-on-resume). - Subagent B, dispatched seconds before the fork, fails with the system notification "was checkpointed for the background fork but could not be resumed (resume failed)".
- Subagent C, dispatched fresh after the fork, works; its outputs now live under the new session UUID.
- ~12:25 —
SendMessageto completed pre-fork agent A →No transcript found for agent ID. - ~12:55 — control:
SendMessageto post-fork agent D, completed ~25 min earlier (comparable delay) → success, "had no active task; resumed from transcript". The only variable separating success from failure is pre- vs post-fork, ruling out a completion-age timeout.
Filesystem evidence
Under ~/.claude/projects/<project-slug>/:
bc552010-…/subagents/
agent-<A>.jsonl (294 KB — completed pre-fork builder, INTACT)
agent-<A>.meta.json
agent-<B>.jsonl (1.3 KB — the checkpoint-failed agent, barely started)
agent-<E>.jsonl (real file; agent E was RUNNING at fork time)
29a1e714-…/subagents/
agent-<E>.jsonl -> ../../bc552010-…/subagents/agent-<E>.jsonl ← symlink: running agent carried over
agent-<E>.meta.json (fresh)
agent-<C>.jsonl (post-fork agents: real files)
… no entry at all for completed agent <A>, nor for <B>
So: running agents are carried across via symlink (and keep working — E resumed fine); completed agents are stranded in the old dir, and the resume lookup (scoped to the current session's subagents/) can't see them.
Expected
Either the fork carries over all subagent transcripts (completed included, symlink or copy), or the resume lookup falls back to the parent/pre-fork session directory when an agent id isn't found locally.
Workaround
Manually symlinking agent-<id>.jsonl (+ a meta.json) from the old session's subagents/ into the new one restores resumability.
Repro sketch
- Start a background session (job) and dispatch a background subagent.
- Wait for the subagent to complete (notification received).
- Cause the session to fork — in our case it happened on delivery of a queued message to the job (
SessionStart:forkin the transcript, session UUID rotates). SendMessageto the completed agent id →No transcript found for agent ID, while<old-session>/subagents/agent-<id>.jsonlexists on disk.
Related (searched, none covers this case)
#38443 (cross-session resume limitation), #23821 (subagent files lost after compaction), #59248 (orphaned subagents dirs), #23707 (Web sandbox recycling) — none describes the running-symlinked / completed-stranded asymmetry on background fork.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗