[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

Status Open

Maintainer reply None cached

Activity 6 comments · opened Jul 5, 2026

What's Wrong?

I maintain claude-desktop-debian, which repackages the official Linux .deb into RPM/AppImage/Nix/AUR formats. Two of our users hit the same Cowork failure on machines with a complete, healthy KVM stack, so I read the bundle to find the cause.

Cowork's support evaluator resolves virtiofsd from exactly two absolute paths: /usr/libexec/virtiofsd, then /usr/bin/virtiofsd. It checks each with fs.access for read access. There's no PATH search. When neither resolves, it falls back to the bundled copy at process.resourcesPath/virtiofsd only when /etc/os-release reports ID=ubuntu and VERSION_ID starting with 22.. On anything else, virtiofsdPath stays null.

With a null virtiofsdPath, the evaluator (feature key yukonSilver) returns unsupported / virtualization_tools_missing and the UI shows: "Cowork requires QEMU. Install it with 'sudo apt install qemu-system-x86 ovmf virtiofsd', then restart Claude." That message fires even when qemu, ovmf, and virtiofsd are all installed and working. The install command just puts the binary back where the probe already isn't looking.

The distros this breaks on, all with working KVM:

Arch / CachyOS ship virtiofsd at /usr/lib/virtiofsd. Not probed. (our #771)
Debian Bookworm ships it at /usr/lib/qemu/virtiofsd (Rust 1.13.2). Not probed. (our #772)
Pop!_OS 22.04 reports ID=pop, so a jammy base never qualifies for the bundled fallback. This one reproduced on Anthropic's own official .deb from your apt repo, so it isn't a repackaging artifact on our end.

The Linux VM bundle isn't the problem. The static manifest includes unix/x64 and unix/arm64 rootfs entries with checksums, and every install ships a working bundled virtiofsd (v1.13.2, ~2.6 MB) at resources/virtiofsd. Linux Cowork is fully built. It's gated off by the path resolution alone.

Two things compound it. The startVM path logs [startVM] VM not supported (linux/x64), skipping for any unsupported status. The platform/arch interpolation makes it read like an architecture gate when it's actually the tools gate, which sent our triage bot down the wrong path (unsupported_architecture). And cleanupVMBundleIfUnsupported deletes the downloaded VM bundle whenever status ≠ supported, so an affected user's bundle gets repeatedly cleaned out.

What Should Happen?

On a host with a working KVM stack and a virtiofsd binary present, Cowork should evaluate as supported and start the VM. The user shouldn't be told to install packages that are already installed.

Two fixes, either or both:

Drop the Ubuntu-22-only condition on the bundled fallback. You already ship the binary in every install. System paths can stay preferred; the bundled copy just becomes the universal last resort instead of a jammy-only one. This is the smaller, safer change.
Widen the probe list to include /usr/lib/virtiofsd and /usr/lib/qemu/virtiofsd. One caveat: /usr/lib/qemu/virtiofsd on qemu < 8 hosts (e.g. Ubuntu 22.04 jammy) can be the legacy C implementation, whose CLI is incompatible with the Rust one. That's presumably why the current list is conservative. Un-gating the bundled copy avoids that trap entirely, which is why I'd lean on (1).

Error Messages/Logs

UI prompt:

Cowork requires QEMU. Install it with 'sudo apt install qemu-system-x86 ovmf virtiofsd', then restart Claude.

Misleading main-process log line (reads like an arch gate; it's the tools gate):

[startVM] VM not supported (linux/x64), skipping

The gate reason lands in ~/.config/Claude/logs/cowork_vm_node.log. Grep there for virtualization_tools_missing.

Steps to Reproduce

Linux host with a working KVM stack: qemu-system-x86_64, OVMF, and virtiofsd all installed and functional.
Install virtiofsd anywhere other than /usr/libexec/virtiofsd or /usr/bin/virtiofsd (Arch → /usr/lib/virtiofsd, Debian → /usr/lib/qemu/virtiofsd), or run on a non-Ubuntu / non-22.x distro so the bundled fallback is gated off.
Launch Claude Desktop and open Cowork.

Expected: Cowork starts. Actual: "Cowork requires QEMU" prompt for packages that are already installed.

Confirming workaround (proves it's the probe): sudo ln -s <actual virtiofsd path> /usr/bin/virtiofsd, then fully quit Claude (not just close the window) and relaunch. The probe runs once at module load and is memoized, so a restart is required. The client only needs read access to the binary.

I also verified the mechanism differentially on an Arch VM (virtiofsd only at /usr/lib/virtiofsd, otherwise a complete KVM stack — qemu on PATH, OVMF at the probed path, /dev/kvm and /dev/vhost-vsock present): 1.18286.0 as shipped logs [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported) and deletes the VM bundle on every launch; the same build with only the bundled fallback un-gated evaluates as supported on the same machine and proceeds to bundle management ([Bundle:status] rootfs.img missing). The gate is the resolver, nothing else.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A — this is a Claude Desktop issue. Bundle version: 1.18286.0

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Anchor table for 1.18286.0. Minified symbols rename between releases, so each row carries a stable string anchor. All line numbers are against the beautified bundle (asar extract + prettier on the official Linux .deb).

| Role | Symbol in 1.18286.0 | Stable anchor | Beautified loc |
|---|---|---|---|
| Probe path array | sgi | ["/usr/libexec/virtiofsd", "/usr/bin/virtiofsd"] | index.js:156891 |
| Ubuntu-22 gate | agi() | id === "ubuntu" && versionId.startsWith("22.") | index.js:156892 |
| Resolver | cgi(A) | TMt(sgi) \|\| (A ? bundled : null) | index.js:156906 |
| Memoized probe | Igi() / N2e | probe runs once at module load | index.js:156963 |
| Tools gate | Cen() | !e.qemuPath \|\| !e.firmwarePath \|\| !e.virtiofsdPath → virtualization_tools_missing | index.js:281909 |
| Misleading log | startVM | VM not supported (linux/x64), skipping | index.js:283787 |
| Bundle cleanup | cleanupVMBundleIfUnsupported | deletes VM bundle when status ≠ supported | index.js:499016 |

The probe resolves to TMt(sgi) (first readable of the two system paths) OR — only when agi() is true — the bundled copy. Un-gate that second operand and every install with the shipped binary resolves.

Full downstream provenance: aaddrick/claude-desktop-debian#771 and #772. The Pop!_OS datapoint on the official .deb came from @mj-crabtree in the #771 thread.

One question where a one-line answer would help us route this downstream: is the Ubuntu-22-only gate on the bundled fallback deliberate (e.g. you only validated the bundled binary against a jammy glibc), or is it a leftover from an early Ubuntu-first rollout? If it's deliberate, we'll keep our downstream patch conservative.

---
Written by Claude Fable 5 via Claude Code

View original on GitHub ↗

6 Comments

anupamguleria · 1 month ago

Adding a data point that rules out hardware-side hypotheses and adds a distro-detection angle.

Environment: KDE Neon (Ubuntu 24.04 LTS base, Plasma 6.7, X11), running as a VMware Workstation guest on a Windows 11 host. Official claude-desktop package v1.18286.0, not claude-desktop-unofficial. /etc/os-release: ID=neon, ID_LIKE="ubuntu debian", VERSION_ID=24.04.

All locally-verifiable prerequisites present and correct:

virtiofsd at /usr/libexec/virtiofsd (first probe path per this issue), -rwxr-xr-x root:root
qemu-system-x86_64 at /usr/bin/qemu-system-x86_64
OVMF present as /usr/share/OVMF/OVMF_CODE_4M.fd (Ubuntu 24.04 4M naming); tested with a compat symlink to the unsuffixed name, no change in outcome
Intel VT-x and VT-d confirmed Enabled in UEFI firmware directly
Windows host VBS interference ruled out after full remediation and recheck

Log:

2026-07-06 18:51:54 [info] [VM] Loading vmClient (TypeScript) module...
2026-07-06 18:51:54 [info] [VM] Module loaded successfully
2026-07-06 18:51:55 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
2026-07-06 18:51:55 [info] [linux-vm] Spawning helper: /usr/lib/claude-desktop/resources/cowork-linux-helper
yukonSilver fires immediately after module load with no preceding qemu/virtiofsd/firmware probe lines. This is a launch-time trace, not a Cowork-tab-click trace, so the ordering is suggestive rather than call-stack-verified

Two observations for triage:

This log line is identical to the long-running Windows yukonSilver reports (#25136, #27406, #28238, #32004, #47327, #50961), including regressions on previously-working machines with no local changes. Whatever the evaluator keys on, it misfires across platforms, so this may be the same underlying bug surfacing on the Linux beta rather than a Linux-specific one.

Since the bundled-fallback gate documented in this issue checks ID=ubuntu + VERSION_ID starting with 22. exactly: KDE Neon reports ID=neon with ID_LIKE="ubuntu debian", so any exact-match distro check fails here despite a fully Ubuntu 24.04 system underneath. If yukonSilver or related gates do exact ID matching rather than consulting ID_LIKE, every Ubuntu derivative (Neon, Mint, Pop!_OS, Zorin) fails detection regardless of actual capability. Note @mj-crabtree reproduced this on Pop!_OS in aaddrick/claude-desktop-debian#771, which is consistent with this hypothesis. Easy to confirm or eliminate with access to the evaluator source.

Happy to pull any diagnostic output that would help narrow this down.

***

Generated through Claude Fable 5

mazelado · 1 month ago

Confirming this is still broken on 1.18286.2 even after applying the virtiofsd symlink workaround exactly as described above — plus an additional fix (OVMF filenames) not mentioned in the original report. Posting in case the extra data point helps narrow this down, since my case seems to contradict the "symlink alone fixes it" conclusion from the differential Arch VM test.

Environment

Claude Desktop: 1.18286.2 (official .deb/apt install, not a repackaged build)
Distro: Arch Linux (rolling)
virtiofsd: 1.14.0-1 (pacman), installed at /usr/lib/virtiofsd
qemu-system-x86: 11.0.2-3
edk2-ovmf: 202605-1
/dev/kvm: present, crw-rw-rw- (world-accessible)
/dev/vhost-vsock: present

What I did, in order

Confirmed virtiofsd was only at /usr/lib/virtiofsd, not the two hardcoded probe paths.
Symlinked it: sudo ln -s /usr/lib/virtiofsd /usr/bin/virtiofsd
Fully quit Claude Desktop (verified via pgrep -af claude, no stray processes), relaunched. Still yukonSilver unsupported.
Noticed Arch's edk2-ovmf ships OVMF_CODE.4m.fd / OVMF_VARS.4m.fd, not the OVMF_CODE.fd / OVMF_VARS.fd filenames the probe appears to expect. Symlinked those too:

``sudo ln -s /usr/share/edk2/x64/OVMF_CODE.4m.fd /usr/share/edk2/x64/OVMF_CODE.fd sudo ln -s /usr/share/edk2/x64/OVMF_VARS.4m.fd /usr/share/edk2/x64/OVMF_VARS.fd``

Fully quit and relaunched again. Still yukonSilver unsupported, across multiple subsequent relaunches over ~15 minutes.

Evidence the fix was actually in place at launch time

$ ls -al /usr/bin/virtiofsd
lrwxrwxrwx root root 18 B ... /usr/bin/virtiofsd ⇒ /usr/lib/virtiofsd

cowork_vm_node.log, well after both symlinks existed:

2026-07-09 21:34:40 [info] [linux-vm] Spawning helper: /tmp/.mount_claudeEp4fcy/.../cowork-linux-helper
2026-07-09 21:34:40 [info] [linux-vm-helper] [cowork-linux-helper] ... starting (pid=148606, socket=/run/user/1000/claude-cowork-vm.sock)
2026-07-09 21:34:40 [info] [linux-vm-helper] [cowork-linux-helper] ... [server] listening on /run/user/1000/claude-cowork-vm.sock
2026-07-09 21:34:42 [info] [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...

So the helper process itself starts and binds its socket without any error — the failure is entirely in the app's own yukonSilver evaluator, which never logs a reason.

Ruled out separately

Running cowork-linux-helper manually/standalone against a test socket: starts and listens with zero errors.
/dev/kvm and /dev/vhost-vsock both present and accessible.
No stale Electron/helper processes surviving between launches (checked via pgrep -af claude each time).

Possibly relevant: the live desktop-features payload shows yukonSilver stuck with "reason":"Checking virtualization support…" rather than resolving to either supported or a concrete failure reason:

"yukonSilver":{"status":"unsupported","reason":"Checking virtualization support…","unsupportedCode":"unknown"}

That "Checking..." placeholder never resolving might indicate the probe is timing out or throwing partway through rather than cleanly evaluating false on a specific check — which would explain why fixing the two known path issues (virtiofsd, OVMF) doesn't flip the result the way it did in the original differential test.

Happy to grab any additional logs/output if it'd help narrow this down further.

crazykodi · 1 month ago

Adding a data point on Linux Mint (Ubuntu-based, non-22.04 base) that matches this issue exactly.
Verified working, in this order:

/dev/kvm exists with correct group ownership: crw-rw----+ 1 root kvm 10, 232
kvm-ok confirms: "KVM acceleration can be used"
User confirmed in kvm group
virtiofsd installed via apt (1.10.0-1), actual binary at /usr/libexec/virtiofsd, symlinked to /usr/bin/virtiofsd
qemu-system-x86_64 present at /usr/bin/qemu-system-x86_64
OVMF firmware present only under the newer _4M naming (OVMF_CODE_4M.fd, OVMF_VARS_4M.fd); symlinked to legacy names (OVMF_CODE.fd, OVMF_VARS.fd) as a workaround attempt

Result: Still status=unsupported after a full Claude Desktop restart (confirmed via new PID in the helper log) with all of the above in place.

Log excerpt:
[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
[warn] [startVM] VM not supported (linux/x64), skipping
This suggests the path/version-detection issue described here isn't limited to the specific distros already mentioned — it affects Mint too, and persists even when every documented prerequisite (KVM, virtiofsd, QEMU, OVMF) is manually satisfied and symlinked to expected paths.

Wekins73 · 1 month ago

Adding a data point for Zorin OS, another Ubuntu derivative hitting this.
System: Zorin OS 17.3, Ubuntu 22.04/jammy base, Claude Desktop Linux beta
/etc/os-release:
PRETTY_NAME="Zorin OS 17.3"
NAME="Zorin OS"
VERSION_ID="17"
VERSION="17.3"
VERSION_CODENAME=jammy
ID=zorin
ID_LIKE="ubuntu debian"
UBUNTU_CODENAME=jammy
Confirmed all required components installed and correctly located per this thread:

qemu-system-x86, ovmf — installed via apt
virtiofsd — present at /usr/lib/qemu/virtiofsd, symlinked to /usr/bin/virtiofsd

Still get the "Cowork requires QEMU" gate. Support (Fin) confirmed this is the distro-ID check not honoring ID_LIKE or codename fields for Ubuntu derivatives — same root cause as the Pop!_OS and Arch/CachyOS reports already here (#771, #772).
Given ID_LIKE="ubuntu debian" and UBUNTU_CODENAME=jammy are both present and correctly identify this as a supported base, checking those fields (not just ID) would fix Zorin, Pop!_OS, Mint, and similar derivatives in one pass.

westes · 1 month ago

Slightly different flavor of this bug, but likely related: my Cowork VM had been working fine for months (logs show successful VM already connected sessions going back to April 2026) and broke specifically after a Claude Desktop update on 2026-07-08. The exact log line:

2026-07-08 20:47:16 [warn] [startVM] VM not supported (linux/x64), skipping

No further connection attempts logged after that point — Cowork tab disappeared from the UI entirely.

System: Ubuntu 22.04, Claude Desktop 1.22209.3, installed via the official apt repo (downloads.claude.ai). qemu-system-x86 and ovmf are installed via apt (versions 1:6.2+dfsg-2ubuntu6.31 and 2022.02-3ubuntu0.22.04.6 respectively); no standalone virtiofsd package (not available for jammy — it doesn't show up separately until 24.04/noble).

If this is the same path-resolution gate described above, it'd be useful to know whether the regression is from a change in how the update detects the bundled resources/virtiofsd, since this was working before that specific update.

thoratleedvardsen-coder · 1 month ago

Confirming this also affects Ubuntu 24.04.4 LTS (Noble), not just the Ubuntu-22-gated cases discussed above.

Environment:

Ubuntu 24.04.4 LTS, kernel via ThinkPad T490s
virtiofsd 1.10.0-1 installed via apt (dpkg -l | grep virtiofsd confirms package present)
Bundled Claude copy present at /usr/lib/claude-desktop/resources/virtiofsd
KVM group membership and /dev/kvm permissions confirmed correct (root:kvm, 660, user in kvm group)
which virtiofsd returned nothing — not on PATH, despite the package being installed

Symptom matched this thread exactly: cowork_vm_node.log repeatedly showed [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported) on every launch, with KVM/vsock independently verified working.

Workaround that resolved it: symlinking the bundled binary to where the probe apparently expects it —

sudo ln -s /usr/lib/claude-desktop/resources/virtiofsd /usr/bin/virtiofsd

followed by a full process kill (pkill -f claude-desktop, confirmed via ps aux) and relaunch — window close alone did not retrigger the probe, consistent with it being memoized at module load as noted above.

Given this is hitting 24.04 as well, the path-resolution gate seems broader than just an Ubuntu-22-specific issue — it looks like it's failing for any system where virtiofsd isn't symlinked onto PATH by default, regardless of Ubuntu version.