[BUG] Agents view: reopening a stopped background agent dispatches a blank `mode: prompt` worker — same session ID, intact transcript never loaded, original prompt re-injected

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest: #75929, which covers the worktree-relocation trigger of the same blank-resume family; the 2.1.207 fix for that variant does not cover this one)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

When a background (daemon) agent settles as killed (user stops it in the agents view, or the initial handoff worker dies) and the user then reopens/resumes it from the agents view, the reclaim dispatches a fresh mode: "prompt" worker with no resume target instead of resuming the session. The worker comes up with an empty conversation reusing the same session ID, re-injects the job's original intent as a new user prompt, and appends onto (or collides with, producing .orphaned-* stubs next to) the fully intact transcript. To the user, a long-running conversation "clears out" with no error.

The transcript is intact on disk the whole time — claude --resume <sessionId> from a terminal restores the full conversation. This is a dispatch bug, not data loss.

Environment

• macOS arm64 (Darwin 25.5.0)
• Daemon backend; reproduced on daemon v2.1.206 (2026-07-10) and v2.1.207 (2026-07-12) — so the 2.1.207 changelog fix ("background sessions that entered a git worktree resuming blank after a cold reopen") does not cover this path. No worktree involved; transcript never relocated.

Observed timeline (daemon.log, v2.1.207, 2026-07-12)

[2026-07-12T14:30:37.558Z] [bg] bg spawned 8984c5ed (slash)        <- background handoff from an interactive session
[2026-07-12T14:31:16.510Z] [bg] bg settled 8984c5ed (killed)       <- user stops it in the agents view; moves to Completed
[2026-07-12T14:31:26.309Z] [bg] bg claimed-spare 8984c5ed (fleet)  <- user reopens it from the agents view
[2026-07-12T14:31:35.507Z] [bg] bg settled 8984c5ed (killed)       <- comes up blank; killed/interrupted again

Identical sequence on v2.1.206 two days earlier (job 45cc2ff8): spawned (slash) 14:22:04 -> settled (killed) 14:22:08 -> claimed-spare (fleet) 14:22:09 -> blank.

Dispatch evidence (daemon/roster.json)

The initial handoff spawn is dispatched correctly and forks the parent conversation:

launch: { mode: "resume", sessionId: "<parent>.jsonl", fork: true }   source: slash

The fleet reclaim of the same job after it settled is dispatched with no resume at all:

launch: { mode: "prompt", fork: null }   source: fleet    <- no session/transcript target

state.json's sessionId/resumeSessionId are correct and the child .jsonl exists with full forked history (in the 45cc2ff8 case: 291KB, 9 user / 11 assistant messages, same project dir as the job cwd) — the reclaim simply never consults them.

Effect on the transcript

• The blank worker adopts the same session ID and appends fresh metadata (ai-title, agent-name, mode, permission-mode) plus a re-injected copy of the job's original intent as a new user turn onto the intact transcript.
• In some occurrences the collision instead produces a <sessionId>.orphaned-<ts>-<hash>.jsonl stub containing only ai-title/agent-name lines.
• A related earlier variant (observed 2026-07-06 on v2.1.199/201, and 2026-07-08): the initial handoff worker itself is settled (killed) seconds after spawn, before the fork ever writes assistant turns — the subsequent fleet reclaim then shows the same amnesia.

What Should Happen?

Any of:

1. A fleet reclaim of a job whose session .jsonl exists resumes it (mode: resume), exactly like the initial slash dispatch does; or
2. the reclaim honors resumeSessionId from the job's state.json; or
3. at minimum, reopening fails loudly instead of silently starting an empty conversation under the same session ID and re-running the original prompt.

Steps to Reproduce

1. In an interactive session with some history, background it (agents-view handoff) so a daemon bg job is created; verify the child session .jsonl contains the forked history.
2. Stop the agent in the claude agents view (it settles killed and moves to Completed).
3. Reopen it from the agents view.
4. The conversation is blank; daemon/roster.json shows the new worker dispatched mode: "prompt" with no resume target; the original intent is re-injected as a fresh prompt; the historied .jsonl is intact on disk.

Claude Model

Opus

Is this a regression?

Unknown — observed on 2.1.199 through 2.1.207.

Claude Code Version

2.1.207 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Additional Information

Recovery that works today (may help other users hitting "my background agent cleared out"): find the job's sessionId in ~/.claude/jobs/<short>/state.json and run claude --resume <sessionId> in a terminal — full history loads. If the child transcript is empty (the initial worker died before forking), the history is still in the parent session's .jsonl; it can be located by grepping ~/.claude/projects/ for the job's intent string.

🤖 Generated with Claude Code