# Claude Cowork on Linux needs KVM; the open source route does not > Claude Cowork boots a virtual machine on your own computer, so the errors it reports on Linux describe the host. Each message belongs to one check, and some hosts have no local fix at all. Kortix, the open-source AI Operating System, gives every agent session its own cloud computer, so the machine is not yours to configure. URL: https://claudedesktoplinux.com/cowork-linux-kvm ## Anthropic's Cowork requirements, in the order its page lists them `Cowork requirements` ``` On Linux, Cowork runs those tasks in a virtual machine that the desktop app hosts with QEMU and KVM. Without it, Cowork reports “Cowork requires hardware virtualization (KVM)”. Cowork reports “Cowork requires QEMU” and shows the apt install command to run. Access to /dev/kvm: add your user to the kvm group with sudo usermod -aG kvm $USER, then log out and back in. Some desktop environments grant the logged-in user access to /dev/kvm without the group, but Cowork also needs /dev/vhost-vsock, which only kvm group members can open. The app checks these requirements once at launch: restart it after installing packages, and log out and back in after joining the group. ``` Source: https://code.claude.com/docs/en/desktop-linux Quoted from Anthropic's Linux page, checked October 2026. ## What Cowork runs on Linux Claude Cowork is the part of the desktop app for Dispatch and longer agentic work, and on Linux it runs those tasks in a virtual machine. That is why the errors it reports describe the host. Anthropic's page puts it plainly: "On Linux, Cowork runs those tasks in a virtual machine that the desktop app hosts with QEMU and KVM" ([Anthropic's Linux page](https://code.claude.com/docs/en/desktop-linux)). QEMU builds the machine. KVM is the kernel interface that lets the guest use the processor's virtualization instructions. virtiofsd gives the guest a path to the files the task works on. One fact explains every message the app can show. A host has to allow a virtual machine to exist, and Linux allows it when firmware, kernel and account agree. The app runs the checks once, at launch. It does not revisit them until you restart it, so a correct fix looks like it did nothing until the app comes back up. ## The five checks it runs at launch Five conditions decide whether the guest starts. Four of them describe the machine, and no repackaging project can change a device the kernel never exposes. 1. Hardware virtualization, switched on in firmware. 2. `qemu-system-x86`, `ovmf` and `virtiofsd` installed, or `qemu-system-arm`, `qemu-efi-aarch64` and `virtiofsd` on arm64. 3. Access to `/dev/kvm`. 4. Access to `/dev/vhost-vsock`, which only members of the `kvm` group can open. 5. A module directory under `/lib/modules` for the running kernel. Only the second is a package question in the ordinary sense. The install pulls those packages as recommended dependencies. A standard Ubuntu or Debian install passes check two without anyone choosing it. A minimal image, a container build, or an install with `--no-install-recommends` skips those packages. The gap then shows up as the QEMU message on a machine whose CPU and kernel are fine. ## Error by error, and the fix where one exists ### Cowork requires hardware virtualization (KVM) The firmware check failed. `grep -cE 'vmx|svm' /proc/cpuinfo` is the fast read: a count above zero means the processor offers virtualization to the kernel. Zero sends you to the UEFI settings. Enable Intel VT-x, AMD-V or SVM, depending on the board, then restart. Some machines have the setting and no way for you to reach it. A work laptop with a locked firmware is one. A cloud instance that does not pass virtualization to its guest is another. Nothing inside Linux turns those on. ### Cowork requires QEMU The package set is incomplete, or the app cannot find one binary inside a complete set. Install the three packages and restart the app: ```sh sudo apt install qemu-system-x86 ovmf virtiofsd ``` Ubuntu 22.04 has no `virtiofsd` package, and the app carries its own copy there. A missing package on that release is expected. On arm64 the names are `qemu-system-arm` and `qemu-efi-aarch64`. The repository setup on the Debian family, and the errors apt can print while adding it, are on [the Ubuntu and Debian page](/ubuntu-debian). A full install can still report the message. The repackaging project traced it to the path the app probes: "Upstream probes only /usr/libexec/virtiofsd and /usr/bin/virtiofsd, falling back to its bundled copy only when /etc/os-release reports Ubuntu 22.x. Arch installs virtiofsd at /usr/lib/virtiofsd and Debian at /usr/lib/qemu/virtiofsd." ([project readme](https://github.com/aaddrick/claude-desktop-debian)). A complete KVM stack can therefore report the QEMU message. Pointing one of the probed paths at the real binary closes the gap on an unpatched build, and the project's own builds carry a fix for it. ### The kvm group, /dev/kvm and /dev/vhost-vsock `/dev/kvm` can open for your desktop session without the group, and Cowork still fails, because "Cowork also needs /dev/vhost-vsock, which only kvm group members can open." Join the group, log out, log back in, then restart the app: ```sh sudo usermod -aG kvm $USER ``` A terminal opened before the change keeps the group list it started with. `id -nG` in that window will still omit `kvm` after a correct command. The logout is part of the fix. ### A kernel with no module directory The app reports a kernel problem when `/dev/vhost-vsock` is missing and `/lib/modules` holds no directory for the running kernel ([Anthropic's Linux page](https://code.claude.com/docs/en/desktop-linux)). Anthropic adds that the support cannot be added by hand, and names where the case is common: "This combination is common on ChromeOS and in container-based Linux environments." The message is accurate. Kernel modules load from that directory. A kernel built without one cannot load `vhost_vsock` later, so the device never appears. No package, flag or rebuild of the app supplies it. ## Hosts where no local fix exists A Chromebook, a container image, a kernel compiled without modules, and a laptop with a locked firmware all end in the same place. The app installs, Cowork stays closed, and the error names a device the host cannot produce. A container on a machine with `/dev/kvm` can be given the device at run time. That change happens on the host that starts the container, and nothing inside the image creates it. [The ChromeOS and container page](/containers-chromeos-servers) takes those hosts one at a time. The AUR package, the .rpm, the AppImage and the Nix flake all install the same app and meet the same devices. The [home page](/) covers the distributions Anthropic supports for the app itself. ## The bubblewrap fallback, and what it costs One project ships a way around the VM requirement, and its readme says exactly what it is: "Cowork bubblewrap backend. Opt-in via `COWORK_VM_BACKEND=bwrap` for hosts without KVM/vhost-vsock. Every branch is gated on the flag, so an unflagged launch runs upstream's path unchanged." ([project readme](https://github.com/aaddrick/claude-desktop-debian)). With the variable set, the task runs in a bubblewrap sandbox on your own kernel. The guest machine, the virtual socket and the UEFI firmware leave the picture. That is why the flag works on hosts that fail the five checks. What it does not give you is the boundary Anthropic documents. A bubblewrap sandbox shares the host kernel; the guest in the VM does not. The flag also belongs to that project's builds. The AUR entry and the Fedora script are separate packagings, so check before you plan around it. Nor is it automatic. Launch without the variable and the app takes the upstream path and shows the original message again. The project's docs index calls the earlier bwrap daemon "superseded on KVM hosts" and parks it under `scripts/cowork-fallback/`. The two paths are ranked in the project's own docs. ## Where the session's machine comes from Every message above describes a machine Cowork tries to build on your computer. A Kortix session builds on one you never configure. One isolated sandbox per session. Each session has its own isolated machine and branch. Slack and Microsoft Teams are live. Email is experimental, per project. The host that failed a check installs nothing, and the session still runs ([Read the docs](https://kortix.com/docs)). Cowork stays on hosts that pass the five checks. Agent work that has outgrown the laptop goes to a session with a machine of its own, and [how the agent route compares with the desktop app](/agent-on-linux) covers the choice per job. ## What Linux readers ask about Cowork and KVM ### Does Claude Cowork work on Linux? Yes, on a host that exposes the devices the virtual machine needs. Cowork runs its tasks in a virtual machine the desktop app hosts with QEMU and KVM, so firmware virtualization, `/dev/kvm` and `/dev/vhost-vsock` decide whether it starts. ### Why does Claude Cowork say it requires KVM? Because Cowork boots a virtual machine, and KVM is how the Linux kernel lets one run. The message means hardware virtualization is off in firmware or `/dev/kvm` is closed to your account; turn the first on, or join the `kvm` group and log back in. ### Can you run Claude Cowork on ChromeOS? No, not on the Chromebook itself. On ChromeOS a missing `/dev/vhost-vsock` with no module directory under `/lib/modules` is a common combination, and Anthropic says that support cannot be added by hand. ## Put the session on a cloud computer Start from a browser tab, the CLI, or a Slack thread, and the KVM check stops applying to the machine in front of you. [Try Kortix](https://kortix.com) · [How the agent route works](https://claudedesktoplinux.com/agent-on-linux)