Backgrounding an interactive session seeds a new job with only the last (already-answered) prompt, dropping all prior context and its own response

Summary

Backgrounding an interactive session (--bg / "background this conversation") spawns a new job whose seed intent is the last prompt the user sent in the original conversation — not a continuation of that conversation's actual state. When the job later runs, it starts a brand-new session containing only that one prompt: everything before it (the whole prior conversation) and the already-completed answer that prompt received in the original session are both absent. The job then silently re-does the same work from scratch, unaware it was already finished.

(Correction from the original report: I had mischaracterized the seeded prompt as the conversation's "opening" prompt. It's actually the most recent one — the one already answered right before backgrounding.)

Repro (reconstructed from job/session state files)

1. In an interactive session, run a multi-step research task across several turns. The last turn's prompt gets a full answer — tool calls, sub-agent workflow, delivered response — all visible and complete in that session's own transcript (~/.claude/projects/<proj>/<session-id>.jsonl).
2. Background the conversation.
3. The new job's ~/.claude/jobs/<id>/state.json has "interactiveLineage": true and an "intent" field equal to that last prompt — the one already answered in step 1.
4. The job sits queued, then eventually runs (in my case ~19h later) in a brand-new session-id. That new session's transcript opens directly with the seeded intent as the first message, with no prior turns and no trace of the answer already given to it in the original session.
5. Because the two sessions have different ids with no link between them, from the terminal it looks like the same question is being asked twice for no reason. Interrupting the redundant run mid-flight reads as if history/context had been lost — it hadn't; the original transcript is untouched — but the new session never had it to begin with.

Impact

• Wastes tokens/cost re-running an already-completed multi-agent workflow.
• Misleads the user into thinking session history was corrupted. Confirming it wasn't required manually diffing two separate .jsonl files by timestamp — there's no parentId/respawnOf field linking the new job back to the source conversation.

Expected behavior

Backgrounding a conversation should carry that conversation's actual history into the job, not just replay its last prompt as a fresh intent with no context. At minimum, the job should be able to tell that the seeded prompt was already answered in the source session before restarting the same work.

Environment

• Claude Code CLI, version field in session jsonl: 2.1.221
• macOS

Related (found via search, all appear to be the same underlying "session fork drops context, keyed only by seed intent" family — filing this as a distinct trigger path in case it's useful for root-causing, happy to have it merged/closed as duplicate if maintainers judge it's the same fix):

• #72012 — closest match: reopening a stopped/completed background session from Agent View spawns a new session-id, injects only the launch intent, prior conversation is not carried over. Same symptom, different trigger (Agent View reopen vs. backgrounding a still-live interactive session).
• #76493 — related fork cluster: resuming from Agent View forks the session (new id); in that variant conversation history is retained but the per-session task-list store is dropped.
• #78777 — related fork cluster: resuming a backgrounded --agent <name> session keeps history but silently reverts to the default agent identity/toolset.
• #54086 (closed) — different mechanism (ScheduleWakeup re-firing a full slash command) but same symptom class: harness re-executes a stale prompt without checking whether the work was already done.