Remote Control: every session attached to a bridge becomes unrecoverable when the bridge process ends, even though a replacement re-adopts the same environment

Summary

When a Remote Control bridge process ends, every session attached to it becomes unrecoverable through Remote Control — even though the replacement bridge comes up within seconds and re-adopts the same environment. The sessions are not resumable from the picker; the cards for them remain, but selecting them does not reconnect. The underlying work is only recoverable locally, by resuming each session's local id from a terminal.

Note on a previous report

I filed this before, in #89228, and withdrew it — that report attributed the bridge's death to a silent product crash, and the real cause turned out to be a maintenance task on my own machine force-killing the process. That diagnosis was mine and it was wrong.

I am re-filing because the withdrawal only invalidated the premise, not the subject. Whether an attached session should survive its bridge process ending is independent of what ended it, and a deliberate local kill is actually a cleaner reproduction than the mystery crash I originally described — it is deterministic and requires nothing unusual.

Reproduction

1. Attach several sessions to a Remote Control bridge (observed with 7).
2. Terminate the bridge process itself (any means — in my case Stop-Process -Force from an unrelated scheduled task).
3. Observe that the attached session host processes are children of the bridge and end with it.
4. A replacement bridge starts and re-adopts the same environment.

Expected: either the re-adopting bridge picks the sessions back up, or there is a grace window in which a reconnecting bridge can reclaim them.

Actual: the sessions are gone as far as Remote Control is concerned. Their cards persist in the picker but lead nowhere, so the picker's state and the real state disagree until the dead cards are ended by hand.

Why it matters beyond my own bug

Any bridge exit produces this: an OS-level kill, a machine going to sleep, an ordinary crash, a maintenance restart. The blast radius is every session attached to that bridge at once rather than one session, and there is no signal to the sessions themselves — work in flight simply stops mid-turn. In my incident two of the seven were mid-tool-call, with no completion record written.

What makes it costly is the asymmetry: the transcripts survive and are perfectly resumable locally, so the work is not lost — but the path back to it through Remote Control is, and the picker actively misleads about which is which.

Environment

Windows 11, Remote Control bridge hosting 7 sessions, replacement bridge started ~60s after the kill by a supervising task and re-adopting the same environment. Happy to supply logs or run a narrower reproduction if useful. If this is intended behaviour rather than a gap, that is a fine answer and I will stop re-filing it — I would just like to know which it is.