[BUG] Stale dispatch environments persist in mobile app; dispatching to them hangs at "Allocating sandbox" and creates unrecoverable ghost sessions

Summary

After a network drop while on the move, phone-dispatched sessions became permanently stuck "ghost" sessions. From client-side evidence, the root cause appears to be: environment registrations remain listed in the mobile app's directory picker even after they can no longer accept dispatches, and dispatching a new session to such a stale environment never fails — it hangs at "Allocating sandbox…" indefinitely, producing sessions that no client (mobile or desktop) can operate.

Environment

• Claude Code CLI 2.1.218 (macOS, Apple Silicon)
• Claude desktop app 1.24012.1 (macOS)
• Claude mobile app (iOS), Code tab
• macOS (Darwin 25.3.0)

Timeline

1. Dispatched several sessions from the iOS app to my Mac. While I was moving between locations (Wi-Fi ↔ cellular), the connection dropped.
2. Three sessions became ghosts: they still appear in the mobile session list, but sending the next instruction hangs forever. Opening the same sessions from the desktop app on the Mac also hangs. Searching the Mac's local state (~/.claude/sessions/*.json bridge session IDs, all ~/.claude/projects/**/*.jsonl transcripts, desktop app data) finds no trace of these session IDs — they appear to exist only server-side.
3. Starting a new session from the mobile app also stopped working (stuck at "Allocating sandbox…"), while the device itself still showed as "connected" in the mobile app. The device connection was in fact fine — a desktop-app session on the same Mac kept working normally the whole time. Stopping all listed sessions from the mobile app and closing every remote-control terminal on the Mac did not help: the device stayed "connected" and the stale directory entries remained in the picker.
4. Ran a fresh claude rc in a project directory. The listener was healthy (Ready, Capacity: 0/32, one ESTABLISHED TLS connection to Anthropic). Sent a message from the phone → stuck at "Allocating sandbox…" again, rc capacity stayed 0/32, and the new session ID again has zero local trace. status.claude.com showed "All Systems Operational" at the time.
5. Found the cause: the mobile app's directory picker listed three environments for the device — the live rc one (showing a "1 / 32" capacity badge) plus two stale entries (from earlier sessions/hosts) that no longer accepted dispatches. My earlier attempts had been routed to a stale environment. Dispatching to the live environment worked instantly.

Expected behavior

• Environment registrations should be cleaned up (or at least marked offline) when their host process exits or stops responding.
• Dispatching to an unreachable environment should fail fast with a clear error instead of hanging at "Allocating sandbox…" indefinitely.
• The resulting ghost sessions should be recoverable or clearly marked dead. Instead they stay in the session list and hang every client that opens them (there also seems to be no way to take them over from the desktop app, which defeats the "continue anywhere" story).
• The directory picker gives no reliable way to distinguish live environments from dead ones — the capacity badge appears to be the only hint.

Ghost session IDs (partially masked)

• session_01Lz…2L9, session_01Er…PfZ, session_01WW…3aU (from the original disconnect)
• session_01Ew…8PB (the "Allocating sandbox" repro above, with a healthy rc listener running)

Happy to share the full IDs privately if useful for server-side correlation.

Impact

Dispatch from mobile was effectively unusable for half a day until I diagnosed this from the Mac side (checking ~/.claude/sessions, transcripts, rc socket state, etc.). A user without terminal access would have no way to understand what is wrong or recover.