Remote-control session worker self-terminates on "Epoch mismatch (409)" instead of recovering

Environment

• Claude Code CLI 2.1.210 (Linux, Ubuntu droplet)
• Sessions launched as claude --remote-control "<name>" --dangerously-skip-permissions, driven from the macOS desktop app and claude.ai/code web client
• Long-running named sessions in tmux; multiple concurrent sessions

Summary
A remote-control session's CLI worker terminates itself when its bridge epoch is superseded (HTTP 409), rather than recovering. The session disappears from the app and must be manually relaunched with --resume. In-progress work halts. This happens multiple times per day, sometimes within 15–30 minutes of launch.

Log signature (consistent across many sessions/days)

[bridge:repl] Inbound control_request subtype=end_session
[bridge:repl] Sent control_response for end_session request_id=... result=error
CCRClient: Epoch mismatch (409), shutting down
[bridge:repl] CCR v2: epoch superseded (409) — closing for poll-loop recovery
SSETransport: Stream read error: The operation was aborted.

Note the log says "closing for poll-loop recovery," but the process fully exits (tmux pane dies) — it does not recover.

Trigger
Occurs when the client re-attaches to a session — switching between sessions in the app, opening the same session from a second client, or a flaky reconnect. A newer connection sends end_session / claims a new epoch, and the existing worker shuts down.

Also frequently seen during normal operation

SSETransport: Stream read error: The socket connection was closed unexpectedly.

Expected: the worker survives an epoch supersession / end_session from a stale attachment and keeps the session alive (or actually performs the "poll-loop recovery" it logs).
Actual: the worker exits; the session drops from the app and requires manual --resume.

Impact: unreliable long-running remote-control sessions; frequent manual restarts; interrupted work.