[Bug] `claude --continue` silently resumes existing conversation without indication or live session detection

Bug Description
claude --continue silently attaches a window to another window's live conversation, with no indication it did so ## What happened I had two terminal tabs open on the same project directory, deliberately labelled for two different workstreams. Tab A was running a long session on workstream A. In tab B I started Claude with claude --continue. --continue resumed tab A's conversation — the most recent one in that directory — into tab B. Nothing in tab B's session indicated this had happened. The agent in tab B received tab A's compacted summary, which stated "this window is dedicated to <workstream A>", took that as fact, and spent an hour doing workstream A's work: editing the same remote resource that the agent in tab A was editing at that moment. Both agents wrote to the same transcript file. Each saw the other's changes to the shared remote resource as edits appearing from nowhere, and each independently concluded "another session is editing this concurrently." Both then stopped, with contradictory partial diagnoses of the same problem. ## Why this is bad 1. --continue is topic-blind by design (most recent conversation in the directory) but presents its result as if the window simply started. Nothing distinguishes "attached to an existing conversation" from "started fresh" — not in the UI, not in context. 2. A compacted summary asserting "this window is dedicated to X" is highly persuasive to the resumed agent, and there is no signal available to it that would justify doubting that claim. 3. Two windows can drive one conversation simultaneously, interleaving appends into one transcript file (I have out-of-order timestamps proving it: an assistant message stamped 21:58:28 sits between lines stamped 22:02:18 and 22:02:42). 4. The human looks wrong. I had my tabs straight; the tool handed one of them the wrong conversation, and the resulting evidence — the transcript — pointed at me as the confused party. ## Reproduction 1. In directory D, run claude in tab A and start a conversation on topic A. 2. While tab A is still live, open tab B in directory D and run claude --continue. 3. Tab B is now in tab A's conversation. Both tabs append to the same transcript and can act on the same external resources. ## Suggested fixes - On --continue/--resume, state plainly in-session what was attached to: session id, topic, and whether that session is currently live elsewhere. - Warn or refuse when the target conversation already has a live process attached — this is the actively harmful case. - Consider making --continue decline to attach to a session that is currently active, and offer a fork instead. ## Workaround A user-level SessionStart hook that prints the session id, the real launch command, and other live claude processes, and flags when the launch was an attach rather than a start. That works, but every user hits this before the know to write it.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.238
• Feedback ID: d45fcbfc-a2b3-437b-b9b5-04e349669577

Errors

[]