[BUG] Cowork: desktop device bridge authenticates but device tools are never provisioned into newly created sessions (works in pre-existing sessions)

Additional reproduction on an officially supported setup (rules out distro/repack confounds)

Same failure reproduces on a fully official install, which removes the "unsupported distro" and "third-party repack" explanations:

• App: official Anthropic apt package claude-desktop 1.18286.2, installed from https://downloads.claude.ai/claude-desktop/apt/stable. Signing key verified: fingerprint 31DD DE24 DDFA B679 F42D 7BD2 BAA9 29FF 1A7E CACE, UID Anthropic Claude Code Release Signing <security@anthropic.com>.
• OS: Linux Mint (Ubuntu-based, meets the documented Ubuntu 22.04+ requirement).
• Session: brand new Cowork chat, created after the July 7 merge.
• Folder: a folder is shared and shows in the Context panel ("Ordner"), but is not functionally linked.

Result: device_list_dir, device_stage_files, device_commit_files, and device_bash all return "No such tool available." The remote-devices MCP server is absent from the session's server list (only Atlassian_Rovo, claude-code-remote, and visualize are present). The session context still advertises the device as reachable, so the capability gate is advertising a device it never provisions tools for.

This confirms the regression is independent of distribution and of the Fedora repack. It reproduces on the official Debian/Ubuntu package on a supported distro, consistent with the server-side capability-negotiation root cause described above.

Additional evidence (upgrades this from "suspected server-side" to demonstrated)

1. Reproduces on the official Anthropic package, not just the Fedora repack.

Installed the official apt package on Linux Mint (Ubuntu-based, meets the documented Ubuntu 22.04+ requirement): signing key verified (31DD DE24 DDFA B679 F42D 7BD2 BAA9 29FF 1A7E CACE), repo downloads.claude.ai, version claude-desktop 1.18286.2. New Cowork/Home session, folder shared via "Add folder" (shows in the Context panel), device tools still return "No such tool available". So this is not the repack and not an unsupported distro.

2. The client registers the full tool list to the bridge and authenticates. The client side is healthy.

From ~/.config/Claude/logs/main.log on app start:

[remote-tools-device] init: manta=off shrimp=on device=fedora
[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, filesystem__read_file, ...,
  filesystem__list_allowed_directories
[remote-tools-device] connecting wss://bridge.claudeusercontent.com/devices/<org-id>_<device-id>/fedora/bridge
[remote-tools-device] authenticated

The client publishes every device tool, opens the bridge socket, and authenticates successfully. Nothing is missing client-side. The newly created cloud session still reports the tools as unavailable, so the session never consumes the already-connected bridge.

3. Working vs. broken session: the folder mounts.

In a session where file access works, the shared folders are mounted into the cloud workspace VM:

[workspaceMcpServer] bash: vmStatus=ready ... vmCwd=/sessions/<vm>/mnt/pages,
  mounts=pages,dev,plans,<...>,uploads,.claude/skills,.claude/projects,outputs,...

In a newly created session, none of that happens: the shared folders are never mounted (only the read-only skills filesystem is present) and the device tools are absent. Same machine, same account, older session works, new session gets no local-file provisioning at all. [remote-tools-device] keeps authenticating fine throughout, so the break is specifically in per-session provisioning, not device auth.

4. manta / shrimp are server-delivered flags.

init: manta=off shrimp=on is logged every start, always adjacent to [growthbook] loaded 206 features (GrowthBook = feature-flag service). grep -rao 'manta[A-Za-z0-9_]*' /opt/Claude/resources/app.asar returns nothing, so the names aren't in the client bundle. The client just reports whatever the backend hands it.

Net: client registration and bridge auth are complete and correct on both the official package and the repack. Newly created sessions don't get the bridge tools wired in or the folders mounted, older sessions do. Consistent with a server-side per-session capability/provisioning gate.

Root cause narrowed + reliable workaround: it's the "Run new tasks in the cloud" setting

Found the switch that flips this between broken and working: Settings → "Run new tasks in the cloud" (the toggle under Cowork).

• Toggle ON (new tasks run in the Anthropic cloud sandbox): new sessions get no local file access. Device tools (device_list_dir, device_bash, …) return "No such tool available" and the shared folders are never mounted into the session VM.
• Toggle OFF (new tasks run locally on this machine): a new chat has full local file access immediately. The shared folders are listed and readable, no "No such tool available".

That reframes the earlier "old sessions work, new sessions don't" observation. It was never really old vs. new. It's local vs. cloud execution. Pre-merge sessions ran locally and worked; after the July 7 merge new sessions default to cloud execution, which hits the broken path. The "grandfathered old sessions" were simply still running in local mode.

Consistent with the container evidence: a broken cloud session runs in a …--remote_cowork container with only the read-only skills filesystem mounted (/mnt/skills), none of the shared folders, and no device tools wired in. A working (local) session has the full mount set (mounts=pages,dev,plans,…,uploads,outputs,…) via the local VM. So the failure is specifically in the cloud-execution path provisioning local file access into the session, not in the client, the distro, or the package (reproduced on both the official apt build and the Fedora repack).

Net:

• Workaround for anyone hitting this on Linux: turn off "Run new tasks in the cloud", new sessions then get local file access.
• The bug is localized to cloud-session provisioning of the device bridge / folder mounts. The desktop client publishes the full tool list to the bridge and authenticates fine (see earlier log excerpt); the cloud session just never consumes it.