[BUG] yukonSilver marked unsupported on official Linux Cowork build despite KVM and vsock both confirmed working

[MaxStrey]

Preflight Checklist

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

What's Wrong?

When launching Cowork on the official Linux build of Claude Desktop, the app's internal platform classifier (yukonSilver) reports status=unsupported on every launch, which prevents the VM bundle from ever downloading. Cowork shows a "Virtualization isn't fully set up" dialog directing the user to add themselves to the kvm group.

This is misleading: the actual KVM and vsock prerequisites are independently confirmed working on this system (see verification steps below), yet the yukonSilver check still blocks initialization. The cowork_vm_node.log shows the same "not supported" classification on every launch with no VM boot attempt ever made, matching the pattern reported extensively for Windows builds in issues #25136, #27316, #27420, #29887, #32004, #37016, #43282, #45140, #47327, #48995, and #57717 — all of which conclude this is an app-side platform-detection bug rather than a real system limitation. This appears to be the same bug surfacing on the newly-released Linux build (Linux support shipped 2026-06-30).

What Should Happen?

Cowork should detect that KVM acceleration and vhost_vsock are both available and correctly permissioned, download the VM bundle, and successfully initialize the Cowork workspace — consistent with how yukonSilver is presumably intended to behave when all real prerequisites are met.

Error Messages/Logs

From ~/.config/Claude/logs/cowork_vm_node.log (repeats on every launch, no VM boot ever attempted):

2026-07-02 15:06:04 [info] [VM] Loading vmClient (TypeScript) module...
2026-07-02 15:06:04 [info] [VM] Module loaded successfully
2026-07-02 15:06:04 [info] [linux-vm] Spawning helper: /usr/lib/claude-desktop/resources/cowork-linux-helper
2026-07-02 15:06:04 [info] [linux-vm-helper] [cowork-linux-helper] 2026/07/02 15:06:04.830228 starting (pid=43960, socket=/run/user/1000/claude-cowork-vm.sock)
[cowork-linux-helper] 2026/07/02 15:06:04.830451 [server] listening on /run/user/1000/claude-cowork-vm.sock
2026-07-02 15:06:04 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...

--- System verification performed to rule out real prerequisite issues ---

$ groups $USER
max : max adm cdrom sudo dip plugdev users kvm lpadmin

$ ls -l /dev/kvm
crw-rw----+ 1 root kvm 10, 232 Jul  1 08:33 /dev/kvm

$ sudo -u $USER test -r /dev/kvm -a -w /dev/kvm && echo "ACCESS OK"
ACCESS OK

$ kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

$ lsmod | grep vsock
(initially empty — root cause of the original issue was that vhost_vsock was not loaded)

$ sudo modprobe vhost_vsock
$ ls -l /dev/vhost-vsock
crw-rw---- 1 root kvm 10, 241 Jul  2 14:52 /dev/vhost-vsock

After loading vhost_vsock and confirming both device permissions, the yukonSilver check still returns unsupported on every subsequent app restart. No vm_bundle or .img files were found anywhere under ~/.local/share/claude-desktop or ~/.config/Claude, indicating the VM bundle download is never even attempted.

Steps to Reproduce

1. Install Claude Desktop via the official apt repo (downloads.claude.ai/claude-desktop) on Ubuntu 24.04.4 LTS
2. Ensure user is in the kvm group and /dev/kvm is accessible (verified via kvm-ok)
3. Ensure vhost_vsock kernel module is loaded and /dev/vhost-vsock exists with correct permissions
4. Open Claude Desktop and attempt to start a Cowork task
5. Observe: "Virtualization isn't fully set up" dialog appears, directing user to join the kvm group (already satisfied)
6. Check ~/.config/Claude/logs/cowork_vm_node.log — shows yukonSilver not supported (status=unsupported) on every launch, VM bundle never downloads

Claude Model

None

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

1.17377.2 desktop app linux

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[MarshallOfSound]

For desktop environments after adding your user to the kvm group you need to log out and log back in again in order to refresh that group access. On some distros you may even need to restart your machine

[MiguelMontillaLesmes]

Confirming the same behavior on a different distro — Zorin OS 17.3 (based on Ubuntu 22.04 LTS "jammy"), Claude Desktop 1.18286.0, installed via the official apt repository.

Both real prerequisites are confirmed present and accessible:

$ egrep -c '(vmx|svm)' /proc/cpuinfo
16

$ id
uid=1000(miguelml) gid=1000(miguelml) groups=1000(miguelml),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),109(kvm),125(lpadmin),137(sambashare),141(libvirt)

$ ls -l /dev/kvm
crw-rw----+ 1 root kvm 10, 232 ... /dev/kvm

$ ls -l /dev/vhost-vsock
crw-rw---- 1 root kvm 10, 241 ... /dev/vhost-vsock

$ test -r /dev/vhost-vsock -a -w /dev/vhost-vsock && echo "ACCESS OK"
ACCESS OK

QEMU, OVMF, and virtiofsd are also installed and functional:

$ qemu-system-x86_64 --version
QEMU emulator version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.31)

(Note: on jammy, virtiofsd is not a standalone apt package — it ships bundled inside qemu-system-common at /usr/lib/qemu/virtiofsd. Symlinking it to /usr/local/bin/virtiofsd for PATH visibility did not change the outcome.)

Despite all of the above, cowork_vm_node.log shows the same result on every launch:

[info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...

No VM bundle download is ever attempted, and the app repeatedly prompts to install packages (qemu-system-x86 ovmf virtiofsd) that are already installed and up to date.

One additional data point that might be relevant to the platform-detection logic: running virtiofsd --version directly as a normal (non-root) user on jammy returns:

setgroups() failed with error=1:Operation not permitted

This happens even for a simple --version call. If the yukonSilver compatibility probe shells out to virtiofsd to test availability and interprets this failure as "unsupported," that could be a contributing factor — worth checking whether this differs across distros/virtiofsd versions.

Also performed a full system reboot (not just logout/login) after adding the user to the kvm group, per @MarshallOfSound's suggestion above — confirmed via id that the kvm group is active in the session — and the issue persists.

Happy to run further diagnostics if useful.

[gitTy600]

Same issue here, on the official Anthropic apt install (not the community fork).

Environment:

• OS: Linux Mint (Ubuntu Noble base)
• Claude Desktop: 1.18286.0 (official downloads.claude.ai/claude-desktop/apt/stable)
• CPU: Intel Core i5-3470 (Ivy Bridge, 2012)

All documented prerequisites confirmed working:

• /dev/kvm exists, user in kvm group, kvm-ok passes
• CPU virtualization flags present, not running nested (systemd-detect-virt: none)
• QEMU 8.2.2, OVMF, virtiofsd all installed
• /dev/vhost-vsock exists (module loaded)
• Network reachable, apt repo syncs fine
• Already on latest version

Same exact log signature:
[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...

cowork-linux-helper spawns and listens on socket successfully, but no QEMU process ever starts and no VM image is ever downloaded. main.log shows [WarmLifecycle:cowork] Initialized immediately followed by Destroyed, with zero error output in between.

Given this matches your findings plus the linked Windows reports, it does look like an app-side bug in the yukonSilver platform detection rather than a real missing dependency. Happy to share full log files if useful for debugging.

[Vanar-Bharat]

Same issue, third confirmation on a different distro/kernel:

• OS: Ubuntu 26.04 LTS (resolute), kernel 7.0.0-27-generic
• Claude Desktop: official apt install
• systemd-detect-virt: none (bare metal, not nested)
• /dev/kvm present, root:kvm, mode 660; user in kvm group
• vhost_vsock module loaded, /dev/vhost-vsock present
• virtiofsd installed (/usr/libexec/virtiofsd)
• QEMU, socat present
• OVMF installed (/usr/share/OVMF/OVMF_CODE_4M.fd)
• 380GB disk free, 14GB RAM
• No vm_bundles or .img files anywhere under ~/.config/Claude or ~/.local/share

cowork_vm_node.log shows only:
[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...

on every launch since install — helper spawns and listens on socket, no QEMU process ever starts, no download attempted. All host-side prerequisites confirmed green; this looks like the classifier gate itself, not a real dependency gap.

[cope413]

Same issue, though I get

Bundle:status rootfs.img missing right after the yukonSilver not supported, checking for stale bundle.

Ubuntu 26.04 LTS, 7.0.0-27-generic

[yevhen-chernenko]

Confirming this on a second machine — same signature, still unresolved.
Environment: Ubuntu, Claude Desktop (official apt repo).
Distributor ID: Ubuntu
Description: Ubuntu 24.04.4 LTS
Release: 24.04
Codename: noble

Verification performed:

$ kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

$ ls -la /dev/kvm
crw-rw----+ 1 root kvm 10, 232 Jul 12 17:31 /dev/kvm

$ groups $USER
yevhen-chernenko : yevhen-chernenko adm cdrom sudo dip plugdev users kvm lpadmin docker

$ ls /usr/libexec/virtiofsd
/usr/libexec/virtiofsd (present, expected path)

$ lsmod | grep vsock
vhost_vsock, vmw_vsock_virtio_transport_common, vhost, vsock (all loaded)

$ ls -la /dev/vhost-vsock
crw-rw---- 1 root kvm 10, 241 Jul 12 18:34 /dev/vhost-vsock

Also checked for a stale cached result in ~/.config/Claude/config.json — lastSeenRequireCoworkFullVmSandbox is null, not a cached failure, so this isn't a caching issue either. cowork_vm_node.log shows yukonSilver not supported (status=unsupported) on every launch since first install, no VM boot ever attempted.
Everything the docs ask for is in place and correctly permissioned. Would be great to get a fix or at least more granular logging on what yukonSilver is actually checking, since right now there's no way to tell which specific check is failing.

[BlueJacket7]

Same classifier-gate signature on Ubuntu Server 24.04.4 LTS x86_64 — Claude Desktop 1.18286.2, official apt repo — tracked with full logs in #77348. Two data points that may help narrow which check yukonSilver is failing:

1. Elimination trail already run on this machine: clean reboot; account-side device deregistration and fresh re-registration; full app-state reset (config + keystore archived, fresh sign-in). The [startVM] VM not supported (linux/x64), skipping + rootfs.img missing pairing persists through all of it. VT-x live per lscpu, /dev/kvm present and permissioned, 77 GB free, 32 GB RAM.

2. A second, possibly distinct layer that no comment here shows: [device-registry] enclave key unavailable — refusing to resolve row-PK repeating while transport authenticates. Net effect: cloud sessions cannot link to the machine, while on-computer sessions get working file tools but no shell ("The Bash sandbox is unavailable right now. VM guest is not connected.").

Happy to run further diagnostics — full environment and logs in #77348.

[Rollis76]

Same issue on 1.22209.3 (latest as of 20 Jul 2026), Ubuntu 26.04 LTS, i9-11900. kvm group ✓, /dev/kvm accessible ✓, vhost_vsock loaded with /dev/vhost-vsock present ✓, virtiofsd at /usr/bin ✓. Clean reinstall with ~/.config/Claude wiped made no difference. Log shows yukonSilver not supported (status=unsupported) on every launch, no VM boot attempted.

[GianPierree]

Hello, I use Ubuntu and I get the following log:

cat ~/.config/Claude/logs/cowork_vm_node.log 2026-07-18 21:54:08 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle... 2026-07-18 22:07:49 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle... 2026-07-18 22:08:08 [info] [VM] Loading vmClient (TypeScript) module... 2026-07-18 22:08:08 [info] [VM] Module loaded successfully 2026-07-18 22:08:10 [info] [linux-vm] Spawning helper: /usr/lib/claude-desktop/resources/cowork-linux-helper 2026-07-18 22:08:10 [info] [linux-vm-helper] [cowork-linux-helper] 2026/07/18 22:08:10.163540 starting (pid=119192, socket=/run/user/1000/claude-cowork-vm.sock) [cowork-linux-helper] 2026/07/18 22:08:10.163759 [server] listening on /run/user/1000/claude-cowork-vm.sock 2026-07-19 20:22:28 [info] [VM] Loading vmClient (TypeScript) module... 2026-07-19 20:22:28 [info] [VM] Module loaded successfully 2026-07-19 20:22:28 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle... 2026-07-19 20:22:28 [info] [linux-vm] Spawning helper: /usr/lib/claude-desktop/resources/cowork-linux-helper 2026-07-19 20:22:28 [info] [linux-vm-helper] [cowork-linux-helper] 2026/07/19 20:22:28.568155 starting (pid=40280, socket=/run/user/1000/claude-cowork-vm.sock) [cowork-linux-helper] 2026/07/19 20:22:28.568366 [server] listening on /run/user/1000/claude-cowork-vm.sock 2026-07-19 21:25:42 [info] [VM] Loading vmClient (TypeScript) module... 2026-07-19 21:25:42 [info] [VM] Module loaded successfully 2026-07-19 21:25:42 [info] [linux-vm] Spawning helper: /usr/lib/claude-desktop/resources/cowork-linux-helper 2026-07-19 21:25:42 [info] [linux-vm-helper] [cowork-linux-helper] 2026/07/19 21:25:42.194326 starting (pid=48739, socket=/run/user/1000/claude-cowork-vm.sock) [cowork-linux-helper] 2026/07/19 21:25:42.194662 [server] listening on /run/user/1000/claude-cowork-vm.sock 2026-07-19 21:25:42 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle... 2026-07-19 21:37:07 [info] [VM] Loading vmClient (TypeScript) module... 2026-07-19 21:37:07 [info] [VM] Module loaded successfully 2026-07-19 21:37:07 [info] [linux-vm] Spawning helper: /usr/lib/claude-desktop/resources/cowork-linux-helper 2026-07-19 21:37:07 [info] [linux-vm-helper] [cowork-linux-helper] 2026/07/19 21:37:07.751538 starting (pid=50870, socket=/run/user/1000/claude-cowork-vm.sock) [cowork-linux-helper] 2026/07/19 21:37:07.751739 [server] listening on /run/user/1000/claude-cowork-vm.sock 2026-07-19 21:37:07 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle... 2026-07-19 22:36:45 [info] [VM] Loading vmClient (TypeScript) module... 2026-07-19 22:36:45 [info] [VM] Module loaded successfully 2026-07-19 22:36:45 [info] [linux-vm] Spawning helper: /usr/lib/claude-desktop/resources/cowork-linux-helper 2026-07-19 22:36:45 [info] [linux-vm-helper] [cowork-linux-helper] 2026/07/19 22:36:45.740709 starting (pid=55914, socket=/run/user/1000/claude-cowork-vm.sock) [cowork-linux-helper] 2026/07/19 22:36:45.740982 [server] listening on /run/user/1000/claude-cowork-vm.sock 2026-07-19 22:36:46 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...

Confirm that kvm in groups + explicit ACL in /dev/kvm.

[shempman828]

Same bug on Ubuntu 25.10, Claude Desktop 1.24012.0 (AMD, apt install).

• KVM: confirmed working (kvm-ok passes, /dev/kvm accessible, in kvm group)
• virtiofsd: present at /usr/libexec/virtiofsd (one of the two hardcoded paths from [BUG] Claude Desktop for Linux 1.18286.0: Cowork "requires QEMU" on hosts where the full KVM stack is installed — virtiofsd probe checks two paths and gates the bundled fallback to Ubuntu 22 only #74605)
• vhost_vsock: was not loaded, loaded it manually, /dev/vhost-vsock now exists with correct perms

Despite all of the above, yukonSilver still reports unsupported on every launch and no VM bundle download is ever attempted:

2026-07-24 08:49:49 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...