[BUG] Backgrounding a session with in-flight subagents forks it, orphaning the original
Confirming "Background this session?" (← ←, or Ctrl-B) while subagents are in flight doesn't background the running session. The daemon spawns a new session id as the background job and seeds it with a copy of the transcript, so there are two sessions for one task:
- the new background session, which continues the work
- the original one, frozen at the hand-off but still listed in
--resumeand inclaude agents(FleetView) as if it was live, with its subagents shown as running
The in-flight subagents are not migrated either, the background session launches them again from scratch.
No work is lost since the background session completes, but it leaves a dead session that looks resumable, and the subagent work is done twice.
Related but not the same: #69712 (agent view / ← backgrounding) and #25700 (orphaned subagents on /exit).
Steps to reproduce
- Start a fresh foreground session.
- Ask for at least 2 long-running subagents, e.g "Spawn 3 agents that each
sleep 300then echo$RANDOM." - While they run, press
←, then←again and confirm "Background this session?".
A new session id appears, the original freezes but stays in --resume and FleetView, and the background session launches the agents again. Reproduced 4 times in one afternoon on 2.1.186, every time subagents were in flight.
Expected
The existing session moves to the background job and keeps its id, with its subagents. If a new id can't be avoided, the original should be retired so it's not offered for resume or shown as a live duplicate.
Evidence
From a filesystem watcher on ~/.claude/projects/<project>/, ~/.claude/jobs/ and ~/.claude/daemon.log, with the key presses timestamped separately (UTC):
| UTC | User action | On disk |
|---|---|---|
| 15:15:34 | submit prompt | foreground session dcb6b41e created |
| 15:15:44 to 47 | | 3 subagents spawned under dcb6b41e/subagents/ |
| 15:16:20 | 2nd ← (dialog shown) | nothing, the foreground keeps running |
| 15:16:34 | confirm | |
| 15:16:45.954 | | dcb6b41e writes its last line |
| 15:16:46.673 | | daemon.log: [bg] bg spawned bf194046 (slash) |
| 15:16:52 | | new session bf194046 created, 64 KB |
bf194046.jsonl starts with a byte-identical copy of dcb6b41e.jsonl and has the same 3 subagent ids (a4579950…, a5626c14…, ae2752e0…). It then spawned 3 new ones (aafc090d…, ad49d47…, a0bd574…) and FleetView showed "0/3 · re-launched 3 agents.". dcb6b41e never writes again and both sessions stay listed.
The fork happens on confirmation, here about 12 s after the key press because it waits for the current tool to finish. Showing the dialog doesn't fork, and "Stay" aborts cleanly.
Also the messages disagree about the subagents: the guard on the first ← says tasks "would be abandoned", the dialog body says they "carry over to the background session", its button says "tasks will be stopped", and the task count differs between the two screens.
Environment
Claude Code 2.1.186 on Linux (WSL2, kernel 6.6.87.2-microsoft-standard-WSL2), from a terminal inside an editor. The fork is logged by the daemon (~/.claude/daemon.log, ~/.claude/jobs/) so I don't think the terminal matters.
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
Example of "weird state" after the fork happens:
<img width="1249" height="241" alt="Image" src="https://github.com/user-attachments/assets/f7e5a9fa-7dc7-4476-b4eb-1359adcb5c2f" />
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Not a duplicate of these three, though there's a real root-cause overlap with one of them worth linking.
run_in_background/Bash tasks being relaunched after a ~90–120s timeout (area:bash). The only overlap is the phrase "relaunched as duplicates." Different mechanism, not related to session backgrounding./bgmishandles the in-flight turn), but it's a brief report with no repro and doesn't mention session forking, orphaned sessions, or subagent duplication.This report adds two specifics that none of the three cover:
--resumeand FleetView — it shows subagents as running, has no engine behind it, and never progresses.Plus deterministic reproduction steps, which #69006 lacks.
If maintainers want to consolidate, I'd suggest linking this to the open #69006 (same likely root cause) rather than auto-closing it against the already-closed #62118 — otherwise the repro and the orphaned-session symptom get buried with no live tracking. Adding a 👎 to keep this open in the meantime.
I can confirm this, this is really frustrating.
FWIW I got rid of this by doing this in settings.json:
``` json
"disableAgentView": true,