[BUG] Linux beta: Cowork local VM never starts ("VM not supported (linux/x64), skipping") on a requirements-compliant machine — cloud sessions cannot link to the computer

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?

Environment

• App: Claude Desktop 1.18286.2 (official Linux beta), installed ~2026-07-09
• OS: Ubuntu Server 24.04.4 LTS + ubuntu-desktop-minimal, kernel 6.8.0-134-generic, x86_64
• Hardware: Lenovo ThinkCentre M920q, Intel i7-9700T, 32 GB RAM, ~77 GB free on /
• Virtualization: VT-x enabled (lscpu → Virtualization: VT-x); /dev/kvm present and openable by the app's user (explicit ACL user:<user>:rw-; read/write open test passes)

Summary

On a machine that meets every published Cowork-on-Linux requirement (KVM virtualization enabled, >25 GB free disk, >8 GB RAM), the local Cowork VM never starts. Two user-visible consequences:

1. Cloud-mode Cowork sessions cannot link to the computer. Every cloud session shows the yellow banner "Couldn't link this session to a computer, so attached folders can't be used. If this keeps happening, let us know." The connected folder shows as attached, but the device-bridge tools (device_list_dir / device_stage_files / device_commit_files / device_bash) are absent from the session — direct calls return "No such tool available."
2. On-computer mode works for files but has no shell. "Run this task → On your computer" sessions read/write the connected folder correctly, but report "The Bash sandbox is unavailable right now. VM guest is not connected."

What I've eliminated (each tested, failure persists after every one)

• Locked keyring: gnome-keyring proven UNLOCKED via a secret-tool store/lookup round-trip in the same desktop session (also added the standard pam_gnome_keyring lines for xrdp and retested from a physical-console login)
• Stale app state: full reset — ~/.config/Claude and the user keystore archived away, fresh sign-in
• Stale device registration: removed all Linux device entries from claude.ai connected devices, signed in fresh to re-register
• Session/OS state: desktop session recreation AND a full reboot
• KVM access: VT-x live; /dev/kvm present and openable by the app's user (see Environment)
• Launch environment: reproduces on a completely plain desktop launch

Questions

1. Is the local Cowork VM — and with it, cloud-session→computer linking with connected folders — expected to work on the Linux x64 beta, or is it currently feature-gated off? If gated: is the persistent banner the intended UX, and is there a timeline?
2. What does the virtualization-support check require beyond VT-x plus an accessible /dev/kvm? The flag sits at "Checking virtualization support…" / unsupportedCode: unknown indefinitely.
3. Is [device-registry] enclave key unavailable — refusing to resolve row-PK expected on Linux (no hardware enclave), or a separate defect from the VM gate?

Possibly related

#54378 (Windows: "Desktop appears offline" despite verified bridge and virtualization) · #49181 (Filesystem connector not available in Cowork sessions) · #36365 (Windows: "Virtual Machine not available") · #26282 (sandbox dependency check fails inside VM)

Full logs available on request — happy to run any diagnostic build or verbose flag you need; this machine is available for repro.

What Should Happen?

With virtualization requirements met (VT-x enabled, /dev/kvm present and openable by the app's user, >25 GB free disk, >8 GB RAM), the local Cowork VM should start — startVM should proceed instead of reporting "VM not supported (linux/x64), skipping", and the rootfs.img bundle should download rather than being cleaned up as unsupported.

Downstream of that: cloud-mode Cowork sessions should link to this computer (no "Couldn't link this session to a computer" banner) and expose the device-bridge tools for the connected folder, and on-computer sessions should have a working Bash sandbox ("VM guest is not connected" should not occur).

If the local VM is intentionally feature-gated off on the Linux x64 beta, the expected behavior is an explicit "not yet available on Linux" message instead of a persistent link-failure banner that reads as an error.

Error Messages/Logs

## Log signatures

`~/.config/Claude/logs/cowork_vm_node.log` — identical on every app launch:


[info] [VM] Module loaded successfully
[info] [Bundle:status] rootfs.img missing
[info] [linux-vm] Spawning helper: /usr/lib/claude-desktop/resources/cowork-linux-helper
[info] [linux-vm-helper] ... starting (socket=/run/user/1000/claude-cowork-vm.sock)
[info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
[warn] [startVM] VM not supported (linux/x64), skipping


`~/.config/Claude/logs/main.log` — the transport authenticates, then the device registry refuses:


[info] [remote-tools-device] connecting DO bridge with: get_device_info, device_list_dir, device_stage_files, device_commit_files, ... device_bash, ...
[info] [remote-tools-device] connecting wss://bridge.claudeusercontent.com/devices/<id>/qm-linux-cage/bridge
[info] [remote-tools-device] authenticated
[info] [buddy] bridge started
[warn] [device-registry] enclave key unavailable — refusing to resolve row-PK   (repeats)


Desktop feature flags (renderer args) show `yukonSilver: unsupported — "Checking virtualization support…" (unsupportedCode: unknown)` — the virtualization check appears never to resolve.

Steps to Reproduce

1. Install Claude Desktop 1.18286.2 (official Linux beta) on Ubuntu 24.04.4 LTS x86_64 with virtualization requirements met (VT-x enabled, /dev/kvm present and openable by the app's user, >25 GB free disk, >8 GB RAM).
2. Launch the app from the desktop session and sign in.
3. Observe ~/.config/Claude/logs/cowork_vm_node.log on any launch: "[Bundle:status] rootfs.img missing" → "[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported)" → "[warn] [startVM] VM not supported (linux/x64), skipping".
4. Start a Cowork task in cloud mode and connect a local folder.
5. Observe the banner "Couldn't link this session to a computer, so attached folders can't be used" — the folder shows as connected, but device-bridge tools (device_list_dir / device_stage_files / device_commit_files / device_bash) are absent from the session; direct calls return "No such tool available". main.log shows "[remote-tools-device] authenticated" followed by repeating "[device-registry] enclave key unavailable — refusing to resolve row-PK".
6. Start a Cowork task with "Run this task → On your computer" on the same folder: file tools work, but the session reports "The Bash sandbox is unavailable right now. VM guest is not connected."

Reproduces on every launch. Persists after: keyring proven unlocked (secret-tool round-trip), full app-state reset, device deregistration + fresh re-registration, session recreation, and full reboot.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

None on Linux (feature never worked on this install).

Claude Code Version

Claude Desktop 1.18286.2 (official Linux beta). CLI not the subject of this report.

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_