[BUG] Windows Desktop: device bridge handshake never acknowledged for ~18 min (connect frame sent → handshake timeout), survives reboot + app update, then self-recovers
What's wrong
For about 18 minutes, the bridge stopped answering the Windows desktop app's device handshake. The client opened the WebSocket to wss://bridge.claudeusercontent.com and sent its connect frame, but never got an authenticated reply. Every attempt ended with handshake timeout. A full reboot plus an app auto-update applied during that reboot didn't change anything. It then recovered by itself, with no change on the client.
While it was down, cloud sessions bound to this device failed with:
The device this session is bound to is not connected to the bridge.
A cloud session that had just bound fine lost its first shell command. The command ran and exited 0 in the Cowork VM, but the result never came back, and the session gave up after Device '<device>' did not respond within 190s.
status.claude.com showed all systems operational and no incident the whole time.
This is related to, but different from, #77385 / #91111 (mid-session drops) and #84463 (reconnect storm). Here the WebSocket opens but the device handshake is never acknowledged, for a sustained period, across a reboot and two app versions.
Timeline (UTC, 2026-09-25, from %LOCALAPPDATA%\Claude\Logs\main.log)
| Time | Event |
|---|---|
| 00:04:48 | socket closed: 1006. Reconnects at 00:04:51: authenticated, replies redelivered=0 resent=6 expired=0 dropped=0. Routine; this happened 5 times earlier that day and each recovered at once. |
| 00:05:20 – 00:06:18 | Link healthy: served get_device_info (x3). A new cloud session binds to the device. |
| 00:06:20 | That session's first remote-bash starts. The Cowork service log shows the VM process exited with code 0 at 00:06:21. |
| 00:06:42 | pong timeout (1 consecutive) — resetting. The command's reply is never delivered, and the cloud session times out after 190 s. |
| 00:06:44 – 00:10:12 | Each attempt: connecting → connect frame sent: device_id keyed → 15 s later handshake timeout. Backoff grows to 30 s. |
| 00:10:42 | Windows restart. The pending app update (2.7032.0 → 2.9939.2, downloaded hours earlier and held back because the app was running) is applied at logon. |
| 00:13:22 – 00:23:04 | Same pattern on the new version, after reboot: connect frame sent → handshake timeout, repeated. |
| 00:19:08 | In the same app process, Remote Control for a local Code session connected fine ([remote-control] bridge_state: "connected"), while the device handshake kept timing out. |
| 00:24:11 | connect frame sent: device_id keyed → authenticated on the first try. Nothing changed on the client. No drops since, and cloud sessions work again. |
28 connect attempts between 00:06:44 and 00:24:11; 27 ended in handshake timeout and the remaining one was interrupted by the Windows restart. None succeeded. Log excerpts (org ID removed):
00:04:51 [remote-tools-device] connect frame sent: device_id keyed
00:04:51 [remote-tools-device] authenticated
...
00:06:20 [remote-bash] vmUser=<redacted> mounts=<folder>:rw cmdLen=153
00:06:42 [remote-tools-device] pong timeout (1 consecutive) — resetting
00:06:44 [remote-tools-device] connecting wss://bridge.claudeusercontent.com
00:06:44 [oauth-v2] using cached token for orgId=<redacted>
00:06:44 [remote-tools-device] connect frame sent: device_id keyed
00:06:59 [remote-tools-device] handshake timeout
... (after reboot, app 2.9939.2)
00:13:22 [remote-tools-device] connecting wss://bridge.claudeusercontent.com
00:13:23 [remote-tools-device] connect frame sent: device_id keyed
00:13:37 [remote-tools-device] handshake timeout
...
00:23:04 [remote-tools-device] handshake timeout
00:24:11 [remote-tools-device] connect frame sent: device_id keyed
00:24:11 [remote-tools-device] authenticatedWhat was ruled out on the client
- Network:
claude.ai,api.anthropic.comandbridge.claudeusercontent.comwere all reachable on TCP 443 during the outage. There was no proxy (WinHTTP and user settings both direct). A mesh VPN is installed but has no exit node, so internet traffic doesn't go through it. The Windows event logs show no network changes between 23:55 and 00:11. - Auth: the cached OAuth token was used throughout, and nothing rejected it. There was no 401 or close code; the server simply never replied.
- App update: the failure began at 00:06 on 2.7032.0, before the update to 2.9939.2 was installed (00:12). It continued the same way on both versions.
- Cowork VM / Hyper-V: the VM was running; it rebooted cleanly at 00:13 and its Plan 9 shares mounted in 9 s.
vmcomputeandhnswere running. This is not the Windows 11 Plan 9 regression from Sept 9–14 (KB5124008, fixed by KB5129195). That one showed "no Plan9 drive shares mounted" and left the bridge up. - Windows Update: the last OS update was installed 2 days earlier and the link worked for the 2 days after it.
- Local MCP servers: they started more slowly after the reboot, but they're unrelated to the handshake. The handshake failed before and after they connected.
Environment
- Windows 11 Pro, build 26200.9550, x64
- Claude Desktop (MSIX): 2.7032.0 at failure → 2.9939.2 after the restart
- Bundled Claude Code 2.1.281
- Cowork Linux VM on Hyper-V
- Cloud Cowork sessions bound to this device, with one connected folder and six local MCP servers
Asks
- Please check server-side logs for device handshakes that were accepted but never acknowledged, between 00:06 and 00:24 UTC on 2026-09-25. The client-side evidence points to the device's bridge endpoint rather than the network or auth. Remote Control on the same bridge host worked during that window.
- Consider reporting a handshake that is accepted but never answered differently from a network failure. Today it shows as the same "Not connected" in the UI and "not connected to the bridge" in cloud sessions, which sends users off to reboot, reinstall or check Windows Update for nothing.
- When the device link drops during a tool call whose result is already computed (here the VM command exited 0 in 1 s), consider failing the call quickly or redelivering the result after reconnect, instead of letting the cloud session wait 190 s.
Showing cached comments. Read the full discussion on GitHub ↗
10 Comments
Same symptom here, on the same app version, shortly after your report. It still hasn't recovered on my end.
Environment: Windows, Claude Desktop 2.9939.2 (CCD 2.1.281). Clean reinstall with all supporting folders deleted, plus several reboots. None of it helped.
Symptom: The desktop app shows my own computer as "Asleep or app closed" while I'm using the app on it. Cloud sessions bound to it fail with The device this session is bound to is not connected to the bridge. Affected session: cse_01A2VzZsevyvrzEPXHLxVb8n.
Log (2026-09-24, CDT / UTC-5, which is 00:53–00:59 UTC on 2026-09-25):
19:53:05 [remote-tools-device] connecting wss://bridge.claudeusercontent.com
19:53:06 [remote-tools-device] connect frame sent: device_id keyed
19:53:06 [remote-tools-device] device registered — refreshing row PK
19:53:06 [remote-tools-device] device_registered (not authenticated) — resetting to refresh row PK
19:53:06 [remote-tools-device] reconnect #1 in 1562ms
19:53:08 [remote-tools-device] connect frame sent: device_id keyed
19:53:23 [remote-tools-device] handshake timeout
...
19:58:39 [remote-tools-device] connect frame sent: device_id keyed
19:58:54 [remote-tools-device] handshake timeout
19:58:54 [remote-tools-device] reconnect #13 in 27468ms
The same device_registered (not authenticated) then handshake timeout sequence also happened on an earlier app start at 19:49:24. Across that log (19:49–19:58), there were 19 handshake timeouts and zero successful authentications.
Other notes:
Server response before the timeouts: Every run starts with the server returning device_registered (not authenticated). After that, no connect frame gets an authenticated reply. Your log doesn't show that line, so it may help locate the problem, or it may be related to the reinstall creating a new device identity (see #88692).
Other connections work: The claude-in-chrome bridge connected and authenticated on the same host (bridge.claudeusercontent.com) during this time. So network, OAuth and the app itself look fine. Only the device handshake is failing.
Folder consent works: The folder consent prompt appeared, and I allowed it (grantRemoteSessionFolders: user allowed). The sessions just never get a live device link to use it.
Client-side fixes don't help: Reinstalling, rebooting and re-sharing folders make no difference. As in your case, this looks like it needs a fix on the server side.
I can share the full main.log if that helps.
Same issue here: Windows desktop, started at the same time, and still not recovered after 45+ minutes
I'm seeing the same thing on a second machine, starting within seconds of this report. Unlike the original report, mine has not recovered by itself.
Environment
Windows desktop app, updated to 2.9939.2 during the outage (no change)
Claude Code / VM SDK 2.1.281
Cowork VM healthy the whole time (Startup complete, API reachability: REACHABLE, VM already connected)
Windows Defender only: no third-party antivirus, proxy or VPN
Timeline (UTC, 2026-09-25)
00:04:48 [remote-tools-device] rotation due — re-presenting credential in-band
00:04:49 [remote-tools-device] credential re-verified in-band
00:06:07 [remote-tools-device] pong timeout (1 consecutive) — resetting
00:06:10 [remote-tools-device] connect frame sent: device_id keyed
00:06:25 [remote-tools-device] handshake timeout
... same connect → handshake timeout loop, 40+ reconnects ...
Note the credential rotation at 00:04:48, the same second as the socket closed (1006) in the original report. The link had last worked cleanly before that (00:06 was the first failure).
After sign-out/sign-in and updating the app, it's still failing:
00:49:01 [remote-tools-device] device registered — refreshing row PK
00:49:01 [remote-tools-device] device_registered (not authenticated) — resetting to refresh row PK
00:49:19 [remote-tools-device] handshake timeout
00:52:06 [remote-tools-device] device registered — refreshing row PK
00:52:06 [remote-tools-device] device_registered (not authenticated) — resetting to refresh row PK
00:52:25 [remote-tools-device] handshake timeout
Device registration succeeds, but the handshake is never acknowledged.
Already ruled out
Test-NetConnection bridge.claudeusercontent.com -Port 443 succeeds
The claude-in-chrome bridge on the same host connects and pairs in under 1 s during the outage, which matches the "Remote Control connected fine" anomaly in the original report
App restart, full sign-out/sign-in and app update: none of them helped
status.claude.com shows all systems operational
This points to a server-side problem on the device bridge endpoint around 00:04–00:06 UTC, possibly linked to the credential rotation, and it looks like it affected more than one device. Happy to share more logs if that helps.
Same failure on macOS, so it isn't Windows-only.
Environment: M4 MacBook Pro, macOS 27.0, Claude Desktop 2.9939.2 (same build as the Windows reports)
Symptom: In a cloud Cowork session, the computer picker shows "Claude Desktop (macOS) · Asleep or app closed" while I'm actively using the app on that Mac.
Log (
~/Library/Logs/Claude/main.log, EDT / UTC-4, i.e. 00:56–01:03 UTC on 2026-09-25). Same connect → handshake timeout loop on every attempt:Last auth/registration lines (same log, EDT):
The last successful
authenticatedwas at 00:09:30 UTC, a few minutes after the ~00:06 UTC onset in the original report. At 00:44:18 UTC the server returneddevice_registered (not authenticated), the same pattern shown in both comments above. There's been noauthenticatedsince (as of 01:05 UTC).Network is fine:
curl -sI https://bridge.claudeusercontent.comreturnsHTTP/2 426from Cloudflare (EWR edge) immediately.Tried: restarted the app and rebooted the Mac, no change. I did not reinstall or sign out, so the
device_registered (not authenticated)response here isn't tied to a reinstall-created identity (#88692).Different OS and network, but the same time window, build and signature as the Windows reports, which points at the device-handshake endpoint rather than anything client-side.
Same issue on macOS 15.7.7, Claude Desktop 2.9939.2 / Claude Code 2.1.281. Started 2026-09-25 00:05 UTC (same moment as this report) and has not self-recovered — still
connect frame sent: device_id keyed→handshake timeoutat 01:45 UTC (150+ timeouts). Briefly authenticated once at 00:09 UTC, thenpong timeoutat 00:16 and never re-authenticated.Tried:
ant-device-registry.jsonaside (regenerated identical)Bridge reachable (HTTP 426 in 90ms), no proxy.
Same failure here, Windows, but it did NOT self-recover. Last [remote-tools-device] authenticated at 2026-09-25 00:04:48 UTC; since then every attempt is connect frame sent: device_id keyed → handshake timeout (reconnect #44+ and counting). TCP 443 to bridge.claudeusercontent.com succeeds, no 1006 closes, no 401s. Sign-out/sign-in and full app restart did not help. Still failing at 02:08 UTC.
Same symptom here today (Sept 24, 2026), but on Windows 10 Home, build 10.0.19045 — not Windows 11 like the OP. Worked fine earlier in the day, then started showing "device not connected" out of nowhere.
Ruled out on my end before finding this issue:
Adding this in case it's useful to confirm this isn't Windows-11-specific.
Same issue here on Windows 11. Claude Desktop auto-updated from 2.7032.0 to 2.9939.2 during a relaunch/reboot on Sept 24. Everything worked all day before that.
Since the update, every Cowork task, including brand-new ones, shows my PC as "asleep" in the top corner while I'm actively using it. Claude in the task can't reach Desktop Commander or anything local. In Settings → Cowork, my PC is listed as "This computer," and "Last seen" resets to 1 minute each time a task tries to reach it, so something is getting through, but the connection never actually holds.
Tried: relaunching the app twice, rebooting, signing out and back in, starting a new task, resetting the app in Windows Settings, and toggling "Only on this computer." Nothing fixed it. It has lasted well over an hour, much longer than the 18 minutes described above.
Same here.
Supposedly Gemini thinks this update could be a part of the problem: https://support.microsoft.com/en-us/servicing/os/windows-11/2026/09/kb5124008-windows-11-24h2-25h2-security-update
it is back for me, did nothing except waiting...
me too, desktop + usage limitations. let's go