[Bug] Remote control sessions dying with code 4090 worker supersession after 2026-07-17 update

Status Fixed / completed
Reported on v2.1.215
Maintainer reply None cached
Activity 1 comment · opened Jul 21, 2026 · closed Aug 25, 2026

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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗