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] authenticated
What was ruled out on the client
- Network:
claude.ai, api.anthropic.com and bridge.claudeusercontent.com were 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.
vmcompute and hns were 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.
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.comand sent its connect frame, but never got anauthenticatedreply. Every attempt ended withhandshake 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:
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)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.served get_device_info(x3). A new cloud session binds to the device.remote-bashstarts. The Cowork service log shows the VM process exited with code 0 at 00:06:21.pong timeout (1 consecutive) — resetting. The command's reply is never delivered, and the cloud session times out after 190 s.connecting→connect frame sent: device_id keyed→ 15 s laterhandshake timeout. Backoff grows to 30 s.connect frame sent→handshake timeout, repeated.[remote-control] bridge_state: "connected"), while the device handshake kept timing out.connect frame sent: device_id keyed→authenticatedon 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 timeoutand the remaining one was interrupted by the Windows restart. None succeeded. Log excerpts (org ID removed):What was ruled out on the client
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.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.Environment
Asks