[Bug] Session management: /exit lists sessions instead of terminating, duplicate session forks unmanageable

After some time -- My supposed two BACKFILL07 sessions are one background and one interactive. The one I was interacting with told me it's in fact a background session, and I can't find the supposed "interactive" one at all.

An unrelated third session (the one supposed to receive the messages) told me that the mystery interactive session is running in the same Zellij environment where I'm running all of these, and it even found a tab "BACKFILL" and activated it as where it thought the interactive session would be. And that is where the other, "background" session, the one I'm interacting with, is running!

At this point I shared my inference:

That worked but that is the session that told me it was started as a background session. This is behaving as though the same session has two IDs!!!

Claude's response:

That tracks with something concerning, not just cosmetic: the same underlying process (PID 33793, --resume BA...) appears to be registered under two different peer identities — 30f472 (bg) and 366e09 (interactive) — in the ListAgents directory. That's not normal; a single Claude process should have one peer ref. Best guess at what happened, from the process tree: - PID 75427 (claude bg-spare --bg-spare .../e895437b.claim.sock) is a pre-warmed background-agent pool process — infrastructure that sits idle until "claimed" for a task. That's likely 30f472. - PID 33793 (claude --resume BA..., in the ft3 → BACKFILL tab) is a separate interactive terminal process that resumed the same named session (BACKFILL07). That's 366e09. If both are alive and pointed at the same session transcript, you effectively have two processes racing on shared state — one from the background pool, one you started/resumed by hand in ft3. That's a real risk: duplicate actions (e.g., two Jira ticket creations), transcript corruption, or one process clobbering the other's writes. I don't have visibility into Claude Code's internal session-locking to say whether it protects against this. Given the risk, I'd treat this as: don't let both keep running. Since you're now looking at the BACKFILL tab in ft3 directly, that's the safest place to end it — exit or Ctrl+C from inside that pane rather than relying on cross-session messages, since messaging clearly isn't reliably reaching whichever of the two identities is the "real" live one. Want me to check ps aux again to confirm whether PID 75427 (the bg-spare one) is still alive right now, so you know if you're dealing with one live process or genuinely two?

When I exited the BACKFILL07 that I can interact with, the one that tells me it's background, I get this:

 ▐▛███▛█   Claude Code v2.1.241
▝▜██████▀  Sonnet 5 · ~/code/advertising-travel-media-network-campaign-performance-processor
  ▝▝ ▝▝    3 awaiting input · 0 working · 1 completed

Your conversation moved to the background — enter opens it · esc returns to it · ctrl+c twice quits

Needs input
 ✻ BACKFILL07    confirm exit intent or next step                                                                                   19h
 ✻ PR306         let me know what needs adjusting — and whether you still want to explore the skill-derivative option (#3 from ea…   6d
 ✻ DUSK03        Not committed yet — want this batch in, or more to add first?                                                      31d

Completed
 ∙ VALIDATOR13   Three rebriefs in .claude/plans/rebriefs/: HQL+tags.json on MDP-18140 branch; Scala copy on isolated worktree; v…   6m

This sort of exit menu has only started showing up for me in recent days. I assume it's a new feature, but it seems to be connecting with all kinds of running sessions, even from completely different projects/started in different repos. And in the case of BACKFILL07 I wonder if it somehow represents that the session got forked into two, or at least two IDs.

Now that I've closed down the one I'm interacting with, the other session still sees the running one and confirms they were the same process:

That's the same socket (xxxxx.sock) that sent me the original FT35 brief — so 30f472 and that first message are the same process, confirmed. There's also a paired PTY-host process for it:

What a nightmare. Claude researched its own docs and thinks this is what happened:

Feature: called cross-session messaging, on by default (Claude Code v2.1.224+ Mac/Linux) — you didn't opt in, and it needed no setup to start showing you every running claude process on the machine (interactive, -p, and bg), plus a pre-warmed "supervisor worker" it keeps ready. This explains the bg-spare processes we saw. What caused the mess: resuming claude --resume <name> while that name was already running as a background process forks it into a separate session instead of reattaching — exactly what happened with BACKFILL07 twice. How to scope it down, in order of how disruptive: 1. crossSessionInbound: refuse — refuse inbound messages from peers (least disruptive) 2. Deny SendMessage/ListAgents in permission rules — blocks the whole mechanism 3. isolatePeerMachines: true — require approval for cross-machine only 4. disableAgentView: true (or CLAUDE_CODE_DISABLE_AGENT_VIEW=1) — disables agent view entirely 5. claude daemon stop --any — kills the supervisor, which also kills background sessions

I can see how cross-session messaging (XSM) could be a great feature but the way you've introduced it is disastrous for my workflow. I don't intentionally run the same session twice but it seems like something that could happen. Maybe this same mess would have happened pre-XSM if I had tried to access the same session but it's certainly expanding the blast radius.

Why not get the harness to detect the second access of the same session, and warn me?