[BUG] /exit prompts to remove worktree even when other Claude Code sessions are still active in it — accidental remove breaks live sessions

Preflight Checklist

• [x] I have searched existing issues and this one is not a duplicate
• [x] This is a single bug report

Environment

• Claude Code: 2.1.150
• Platform: macOS (Darwin 25.3.0)
• Worktrees feature: standard .claude/worktrees/<name> layout

Summary

When multiple Claude Code sessions are running in the same worktree, exiting any one of them prompts the user with the keep-or-remove worktree dialog as if that session were the sole owner. If the user picks remove, the worktree is wiped while the other sessions are still actively working in it — losing in-progress edits, breaking running tools, and leaving the surviving sessions pointed at a deleted directory.

The exit prompt should be suppressed (or at minimum show a clear warning) when the harness can detect that other Claude Code sessions still have the same worktree as their cwd.

Steps to Reproduce

1. From a project root, create/enter a worktree, e.g. claude --worktree resignapp. The worktree path is .claude/worktrees/resignapp.
2. In a second terminal pane/tab, start another Claude Code session in the same worktree directory (either cd .claude/worktrees/resignapp && claude, or claude --worktree resignapp again).
3. Both sessions are now alive and operating against the same working tree.
4. In session #1, type /exit.
5. The keep-or-remove worktree prompt appears as if session #1 were the only user.
6. Pick remove (intentionally, or by accident — the prompt's default action is right there).
7. The worktree is removed. Session #2 is now sitting in a deleted cwd; subsequent tool calls fail and uncommitted work in that worktree is gone.

Expected Behavior

When /exit would otherwise show the worktree-remove prompt, the harness should first check whether any other Claude Code session has this worktree path as its cwd. If yes, then either:

• Preferred: silently keep the worktree and skip the prompt entirely (with a one-line notice like \"Worktree kept — N other Claude Code session(s) still active here\"), since removal is unsafe by definition while another session holds it.
• Acceptable: still show a prompt, but make the dangerous answer require confirmation and surface the count of active sessions, e.g. \"2 other Claude Code sessions are still using this worktree. Removing it now will break them and discard their uncommitted work. Type 'remove anyway' to proceed.\"

The current behavior — offering a one-keystroke \"remove\" answer that silently destroys other live sessions' working tree — is unsafe.

Actual Behavior

The prompt is rendered identically whether or not other sessions share the worktree. There is no signal in the UI that other sessions exist, no count, no warning. \"Remove\" proceeds unconditionally and the surviving sessions are left in a broken state (deleted cwd, lost uncommitted edits).

Impact

• Data loss: any uncommitted changes in the surviving sessions go with the worktree.
• Workflow breakage: long-running background bash, MCP servers (e.g. Metro, simulator-server), and queued tool calls in the other sessions all fail at once.
• No undo: git worktree remove plus the directory teardown leaves no equivalent of a stash or reflog for the working-tree files.

I have hit this accidentally in real use — this isn't theoretical.

Detection Signal

The harness should already have, or can easily synthesize, a list of active Claude Code session cwds (this kind of cross-session awareness exists in adjacent features — e.g. the bottom toolbar in #56330 has visibility into other sessions on the same machine, and ~/.claude/projects/<encoded-cwd>/ directories are per-cwd already). A check at /exit time of the form \"is any other live claude process's cwd inside this worktree path?\" is sufficient.

Workarounds

• Always answer \"keep\" — works only if you remember every time, and the prompt's default position invites accidents.
• Issue #58034 proposes a settings.json key to default the prompt to keep. That would mitigate the noise, but does not address the multi-session correctness axis: even a user who deliberately wants \"remove\" as their global default should not be allowed to remove a worktree that other sessions are currently using.

Related Issues

• #58034 — settings.json default for the worktree-exit prompt. Complementary, not a duplicate: that issue is about a static per-user default; this one is about a dynamic per-exit safety check based on other live sessions.
• #56330 — Bottom toolbar conflates agents from multiple sessions on the same machine. Different surface, but confirms cross-session awareness already exists in the harness.
• #46444 — Catastrophic data loss from worktree auto-cleanup. Same family of bug (worktree teardown destroys live work); this is a distinct trigger (explicit \"remove\" answer with concurrent sessions) so should be tracked separately.
• #48965 — Multi-session coordination primitives. The detection mechanism this bug needs would naturally live alongside that work.

Additional Context

I run multiple sessions per worktree routinely (terminal panes, plus secondary claude --worktree <existing-name> invocations on the same name). Same-cwd concurrent sessions are clearly an intended use case — see #51617 which discusses them as a first-class scenario. The exit-prompt path appears not to have been updated to account for that.