[BUG] --resume <id> --bg forks the session even without --fork-session
What happens. claude --resume <session-id> --bg starts a new session with a new id. The original stays asleep, untouched and unreachable.
What I expected. The original session to wake and keep its id. --help documents --fork-session as "When resuming, create a new session ID instead of reusing the original (use with --resume or --continue)" — which states that reusing the original is the default and forking is opt-in. I did not pass --fork-session, so I did not expect a fork.
Why the distinction matters. A fork is not a slightly-different success. It splits ownership: the original holds the history and is what every other reference points at, while the fork is a second session that knows the same past and diverges from that moment on. If I wanted the original awake, I now have two sessions with a claim on the same work and no way to merge them.
The workflow this blocks. I run a fleet of long-lived sessions, each owning one piece of work, and they hand context to each other with cross-session messaging. A sleeping session cannot receive a message, so a handoff needs it woken first — and the only route available forks it, which is exactly the outcome I am trying to avoid. The practical result is that the sessions I most need to reach are the ones I cannot reach: the ones idle longest are both the most likely to be running on a stale picture and the only ones that require waking.
Reproduction.
1. Start a session, note its id, let it go to sleep.
2. claude --resume <id> --bg # no --fork-session
3. `claude agents` shows a new session with a different id;
the original is still listed as asleep.What would fix it. Honour the documented default — --resume --bg without --fork-session reattaches to the existing id. If forking is deliberate for the background path specifically, then --fork-session's description is wrong and should say so.
Version. 2.1.228, macOS.
Related: #79830 (compact fork-resume retires the session id) and #76493 (resuming from the Agent View forks) report the same behaviour on other paths, which suggests it is systemic rather than specific to this invocation. #84058 requests agent-to-agent messaging with wake-on-delivery, which would make waking unnecessary — but that is a much larger request, and this is one behaviour that can be fixed on its own. #86082 is the other half of the same workflow problem: not being able to tell from the agent list which sessions are asleep in the first place.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Confirmed / reproduced on 2.1.235 (Linux): with an idle saved session
<id>(not running anywhere),claude --resume <id> --bg "next prompt"— no--fork-session— printsbackgrounded · 34096d1cand the work runs under a brand-new session id:claude agents --json --alllists the new id as a separate background row (carrying the original's name), a new transcript containing the copied history plus the new prompt is written, and the original transcript is left untouched.claude --helpon the same build still describes--fork-sessionas "When resuming, create a new session ID instead of reusing the original", so the background path forks regardless of that flag, as described.🤖 Generated with Claude Code
---
_Generated by Claude Code_
Adding a new path where this same forced fork happens, with launch-command evidence — this one triggers without any user invocation at all.
Setup: Windows 11, CLI 2.1.227, a long-running local session driven by
plugin:telegram@claude-plugins-official, with a user-created native scheduled task (self-paced wake) in that session. The session process is kept alive by a local watchdog (restarts it when unhealthy).Observed: At 2026-08-20 06:36Z a scheduled-task self-wake did not continue the authoritative session. The daemon-generated launch command (captured before cleanup) was:
So on this path the fork is decided at launch-command generation time —
--fork-sessionis injected by the daemon itself; no user ever passed it. Runner job metadata:selfWake=true,inFlight.kindsincludessession_cron, roster launchmode=resume, fork=true, restoresTranscript=true.Cost/impact detail worth adding to this issue: the forked session's first API call logged
cache_miss_reason.type=previous_message_not_found,cacheRead=0,cacheCreate=766,613tokens — i.e. every occurrence of this fork rebuilds the full context at the user's expense, on top of the identity split described above (our channel/observer still pointed at the original id while the task ran in the fork).Consistent with your systemic reading (#79830, #76493): background-path resume forks by default, contrary to the documented opt-in. The scheduled-task self-wake path makes it worse because no human is present to notice the split.
For your information: the label
reproducedon this issue does not prevent it from becoming stale and eventually auto-closed. See https://github.com/anthropics/claude-code/issues/87647 for details, and consider upvoting that for visibility.This means to avoid auto-closing, this issue needs to acquire at least 10 thumbs up, or get new comments every time before the 14 days stale bot interval expires.