Remote-control server/bridge pair survives after "Connection closed" is logged — orphaned for 13+ hours

Environment: Claude Code CLI on Linux (Ubuntu 22.04), remote-control feature accessed via SSH/Tailscale from a laptop client.

What happened: Connected to a remote-control session from a laptop client, then closed the client. The remote-server.log recorded the connection closing normally at the time of disconnect, but the corresponding server-side process pair (server --serve and server --bridge, bound to a socket under ~/.claude/remote/run/<id>/) kept running for over 13 hours afterward, fully orphaned, until manually killed.

Expected behavior: Per the Remote Control docs, closing the terminal or stopping the claude process is what ends a session, and a logged "Connection closed" event should correspond to actual teardown of the server-side serve/bridge processes.

Actual behavior: The log line and process lifetime were inconsistent — the log said the connection closed, but the processes did not exit and had to be killed by hand.

Impact: No obvious excess token usage was found, but this leaves stale server processes accumulating on long-running boxes with no built-in way to list/audit active remote-control sessions server-side, so orphans are easy to miss.

Repro steps:

1. Start a remote-control session on a server reachable via SSH.
2. Connect from a client (laptop/phone app).
3. Close the client app (not the server-side claude process).
4. Check ps on the server after the client disconnects — the serve/bridge pair may still be running well after the log shows "Connection closed."

Would appreciate confirmation on whether idle orphaned serve/bridge processes ever make outbound API calls, and whether a "list active remote sessions" command could be added server-side.