[Bug] Remote control sessions dying with code 4090 worker supersession after 2026-07-17 update
Bug Description
# Bug report — remote-control sessions dying: code 4090 worker supersession (regression since ~2026-07-17 update)
Platform: Claude Desktop on Windows 11 Pro 26200 (MSIX, Claude_pzs8sxrjxfjjc)
App version: 1.22209.3 (regression appears to start with 1.22209.0)
Bundled Claude Code: 2.1.215 (was 2.1.209 when it started; 2.1.215 did not fix it)
Org: e26afb19-b32e-40ee-a8d0-01ce3b68faa8
## Summary
Since 2026-07-18 my remote-controlled sessions repeatedly die with
Transport closed: this connection is no longer the active worker for the session (code 4090),
and the orphaned session then cannot be toggled off — the disable toggle throws
Failed to toggle remote control … Cannot read properties of undefined (reading 'session_url').
Only a full app restart recovers, which disconnects every session.
This is a regression, not a long-standing issue. It began the day after the 2026-07-17 update.
## Evidence: hard onset date
Occurrences of the literal string code 4090 across the rotated main.log files:
| log file | date span | events |
|---|---|---|
| main3.log | 2026-04-19 – 06-14 | 1 |
| main2.log | 2026-06-15 – 07-10 | 4 |
| main1.log | 2026-07-09 – 07-18 | 2 |
| main.log | 2026-07-18 – 07-21 | 27 (54 lines; every line is double-logged) |
5 events in ~3 months, then 27 in 3 days. First event of the storm: 2026-07-18 08:39:21.
## What changed immediately before
- Desktop app: 1.21459.3 (first seen 2026-07-16 16:34) → 1.22209.0 (first seen 2026-07-17 06:05)
- Bundled Claude Code: 2.1.205 (since 07-10) → 2.1.209 (first seen 2026-07-17 08:46)
Also new on that date: the log line [oauth] CLI requested token refresh after 401 appears zero times anywhere in the logs before 2026-07-17, then 58 (Jul 17), 56 (Jul 18), 38 (Jul 19), 122 (Jul 20). (I can't tell whether that is new behavior or a newly added log line — flagging it either way.)
Knock-on effect: app restarts per day ([sessions-bridge] Initializing bridge) ran a steady 2/day through Jul 17, then 10 on Jul 18.
2.1.215 installed 2026-07-21 09:41 and the problem persists — a burst hit at 17:46 the same day.
## Suspected mechanism
Two subsystems inside the same Desktop process appear to both connect as the active worker for one cloud session (cse_01Do2eRWsKhZBL65C8ujsE84): [sessions-bridge] (environment env_011QVeHmbKJVLhXsNvq1LYSg) and [remote-control]. Whenever either reconnects it claims the worker slot and closes the other with 4090. Token expiry drives the reconnects, so it fires on every refresh.
Two log excerpts supporting this:
``
2026-07-21 17:36:19 [sessions-bridge] Forcing session_ingress_token refresh for cse_01Do2eRWsKhZBL65C8ujsE84 (trigger=proactive_timer)
2026-07-21 17:36:19 [sessions-api] Reconnecting session cse_01Do2eRWsKhZBL65C8ujsE84 to environment env_011QVeHmbKJVLhXsNvq1LYSg
2026-07-21 17:46:54 [remote-control] bridge_state: failed — Transport closed: this connection is no longer the active worker for the session (code 4090)
2026-07-21 17:47:29 [remote-control] bridge_state: failed — … (code 4090)
2026-07-21 17:47:32 [remote-control] bridge_state: failed — … (code 4090)
2026-07-21 17:49:16 [remote-control] bridge_state: failed — … (code 4090)
2026-07-21 17:49:41 [remote-control] bridge_state: failed — … (code 4090)
2026-07-21 17:49:56 [remote-control] bridge_state: failed — … (code 4090)
`
Remote control superseding *itself* across its own JWT refresh:
`
2026-07-21 04:31:37 [remote-control] bridge_state: reconnecting — JWT expired — refreshing
2026-07-21 04:31:39 [remote-control] bridge_state: connected
2026-07-21 04:31:48 [remote-control] bridge_state: failed — … (code 4090)
2026-07-21 04:31:51 [remote-control] bridge_state: failed — … (code 4090)
`
After a burst, remote control never recovers on its own — the last successful bridge_state: connected on 2026-07-21 was **11:46:51**; every attempt after that was rejected 4090, including after a full app restart at 17:57.
## Second, related defect: the disable toggle throws
Once a session is orphaned this way, turning remote control off for it throws:
`
Failed to toggle remote control … Cannot read properties of undefined (reading 'session_url')
`
The toggle never flips; re-tapping reproduces it. Previously reported 2026-07-19 and 2026-07-20 (that report captured 6 sessions failing this way between 04:16–04:17).
## Ruled out locally
- No second Claude Desktop instance (all claude.exe processes share one start time).
- A local Telegram bot on this machine uses @anthropic-ai/claude-agent-sdk` on the same OAuth credential, but it was idle all day — no Claude jobs ran anywhere near the bursts.
- The 401 refreshes come from the Desktop app's own warm local CLI sessions…
Note: Content was truncated.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗