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.
What happens.
claude --resume <session-id> --bgstarts 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.
--helpdocuments--fork-sessionas "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.
What would fix it. Honour the documented default —
--resume --bgwithout--fork-sessionreattaches 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.