[BUG] Cowork: remote-devices bridge returns Cloudflare 502; both new and pre-existing sessions lose all device tools

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

In Cowork on macOS, the remote-devices MCP server fails with a Cloudflare 502
and no mcp__remote-devices__* device tools are available. The failure is not
limited to newly created sessions: a session created roughly two days earlier,
which had a working bridge and successfully listed the connected folder at its
own start, now also returns 502 for any live read or write. It can only serve the
cached snapshot it took at session start.

So the bridge is failing for new and pre-existing sessions alike, and neither can
recover. It is not specific to one folder or one project either: an unrelated
folder connected to a different project fails the same way. Connected-folder
metadata is still delivered to sessions normally in every case, so the grant
layer and the transport layer are failing independently of each other.

Unlike the related reports linked below, this failure is loud: it surfaces a
concrete HTTP status at connect time rather than silently missing tools.

What Should Happen?

The remote-devices server should connect and provision the device tools
(device_list_dir, device_bash, device_stage_files, device_commit_files,
get_device_info), so the connected folder can be read and written.

Separately, and regardless of the root cause: a session whose transport enters a
failed state should be able to re-dial. Right now it cannot. Once the connection
state is failed, it stays failed for the entire lifetime of that session, which
turns a transient upstream 502 into a permanent loss of the folder.

Error Messages/Logs

Reported at session start. Note that the error text arrives already truncated —
it ends in "detail …". That ellipsis is in the delivered string, not something
I trimmed:

remote-devices (502): "Error POSTing to endpoint: { type :
https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-502/ ,
title : Error 502: Bad gateway , status :502, detail …"

Attempting to refresh the server mid-session returns:

[{"server":"remote-devices","status":"not_connected","error":"server connection
state is \"failed\" — this tool only re-reads tool lists over live connections
and never dials"}]

Steps to Reproduce

1. On macOS, connect a local folder to a project in the Claude desktop app.

In my case: /Users/torben/Documents/Marvin42 (local disk, not cloud-synced).

1. Start a new Cowork session from that project.
2. Observe the session-start report: remote-devices is listed as failed to

connect with a Cloudflare 502.

1. Attempt to load or call any mcp__remote-devices__* tool. No such tools exist

in the session — a tool search returns no matches, only the failed-server
notice.

1. Now open a Cowork session created several days earlier, one that previously

had a working bridge, and ask it to list the same folder. It reports the same
502 and can only return the cached listing it made at its own session start.

1. To rule out anything folder-specific: connect an unrelated folder

(/Users/torben/Downloads) to a different project and start a new session from
there. Identical 502. The folder is reported as attached to the session, but
the bridge itself does not answer.

Observed on 6 new sessions on 2026-08-27 from approx. 11:30 CEST onwards, across
two different projects and two different connected folders, plus the pre-existing
session described in step 5. Every one failed identically. Because a 502 is by
definition a transient upstream condition, I would expect it to clear on retry.
It does not.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A — Claude desktop app 1.37937.3 (28dcf5), build 2026-08-26T19:52:45Z. Not the Claude Code CLI; this is the Cowork desktop experience.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Environment

• Device: MacBook Pro (M5 Pro), macOS 26.5.2 (25F84)
• Claude desktop app: 1.37937.3 (28dcf5), build 2026-08-26T19:52:45Z
• Connected folder: /Users/torben/Documents/Marvin42 (local disk, not cloud-synced)
• First observed: 2026-08-27, approx. 11:30 CEST (UTC+2)
• No terminal is involved; the "Terminal/Shell" field above is not applicable to

Cowork, but the form requires a value.

On the regression question
The bridge worked two days ago. I cannot attribute the break to a client version,
because the pre-existing session — which had a live bridge and had already
listed the folder — lost it mid-session and returns the same 502. That points at
something server-side rather than at the installed build.

Tried without success

• Full quit and relaunch of the Claude desktop app
• Disconnecting and reconnecting the folder to the project
• Starting 6 new sessions, all failing identically
• Falling back to a pre-existing session that previously worked
• Connecting an unrelated folder (/Users/torben/Downloads) to a different

project and starting a fresh session from there

Possibly related
Closest match, but that one describes intermittent drops that sometimes recover,
whereas this fails hard at connect time with a 502 and never recovers:

• #77385 — remote-devices file bridge disconnects repeatedly, including mid-operation

Same end result (no device tools) but a different, silent signature, and all
three are scoped to newly created sessions only, which this one is not:

• #76054 — Windows: sessions created after app update never receive device-bridge connection
• #76095 — bridge authenticates but device tools are never provisioned into new sessions
• #86647 — session reports zero connected folders while the project UI shows one connected