[BUG] Cloud Cowork sessions provisioned without remote-devices MCP despite authenticated device bridge — signCreateSessionBind not_registered, silent unbound fallback

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?

Cloud-mode Cowork sessions created from the Linux desktop app with a device folder
attached AT TASK CREATION receive the folder-connected metadata (the session's system
context correctly names the device and folder), but the cloud container is provisioned
with NO remote-devices MCP server at all — not disconnected, absent. mcp__remote-devices__*
tools never exist, /mnt/user-data/uploads is never created, and an MCP refresh returns
'Server "remote-devices" not found'. Restarting the app mid-session never retriggers the
handshake, so affected sessions are permanently bridgeless. "On your computer" (local VM)
mode works fine.

Meanwhile the desktop app's device bridge is verifiably healthy the entire time: main.log
shows [remote-tools-device] connecting to wss://bridge.claudeusercontent.com/devices/.../bridge
and "authenticated", with zero disconnects across the session-creation window, and
grantRemoteSessionFolders succeeds with zero errors. The cloud side is internally
inconsistent: the same provisioning pass that injects the folder-connected notice into the
session fails to wire the device MCP server.

Suspected mechanism — the only matching defect in 5 days of client logs — is the session↔device
bind signing failing with "not_registered" and the client silently proceeding without a bind
(see logs field). Sign-out/sign-in does not repair it and no device-registration activity is
ever logged, so there is no user-reachable fix.

Reproduced identically on 1.18286.2 and 1.22209.0 (latest; CCD 2.1.209). Ubuntu 26.04 LTS,
official apt package (downloads.claude.ai). Device: gaitmaps-nuc-box-255h.
Started after the Cowork files storage location was moved off a git-repo/Project folder,
followed by a reboot and folder re-trust.

Ruled out by direct evidence: stale mount bindings (#52432 — no artifacts.json, mounts
healthy), VM/bridge-socket death (#49491 — VM boots in ~7s, bridge is an in-process
websocket, no socat involved), mid-session-attach path (#50168 — fails with creation-time
attach), trust residue (isFolderTrusted -> true), app version (latest), local resources
(26 GB free RAM).

Four affected sessions on 2026-07-17 (EDT): cse_012aGu6dd1YG8y89ZcNTwG2J (16:48, 1.18286.2),
cse_01LKxMR6N5RqG7hXcnQjSo5n (17:09, 1.18286.2), cse_016arihJA2cQBFo7rQDM84ui (17:34,
1.22209.0), plus a post-sign-out/sign-in retest (~18:3x, 1.22209.0) — all FAIL.

Also: signCreateSessionBind failure should surface to the user and/or trigger device
re-registration — the silent "proceeding unbound" fallback makes this undebuggable from the UI.

What Should Happen?

Creating a cloud Cowork task with a trusted folder added in the creation dialog, while the
device bridge is authenticated, should provision the container WITH the remote-devices MCP
server: device_list_dir / device_bash / device_stage_files etc. available, and
/mnt/user-data/uploads mounted. If the session↔device bind cannot be signed
(cause=not_registered), session creation should fail loudly or trigger device
re-registration — not silently create a session that claims the folder is connected while
no device tools exist.

Error Messages/Logs

The only matching failure in 5 days of client logs (claude.ai-web.log):

2026-07-16 13:46:43 [warn] [LOCAL_SESSION] signCreateSessionBind failed; proceeding unbound {"errName":"Error","cause":"not_registered"}
2026-07-17 15:20:38 [warn] [LOCAL_SESSION] signCreateSessionBind failed; proceeding unbound {"errName":"Error","cause":"not_registered"}

Healthy bridge immediately before a failing creation (main.log):

2026-07-17 17:30:25 [info] [remote-tools-device] init: manta=off shrimp=on device=gaitmaps-nuc-box-255h
2026-07-17 17:30:25 [info] [remote-tools-device] connecting DO bridge with: get_device_info, device_list_dir, device_stage_files, device_commit_files, list_artifacts, create_artifact, update_artifact, device_request_folder_access, device_bash, project_memory_read, project_memory_write (+0 grand-prix, +0 local-mcp)
2026-07-17 17:30:25 [info] [remote-tools-device] connecting wss://bridge.claudeusercontent.com/devices/787af9d3-284e-449c-b7ee-9474e0f5283c_a311e56d-fa1a-4941-b4da-1c13e5c86401/gaitmaps-nuc-box-255h/bridge
2026-07-17 17:30:25 [info] [remote-tools-device] authenticated
(no rotate/reconnect/close lines until well after session creation)

Error-free session creation that then just stops — no bind/pairing lines follow (main.log):

2026-07-17 17:34:11 [info] LocalAgentModeSessions.isFolderTrusted: /home/gaitmaps/Downloads/CLAUDE -> true
2026-07-17 17:34:11 [info] LocalAgentModeSessions.setDraftSessionFolders: 1 folders
2026-07-17 17:34:31 [info] LocalAgentModeSessions.grantRemoteSessionFolders: cse_016arihJA2cQBFo7rQDM84ui [1]
2026-07-17 17:34:31 [info] Config file written
2026-07-17 17:34:31 [info] [oauth] using cached token for orgId=787af9d3-284e-449c-b7ee-9474e0f5283c
2026-07-17 17:34:31 [info] [VM] getVMStorageSubpath: vmStorageDir=/home/gaitmaps/.config/Claude/claude-code-vm, subpath=home/gaitmaps/.config/Claude/claude-code-vm

Inside the affected container (cse_01LKxMR6N5RqG7hXcnQjSo5n): MCP server list contains only
claude-code-remote and visualize; refresh of remote-devices returns 'Server "remote-devices"
not found'; no mcp__remote-devices__* tools exist; /mnt/user-data/uploads absent.

Possibly related (claude.ai-web.log): /edge-api/bootstrap/<org>/app_start returned 404
not_found for two org UUIDs (787af9d3-…, c5f8bbc1-…) at 2026-07-17 16:25–16:27
(request_ids req_011Cd8FvrRug8MTkxDn4QgJz, req_011Cd8FzeomcEgiP2jvbvxZv).

Related earlier failure: attaching the subfolder that is a Project space folder is rejected:
2026-07-17 16:10:04 [warn] grantRemoteSessionFolders rejected: /home/gaitmaps/Downloads/CLAUDE/Cowork

Note for triagers: main.log contains NUL bytes (~2026-07-15 onward region), so plain grep
reports "binary file matches" and hides later entries — use grep -a.

Steps to Reproduce

Environment preconditions (how this machine got into the failing state):

• Linux desktop app installed from the official apt repo (downloads.claude.ai), Ubuntu 26.04.
• At some point, Cowork "files storage" was set to a folder that is BOTH a git repo and a

claude.ai Project space folder (/home/gaitmaps/Downloads/CLAUDE/Cowork, flagged as
"protected location"), then repointed to a normal folder (/home/gaitmaps/CoworkFiles),
followed by an OS reboot and re-trusting the folder. All cloud sessions since then
exhibit the bug; there may be a stale/orphaned device registration server-side
(client bind attempts fail with cause=not_registered).

Steps:

1. Launch the Claude desktop app and confirm the device bridge is up:

grep -a "remote-tools-device" ~/.config/Claude/logs/main.log | tail -5
Expected and observed: "connecting wss://bridge.claudeusercontent.com/devices/.../bridge"
followed by "authenticated".

1. In the app, start a NEW Cowork task, run location "In the cloud".
2. In the task-creation dialog (before starting the task), add a trusted folder

(/home/gaitmaps/Downloads/CLAUDE). Note: the folder must NOT itself be a Project space
folder — those are rejected with "grantRemoteSessionFolders rejected" (separate issue).

1. Start the task. Host-side log shows a clean grant with no errors:

isFolderTrusted -> true; setDraftSessionFolders: 1 folders;
grantRemoteSessionFolders: cse_... [1]

1. In the session, send:

"Refresh MCP servers and list connected servers. Search for device_list_dir /
device_bash tools. Run device_list_dir on /home/gaitmaps/Downloads/CLAUDE."

1. Observe (actual): the session's system context says the folder on this device is

connected, but only claude-code-remote and visualize MCP servers exist;
remote-devices is absent ("Server 'remote-devices' not found"); no
mcp__remote-devices__* tools; /mnt/user-data/uploads does not exist.

1. Restart the desktop app while the session is open, wait for "authenticated" again,

and refresh MCP in the session — remote-devices never appears (pairing only happens
at session creation).

1. Repeat steps 2–6 after (a) upgrading 1.18286.2 → 1.22209.0 and (b) signing out and

back into the app — identical failure every time (4/4 sessions on 2026-07-17).

No code or files are needed to reproduce; the bug is in session provisioning. The
minimal check is steps 1–6: an authenticated device bridge + creation-time folder attach
should yield a session with the remote-devices MCP server, and does not on this machine.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.22209.0 (also 1.18286.2), Ubuntu 26.04, apt package

Claude Code Version

1.22209.0 / Linux (desktop app / Cowork)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

PowerShell

Additional Information

Note: terminal selection is not applicable — this bug is in the Claude desktop app
(Cowork cloud sessions / device bridge) on Ubuntu 26.04, not in a terminal or the CLI.
The actual terminal used for log collection was GNOME Terminal, which isn't listed.

Versions / environment:

• claude-desktop 1.18286.2 and 1.22209.0 (official apt repo: downloads.claude.ai/claude-desktop/apt/stable)
• Bundled claude-code (CCD) 2.1.209; VM bundle 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a
• Ubuntu 26.04 LTS, x64, Wayland; Electron 42.5.1 (on 1.18286.2)
• Web commit dfc5d56ae1857faed5ba26492d45995fa93a2ef5, desktop commit 77c938bac27689d6df971289c10759e512785c73 (at 1.22209.0 first launch)

Relevant configuration state (paths, no secrets):

• ~/.config/Claude/claude_desktop_config.json contains the CURRENT (correct) storage path:

"coworkUserFilesPath": "/home/gaitmaps/CoworkFiles"

• ~/.config/Claude/local-agent-mode-sessions/<account>/<org>/remote-session-spaces.json

correctly records every affected session with its folder, e.g.:
{ "sessionId": "session_016arihJA2cQBFo7rQDM84ui",
"folders": ["/home/gaitmaps/Downloads/CLAUDE"], "memoryEnabled": false }
(entries created by sessions attached via a Project space additionally carry a "spaceId")

• No artifacts.json exists anywhere under ~/.config/Claude (rules out orphaned-backing-folder

state of the kind described in #52432)

Server-side identifiers that may help you locate the failing pairing:

• Device bridge URL: wss://bridge.claudeusercontent.com/devices/787af9d3-284e-449c-b7ee-9474e0f5283c_a311e56d-fa1a-4941-b4da-1c13e5c86401/gaitmaps-nuc-box-255h/bridge
• Org: 787af9d3-284e-449c-b7ee-9474e0f5283c; account: a311e56d-fa1a-4941-b4da-1c13e5c86401
• A second org UUID (c5f8bbc1-e630-41cf-9aeb-1944c5715b9e) appears in bootstrap 404s —

possibly an orphaned identity relevant to the not_registered bind failures

• Failing session IDs and creation times are listed in the description
• Bootstrap 404 request IDs: req_011Cd8FvrRug8MTkxDn4QgJz, req_011Cd8FzeomcEgiP2jvbvxZv

Additional observations:

• Feature-flag snapshot at renderer spawn showed "yukonSilver": {"status":"unsupported",

"reason":"Checking virtualization support…","unsupportedCode":"unknown"} — possibly
unrelated, noted for completeness. remote-tools-device flags: manta=off shrimp=on.

• The local Cowork VM is fully healthy on the same machine (qemu boots ~7s, virtiofsd

serving, guest RPC connected, "API reachability: REACHABLE"), and "on your computer"
sessions work — the defect is exclusively in cloud-session device pairing.

• Full unredacted logs (main.log, claude.ai-web.log, cowork_vm_node.log,

coworkd-console.log, kernel-console.log) are preserved and available on request.

• A full diagnostic writeup with the complete hypothesis elimination (stale mounts, VM

death, mid-session attach, trust state, app version — all ruled out with evidence) was
produced during a structured debugging session and can be attached if useful.

Impact: cloud-mode Cowork with device folders is completely unusable on this machine.
Cloud mode is required for this user's workload (clinical gait-analysis calibration);
"run on your computer" is not a substitute. An in-app thumbs-down was also submitted from
a failing session to attach server-side telemetry.

bridge_bug_report.md