Cowork: remote-devices file bridge disconnects repeatedly, including mid-operation
Summary
In the Claude desktop app (Cowork mode), the remote-devices file bridge (device_stage_files / device_bash / device_commit_files) disconnects intermittently — including mid-operation — and does not auto-recover within the session, even after the desktop app reports the device as reconnected.
Environment
- Product: Claude desktop app — Cowork mode, remote-devices file bridge
- Device:
khairuls-mac-studio-local(macOS, arm64) - OS: macOS 26.5.2 (build 25F84), Darwin kernel 25.5.0, arm64
- appVersion: 1.20186.1
- electronVersion: 42.5.1
- nodeVersion: 24.17.0
- Connected folder:
.../Khairulverse/Calendar/B&C Command Center/Bimoli Project Management - Date observed: 2026-07-14, timezone Asia/Jakarta
What happens
The remote-devices bridge drops intermittently and does not auto-recover within the session. In one working session it:
- Staged files fine
- Committed handoff files
- Performed a rename
…then the MCP server disconnected. It reconnected once (get_device_info succeeded), then dropped again mid-operation during device_stage_files with:
The device this session is bound to is not connected to the bridge.
Multiple reconnect attempts over ~several minutes failed. Notably, get_device_info intermittently succeeded while device_stage_files failed in the same window — suggesting a partial/inconsistent bridge state rather than a clean disconnect.
Impact
Blocked from reading two files staged from the connected folder. Had to fall back to manually pasting / dragging the files into chat.
Steps to reproduce
- Connect a folder in Cowork.
- Run a series of
device_stage_files/device_bash/device_commit_filescalls. - The bridge disconnects intermittently and stays down within the session even after the desktop app reports the device reconnected.
Expected behavior
The bridge should either stay connected for the duration of a session, or auto-recover cleanly so that all remote-device tools (not just get_device_info) work again after a reported reconnect.
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
+1 on macOS — Claude Desktop 1.24012.0, Electron 42.7.0, Node 24.18.0, macOS arm64 (Mac14,15), Cowork cloud session.
Bridge dropped mid-session three times in a single working session (same day). Each drop: all remote-devices tools deregister except get_device_info, which returns "The device this session is bound to is not connected to the bridge." No auto-recovery — RefreshMcpTools re-reads show toolCount stuck at 1; the connection is never re-dialed. Recovery only via forcing a fresh folder registration ("Add folder" on the session), with a ~2–5 minute propagation lag before tools reappear.
Note this session ALSO exhibited the new-session attach failure in #76054 before the drops began — the two issues look like siblings: (a) attach dispatch never sent at session creation, (b) no re-attach after transport drop. Both healed by the same re-grant trigger.
Same issue is happening to me. Is very frequent.
Likely root cause for this + #76054: since the ~2026-07-23 desktop build, the app rotates the device-bridge websocket on a fixed ~27–33 min cadence (
[remote-tools-device] rotating (drain_wait_ms=N inflight=N)in~/Library/Logs/Claude/main.log). Local reconnect takes ~1s, but cloud sessions surface it as a full MCP-server disconnect and only re-announce at the next turn. Full forensics (cadence table, drain budget, first-appearance date) + suggested fixes in #81248.Adding a Windows reproduction and one piece of hard evidence for the "state inconsistency rather than a complete network failure" reading in the original report, which matches what we see exactly.
Platform: Windows 11, Claude desktop app, cloud Cowork session with connected folders. This issue is currently labelled
platform:macos; it is not macOS-only.Three occurrences in six days, two of them blocking.
device_stage_filesreturned HTTP 503 on every attempt (one HTTP 500, "adding session file"), 5 attempts over ~7 minutes in batches of 8, 4, 1 and 6. Blocked a deliverable.device_bashreturned "The device this session is bound to is not connected to the bridge" on 3 consecutive calls and the wholemcp__remote-devices__*tool family was withdrawn from the session, then re-announced ~10 minutes later. Recovered with no user action. Blocked a file write mid-command.The evidence for state inconsistency. During occurrence 2 we verified the call was well-formed before concluding anything about the tool, and the result is a clean split between two endpoints:
device_list_diron the identical directory returned 54 entries after the transfer failures began. Mount healthy, path correct, identity correct.device_list_dirat the momentdevice_stage_fileswas returning 503 for them.So directory listing and file transfer are separate endpoints and only the transfer one was failing, in the same session, on the same path, in the same minute. That is the same shape as the
get_device_infosucceeds /device_stage_filesfails observation in the original report, with the addition that the failing side returns a specific 503.Ruled out: machine sleep. The laptop runs a keep-awake utility and the desktop app was confirmed open and not closed across all three occurrences.
Impact worth noting for prioritisation. The outage duration is not the cost. Occurrence 3 killed a write while it was in flight, and the damaging part was the ~15 minutes afterwards where the file's state was unknown and unverifiable from the session. On reconnect the write turned out never to have executed at all - a clean failure with no partial file - but that could only be established by reading the file back once the bridge returned. A session cannot distinguish "write landed", "write partially landed" and "write never ran" while the bridge is down, which makes any non-idempotent operation unsafe to retry blind.
Happy to supply timestamps or further detail if useful.