[BUG] Backgrounding a session with in-flight subagents forks it, orphaning the original

Preflight Checklist

• [x] Searched existing issues — no exact match. Related: #69712 (agent-view / ← backgrounding), #25700 (orphaned subagents on /exit, different trigger).
• [x] Single bug report.
• [x] Reproduced on latest at filing — 2.1.186. Reproduced 4× over one afternoon.

What's wrong? (the core problem)

Confirming background (←← → "Background this session?" → confirm, or Ctrl-B) while
subagents are in flight does not background the running session in place. The daemon spawns a
new session id as the background job and seeds it with a copy of the transcript — so you end
up with two sessions for one task:

• the new background session, which actually continues the work, and
• the original foreground session, now orphaned: frozen at the hand-off point, doing

nothing, yet still listed in --resume and in claude agents (FleetView) as if it were live.

That orphan is effectively semi-dead — it looks resumable and shows its subagents as still
running, but it has no engine behind it and will never progress. (Screenshot: FleetView shows the
same task twice — one entry working, one stuck "needs input"/"awaiting", plus its abandoned
subagents.)

Secondary effect: the in-flight subagents are not migrated to the background session — they're
abandoned with the orphan and re-launched from scratch.

No final user work is lost (the background session completes), but you're left with a confusing
duplicate, a dead-but-listed session, and repeated subagent work.

Steps to reproduce (deterministic)

1. Fresh foreground session.
2. Prompt it to spawn ≥2 long-running subagents, e.g. *"Spawn 3 agents that each sleep 300

then echo $RANDOM."*

1. While the agents are in flight, press ←, then ← → "Background this session?" → confirm.
2. Observe: a new session id appears; the original freezes but stays in --resume/FleetView; the

background session re-launches the agents from scratch.

Expected

Backgrounding should re-home the existing session into the background job (same session id),
or — if a new id is unavoidable — retire the orphan so it isn't offered for resume and doesn't
appear as a live duplicate. In-flight subagents should carry over rather than being re-launched.

Actual / evidence

Captured with a filesystem watcher over ~/.claude/projects/<project>/, ~/.claude/jobs/, and
~/.claude/daemon.log, with user keypress timestamps logged independently (times UTC):

| UTC | User action | On disk |
|---|---|---|
| 15:15:34 | submit prompt | foreground session dcb6b41e created |
| 15:15:44–47 | — | 3 subagents spawned under dcb6b41e/subagents/ |
| 15:16:20 | 2nd ← (dialog shown) | no new session, no daemon event — foreground keeps running |
| 15:16:34 | confirm ("yes") | — |
| 15:16:45.954 | — | foreground dcb6b41e writes its last line (freezes) |
| 15:16:46.673 | — | daemon.log: [bg] bg spawned bf194046 (slash) (fork committed) |
| 15:16:52 | — | new session bf194046 created, 64 KB |

Fork signature (verified on the two transcripts):

• bf194046.jsonl shares dcb6b41e.jsonl's byte-identical prefix and carries the **same 3

subagent IDs** (a4579950…, a5626c14…, ae2752e0…).

• After the fork dcb6b41e never writes again (orphaned); bf194046 continues.
• Both are listed together in --resume / FleetView.

Timing note: the fork is committed on confirmation (here ~12 s after the keypress, deferred
until the in-flight tool reached a safe point — "backgrounding after the current tool finishes").
It is not committed when the dialog appears, and declining ("Stay") aborts cleanly with no
fork (separately verified). The dialog itself behaves correctly.

Subagent hand-off is lossy

The background session carried the 3 original subagent references but then spawned 3
brand-new subagents (aafc090d…, ad49d47…, a0bd574…); FleetView showed
"0/3 · re-launched 3 agents." The live subagent processes belonging to the original are not
migrated — the original's subagents are abandoned and the work is redone in the background
session. (Observed on every reproduction.)

Messaging (secondary)

The flow shows inconsistent claims about the subagents: a first-← guard says tasks "would be
abandoned"; the confirm dialog body says they "carry over to the background session" while its
button says "tasks will be stopped"; and the task count differs between the two screens. One
accurate message would help.

Environment

• Claude Code 2.1.186
• Linux (WSL2, kernel 6.6.87.2-microsoft-standard-WSL2)
• Reproduced from a terminal hosted inside an editor; the fork is daemon-level

(~/.claude/daemon.log, ~/.claude/jobs/), so it's very likely host-environment independent.

Suggested fixes

• Re-home the existing session id into the bg job instead of forking; if a new id is required,

retire/tombstone the orphan so it isn't offered for resume or shown as a live duplicate.

• Migrate in-flight subagents to the background session rather than abandoning/re-launching them.
• Unify the background-confirmation messaging into one accurate statement.

Can you reproduce this?

Yes — deterministic whenever subagents are in flight at background time.

Of course that might not suit everyone :-) but in my case agent view creates more trouble than it's worth.