# Claude Desktop on ChromeOS, Docker and WSL: the open source host

> Claude Desktop installs on a Chromebook or in a container image, a headless server has no desktop to launch it from, and WSL 2 has its own route through Windows. Cowork starts on none of them, for one shared reason. Kortix, the open-source AI Operating System, runs the session on a cloud computer instead.

URL: https://claudedesktoplinux.com/containers-chromeos-servers

## Anthropic's own list of what Cowork asks the host for

`Anthropic's own list of what Cowork asks the host for`

```
On Linux, Cowork runs those tasks in a virtual machine that the desktop app hosts with QEMU and KVM.
Access to /dev/kvm: add your user to the kvm group with sudo usermod -aG kvm $USER, then log out and back in.
Cowork also needs /dev/vhost-vsock, which only kvm group members can open.
QEMU and UEFI firmware: qemu-system-x86, ovmf, and virtiofsd on x86_64, or qemu-system-arm, qemu-efi-aarch64, and virtiofsd on arm64.
If /dev/vhost-vsock is missing and your running kernel has no module directory under /lib/modules
This combination is common on ChromeOS and in container-based Linux environments.
If you work on Windows with WSL 2, install the Windows desktop app and run sessions inside your distribution; see Claude Code Desktop in WSL.
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

Cut from Anthropic's Linux page, checked October 2026. Lines are shortened by deletion, never rewritten.

## Four hosts, one device they cannot hand over

On ChromeOS, in a container image, on a headless server and under WSL 2, Claude Desktop can be installed and Cowork still has no machine to start in. The reason is the same on all four. On Linux the app runs Cowork's tasks "in a virtual machine that the desktop app hosts with QEMU and KVM", so the host has to supply the pieces a virtual machine runs on ([Anthropic's Linux page](https://code.claude.com/docs/en/desktop-linux)). Chat works on every one of these hosts.

Two of those pieces decide these hosts. The app needs access to `/dev/kvm`, and it needs `/dev/vhost-vsock`, "which only kvm group members can open". The second one is where a Chromebook, a container and a rented server fail together. Anthropic's page describes the exact symptom. When `/dev/vhost-vsock` is missing and the running kernel has no module directory under `/lib/modules`, the app reports a kernel problem. The virtualization support Cowork needs is absent, and it cannot be added by hand. The same page calls that combination "common on ChromeOS and in container-based Linux environments".

The mechanism is narrow enough to remember. `/dev/vhost-vsock` is a device the kernel creates when it loads the `vhost_vsock` module, and modules load from `/lib/modules/<version>`. A kernel without that directory has nowhere to load the module from, so the device never appears. Joining the `kvm` group, the fix the docs give for a permissions problem, cannot create it.

There is a section for each of the four: what Cowork does on that host, why, and what you keep. Read your own host first. Two more sections cover the project's opt-in fallback and the route that moves the machine out of the argument.

## ChromeOS: a Debian environment, on a kernel you cannot change

A Chromebook's Linux development environment gives you "a Debian environment" in the Terminal app, with apt available for packages ([Chromebook Help](https://support.google.com/chromebook/answer/9145439)). That is close enough to Anthropic's Debian target that installing the app is the reasonable first move. Chat stays available in a browser tab either way.

Cowork is the part that stops. ChromeOS is one of the two hosts Anthropic names outright, and the message is the kernel one: the virtualization support is missing and cannot be added by hand. ChromeOS keeps its own kernel, and the Linux environment has no module directory for that kernel, so `vhost_vsock` has nowhere to come from. No apt package on the Chromebook changes that.

What survives is worth using. Claude in a Chrome tab works, and so does Claude Code as a CLI in that same Terminal, which starts no virtual machine and needs no vsock device. [The agent route on Linux](/agent-on-linux) covers that split if the CLI is where you want to stay.

## A container image: the kernel and the devices come from outside

An image shares the kernel of whatever runs it and starts with a small default set of devices. `/dev/kvm` and `/dev/vhost-vsock` are in that set only when the process that starts the container passes them through, and `/lib/modules` inside the image usually holds no directory for the host's running kernel.

That is the pair Anthropic describes, so the check fails and Cowork reports the kernel message. Adding `qemu-system-x86`, `ovmf` and `virtiofsd` to the image installs the packages and leaves the device missing. The image cannot manufacture a device its host did not create. The module directory it would need belongs to the host kernel, outside the filesystem you are building.

For CI images and devcontainers, the CLI is the part that fits. It runs Claude Code against the repo in the image and has no guest to boot. Chat runs in a browser on the machine outside the container. If you need Cowork itself, the decision happens on the host that starts the container, and it is a decision about that host's kernel and device list.

## A headless server: no launcher, and a device list you did not write

The documented install ends at a launch, from the application launcher or by running `claude-desktop` in a terminal. A server reached over SSH has neither, so the desktop app has nothing to open into. That is the first wall, and it is separate from the second one: even with a graphical session available, the machine still has to expose `/dev/kvm` and `/dev/vhost-vsock`.

On rented hardware you do not set that. The device list belongs to the provider. A server that starts life as a guest of another hypervisor has no firmware setting for you to open. Two commands answer the question in a second, and they are two of the checks the app makes at launch:

```sh
ls -l /dev/kvm /dev/vhost-vsock
ls "/lib/modules/$(uname -r)"
```

If both devices are listed and the module directory exists, the app can host its virtual machine. That is [the Ubuntu and Debian case](/ubuntu-debian). Anything else leaves the server for the CLI, which works over SSH against the repo directly, and for chat in a browser.

## WSL 2: the Windows app is the documented route

Anthropic's page does not send Windows readers to the Linux build at all: "If you work on Windows with WSL 2, install the Windows desktop app and run sessions inside your distribution; see Claude Code Desktop in WSL."

That sentence splits the work in two. The desktop app, and the virtual machine it hosts, live on the Windows side. The WSL distribution is where Claude Code sessions run, next to the toolchain and the repo they touch. Installing the `.deb` inside the distribution is a third arrangement Anthropic does not document. It inherits the nested-guest problem: the distribution is already a guest, and the app would ask it to host a second machine and a vsock device.

Keep the distribution for the CLI, where it is the natural place for git, compilers and test runners. Keep chat in the Windows app or a browser tab. Cowork follows the Windows app in this arrangement, and its requirements are the Windows app's, documented on Anthropic's own desktop pages.

## The bubblewrap flag swaps the sandbox, not the host

The repackaging project ships a way to run Cowork's work without a virtual machine: "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)).

Set the variable and the task runs inside a bubblewrap sandbox on your own kernel. No guest boots, `/dev/vhost-vsock` stops being a requirement, and a Chromebook or a container can get further than it did. The limit is in what a bubblewrap sandbox is: a boundary around processes on the kernel you are already running, rather than a separate machine the app boots with QEMU and KVM. Isolation against a mistake in a task is one thing; the guest boundary Anthropic documents is another.

The flag is a switch, so a launch without it returns to the upstream path and the original error. It also belongs to that project's builds, which carry several Linux patches. Anthropic's own `.deb` and the AUR entry are separate packagings, so check the build in front of you before you plan around the flag. On WSL 2 and on a headless server the flag does not enter the picture, because the Linux build is not the documented route there.

## When the host is the whole problem, the session gets its own computer

All four of these hosts are cases where the machine in front of you decides whether agent work can run. The alternative is to stop configuring that machine and start the session from something you already hold: a Chrome tab, an SSH terminal, a container shell, a Windows app. Kortix is the open-source AI Operating System, and the session runs on compute the project provisions rather than on the device you installed it from.

Slack and Microsoft Teams are live. Email is experimental, per project. A message in a channel you already have open starts the work and brings the answer back to the same thread, which is the shortest route from a Chromebook, a headless box or a WSL terminal to an agent that runs.

One isolated sandbox per session. Each session has its own isolated machine and branch. The kernel in your Chromebook or your container never enters Anthropic's check, because the work happens on that sandbox and not in the image or the distro. [The docs](https://kortix.com/docs) walk through a project's first session.

## What ChromeOS, Docker and WSL readers ask first

### Can you run Claude Desktop on ChromeOS?

Yes for chat, no for Cowork. Anthropic's Linux page names ChromeOS as a host where `/dev/vhost-vsock` is commonly missing with no module directory to add it from, and says the support cannot be added by hand. Chat works in a Chrome tab, and the CLI works in the Linux terminal.

### Can you run Claude Desktop in Docker?

Yes for the CLI, no for Cowork. A container shares the host's kernel and gets `/dev/vhost-vsock` only if the host passes it in, which is the container case Anthropic names in the same sentence. The Claude Code CLI runs inside the image, and chat runs in a browser outside it.

### Does Claude Desktop work in WSL?

Yes, through the Windows app rather than the Linux build. Anthropic's docs send Windows readers to the Windows desktop app, with Claude Code sessions running inside the WSL distribution. The distribution keeps the CLI and the repo, and the desktop app stays on Windows.

## Run the agent where the host check has already passed

Start from the browser tab, the terminal or a chat message you already have open.

[Try Kortix](https://kortix.com) · [How a session runs](https://claudedesktoplinux.com/agent-on-linux)