### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? # [BUG] Linux beta: device bridge authenticates and folders are granted, but Cowork cloud sessions never receive the device (remote-devices tools absent)

[BUG] Linux beta: device bridge authenticates and folders are granted, but Cowork cloud sessions never receive the device (remote-devices tools absent)

Open 💬 0 comments Opened Jul 10, 2026 by jeroalva

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?

[BUG] Linux beta: device bridge authenticates and folders are granted, but Cowork cloud sessions never receive the device (remote-devices tools absent)

Environment

Claude Desktop: 1.18286.2 (official apt package from downloads.claude.ai/claude-desktop/apt/stable)
OS: Pop!_OS 22.04 (Ubuntu 22.04 base), GNOME on X11 (XDG_CURRENT_DESKTOP=pop:GNOME, XDG_SESSION_TYPE=x11)
Arch: x86_64
Keyring: gnome-keyring running and providing org.freedesktop.secrets (verified via busctl --user list)
Plan: Personal account (claude.ai subscription)
Network: no VPN/proxy; regular chat and Cowork cloud sessions work normally

Summary

On the Linux desktop beta, remote (cloud) Cowork sessions can never reach connected local folders. The desktop side completes every step successfully — device bridge websocket connects and authenticates, folder is trusted, folders are granted to the session — but the session runtime never receives the remote-devices toolset (device_list_dir, device_stage_files, etc.). Inside the session, the device appears permanently offline. Reproduced across app restarts, OS reboot, fresh sign-in, brand-new conversations/projects, and multiple different folders.

Likely related: #54378 (Windows, closed as duplicate), #45962, #49545, #45937.

Steps to reproduce

Install claude-desktop 1.18286.2 from the official apt repo on Pop!_OS 22.04, launch, sign in.
Start a new Cowork conversation; attach any local folder via "Add folder" (folder-trust prompt appears and is accepted).
Ask Claude in that session to list files in the folder.

Expected

The session binds the device bridge; Claude can call device_list_dir and read the folder.

Actual

Claude in the session reports the device is unreachable: "I can't reach your computer right now — the connection to '<device>' isn't active in this session."
Verified from the session side: the remote-devices MCP server is absent from the session's server list; none of the device_* tools exist in the tool registry (confirmed via tool search from within the session).
The folder's metadata DOES reach the session (the session context lists the connected folder), so registration works — only the live tool channel is missing.

Desktop-side evidence (main.log)

Bridge connects and authenticates fine:

[remote-tools-device] init: manta=off shrimp=on device=<hostname>
[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_bash, project_memory_read, project_memory_write
[remote-tools-device] connecting wss://bridge.claudeusercontent.com/devices/<orgId>_<deviceId>/<hostname>/bridge
[remote-tools-device] authenticated

Folder attach + grant for a fresh session completes:

LocalAgentModeSessions.isFolderTrusted: <folder> -> false
LocalAgentModeSessions.addTrustedFolder: <folder>
LocalAgentModeSessions.setDraftSessionFolders: 1 folders
LocalAgentModeSessions.grantRemoteSessionFolders: cse_01EG6h... [1]
[oauth] using cached token for orgId=<orgId>       <-- no auth errors

And then nothing. grep cse_01EG6h... main.log shows the two grantRemoteSessionFolders lines are the last entries ever logged for that session — no transport attach, no tool registration, no error. The grant never round-trips into the session runtime.

Secondary bug: `session_stale_relogin` fails silently and latches

While debugging, we found the elevated-scope OAuth (user:inference user:file_upload user:profile) failing with:

oauth failed: authorize returned 403 {"type":"permission_error","message":"Session is not fresh enough to grant elevated access. Sign in again to continue.","details":{"error_code":"session_stale_relogin"}}
[oauth] short-circuiting fresh /authorize on latched session_stale_relogin failure

Two problems with this behavior:

No user-facing surface. The app shows folders as "connected" in the UI while the bridge silently lacks elevated access. The user sees no prompt to re-authenticate anywhere. Reboots/reinstalls don't help; only an explicit sign-out + sign-in clears it.
The failure latches ("short-circuiting fresh /authorize on latched ... failure") and is never retried until restart, so even transient staleness becomes permanent for the app's lifetime.

Suggested fix: surface session_stale_relogin as a re-login prompt (like other elevated-access flows), and don't latch the failure indefinitely.

(Note: in our case, re-login did clear the OAuth failure — authenticated + cached token afterward — yet sessions still never receive the device, which is the primary bug above.)

Possibly relevant (expected?) Linux-beta warnings

[startVM] VM not supported (linux/x64), skipping
[Bundle:status] rootfs.img missing
yukonSilver: {"status":"unsupported","reason":"Checking virtualization support…"}

If the session-side device attach has any dependency on the local VM path that isn't gated off on Linux, that could explain why the grant never completes.

Troubleshooting already performed

OS reboot, app relaunches (GUI and from terminal)
Full sign-out → quit (pkill) → relaunch → fresh sign-in (cleared the session_stale_relogin OAuth failure — verified in logs)
New conversations, new project, multiple different folders (Dropbox-synced and plain home folders)
Verified official package (apt policy), no community builds present
Verified gnome-keyring / Secret Service is available
Cleared SingletonLock/SingletonSocket
No VPN/proxy; status.anthropic.com shows no incident

What Should Happen?

The session binds the device bridge; Claude can call device_list_dir and read the folder.

Error Messages/Logs

Actual


Claude in the session reports the device is unreachable: "I can't reach your computer right now — the connection to '<device>' isn't active in this session."
Verified from the session side: the remote-devices MCP server is absent from the session's server list; none of the device_* tools exist in the tool registry (confirmed via tool search from within the session).
The folder's metadata DOES reach the session (the session context lists the connected folder), so registration works — only the live tool channel is missing.


Desktop-side evidence (main.log)

Bridge connects and authenticates fine:

[remote-tools-device] init: manta=off shrimp=on device=<hostname>
[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_bash, project_memory_read, project_memory_write
[remote-tools-device] connecting wss://bridge.claudeusercontent.com/devices/<orgId>_<deviceId>/<hostname>/bridge
[remote-tools-device] authenticated

Folder attach + grant for a fresh session completes:

LocalAgentModeSessions.isFolderTrusted: <folder> -> false
LocalAgentModeSessions.addTrustedFolder: <folder>
LocalAgentModeSessions.setDraftSessionFolders: 1 folders
LocalAgentModeSessions.grantRemoteSessionFolders: cse_01EG6h... [1]
[oauth] using cached token for orgId=<orgId>       <-- no auth errors

And then nothing. grep cse_01EG6h... main.log shows the two grantRemoteSessionFolders lines are the last entries ever logged for that session — no transport attach, no tool registration, no error. The grant never round-trips into the session runtime.

Secondary bug: session_stale_relogin fails silently and latches

While debugging, we found the elevated-scope OAuth (user:inference user:file_upload user:profile) failing with:

oauth failed: authorize returned 403 {"type":"permission_error","message":"Session is not fresh enough to grant elevated access. Sign in again to continue.","details":{"error_code":"session_stale_relogin"}}
[oauth] short-circuiting fresh /authorize on latched session_stale_relogin failure

Steps to Reproduce

Steps to reproduce

Install claude-desktop 1.18286.2 from the official apt repo on Pop!_OS 22.04, launch, sign in.
Start a new Cowork conversation; attach any local folder via "Add folder" (folder-trust prompt appears and is accepted).
Ask Claude in that session to list files in the folder.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Desktop: 1.18286.2 (official apt package from

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗