Remote control goes offline every ~8h and never recovers (worker epoch race → code 4090 → retry budget exhaustion)

App: Claude desktop (macOS), v1.20186.1, claude-code 2.1.205, macOS 26 (Darwin 25.3.0)
Feature: Remote control (phone → local machine), SDK-adapter transport (gate 583857784 ON)

Symptom

Remote control shows the machine online for a few hours, then the phone can no
longer connect. Re-enabling remote control in the desktop app always fixes it
immediately. Recurs every day, multiple times.

Root cause (from main.log + bundled JS)

1. Every ~7.9 h (ingress-token TTL 28499 s) the session manager fires

forceIngressTokenRedispatch(trigger=proactive_timer), which calls
POST /v1/environments/{env}/bridge/reconnect on its own session.

1. The server re-dispatches the session; the poll loop receives it and takes

the "Session already active; refreshing session_ingress_token from
duplicate work" path, i.e. keeps the existing connection and (on the SDK
adapter) calls reconnectTransport with the new token.

1. The re-dispatch has superseded the live connection's worker epoch.

10–40 min later the server closes the still-open connection:
bridge_state: failed — Transport closed: this connection is no longer the
active worker for the session (code 4090).

1. Recovery then dead-ends: reconnect attempts are capped at 6 (~1 min of

backoff: 1s → 30s), each reconnect is kicked again by the same stale-epoch
condition, then redispatchCappedSession runs at most RRe = 2 times,
after which the code logs
"transport stays dead until app restart or system resume" — and that is
exactly what happens. powerMonitor resume/darkwake resets
capRedispatchAttempts, which is why sleep/wake cycles mask the bug and
long awake stretches expose it.

Evidence (2026-07-12, all times +08:00)

18:50:56 [sessions-bridge] Forcing session_ingress_token refresh for cse_016aQ… (trigger=proactive_timer)
18:50:56 [sessions-api] Reconnecting session cse_016aQ… to environment env_01H9…
18:50:58 [sessions-api] Poll received work: id=cse_016aQ…
18:50:58 [sessions-bridge] Session cse_016aQ… already active; refreshing session_ingress_token from duplicate work
19:01:43 [remote-control] bridge_state: failed — Transport closed: this connection is no longer the active worker for the session (code 4090)
19:10:22 [remote-control] bridge_state: failed — … (code 4090)
19:52:57 [remote-control] bridge_state: connected        ← 51 minutes offline

Same pattern on 07-10 (5 × 4090 between 19:16 and 22:50 following the 18:34
duplicate-work refresh), 07-11 (02:29 refresh → 02:56 4090 → more at 04:15,
09:47), and ~56 occurrences of code 4090 across the last month of logs. The
JWT-expiry reconnect path (reconnecting — JWT expired — refreshing), by
contrast, recovers in ~3 s every time.

Suggested fixes

• On the ingress-token redispatch path, hand over the worker epoch atomically

(or tear down + fully re-register the transport) instead of leaving the old
epoch registered until the server kills it.

• Treat close code 4090 while remote control is user-enabled as retriable:

re-register a fresh worker (new epoch) rather than reconnecting the
superseded one, and don't let capRedispatchAttempts end in a permanently
dead transport while bridge-state.json still says enabled: true.

• Reset the redispatch budget on a timer (not only on system resume).