Remote Control: sessions attached to a bridge are unrecoverable after the bridge process dies, even when the replacement bridge re-adopts the same environment

Environment

• Claude Code CLI 2.1.237
• Windows 11 (bridge host), sessions driven from the Claude mobile app
• claude remote-control bridge kept alive by a local watchdog

What happened

When a claude remote-control bridge process dies unexpectedly (ours died silently after ~35h of uptime; nothing in its output, no crash event on the host), every session attached to it is permanently stranded, even though:

1. a replacement bridge starts seconds later (our watchdog),
2. the replacement re-adopts the same environment id via bridge-pointer.json, and
3. the sessions remain visible and selectable in the mobile app.

Messages sent from the mobile app to those sessions are accepted by the UI but never dispatched to the replacement bridge — its debug/output shows no trace of them. From the user's perspective the messages simply vanish (the app re-renders from the authoritative transcript, which never received them). There is no error, no "session disconnected" state, and no way to recover the session from the phone; the only remedy is ending each dead card by hand and starting over (local transcripts survive, so --resume works on the desktop).

Observed 2026-08-23: 5 live sessions lost in one bridge death.

Expected

A replacement bridge that re-adopts an environment should re-adopt (or receive redispatches for) that environment's live sessions — or, failing that, the app should mark such sessions as disconnected/errored instead of silently dropping sends into them.

Repro sketch

1. Start a bridge with N attached mobile sessions.
2. Kill the bridge process.
3. Restart it in the same directory (same environment id is re-adopted).
4. Send a message from the mobile app to a pre-kill session.

The message is accepted and never delivered; the session never responds again.