[BUG] Cowork on Linux reports "not supported on this device" when the user lacks access to /dev/vhost-vsock — no reason surfaced in UI or logs

Confirmed on Ubuntu 24.04.4 LTS + Claude Desktop 1.24012.9 (official .deb). Same root cause as described here.

What matched

• Full KVM stack already present (qemu-system-x86_64, OVMF OVMF_CODE_4M.fd, virtiofsd at /usr/libexec/virtiofsd)
• /dev/kvm already had the logind uaccess ACL (crw-rw----+) → accessible without kvm group membership
• /dev/vhost-vsock was root:kvm 0660 with no uaccess → EACCES on the app's R_OK|W_OK probe
• cowork_vm_node.log only showed the consequence (yukonSilver not supported), never which device failed

Grepping app.asar confirms the evaluator treats either device failing as no_permission / kvm_permission_denied, so the UI's "add yourself to the kvm group" hint is directionally right but incomplete: on Ubuntu/Mint the real gate is almost always vsock, because kvm already gets TAG+="uaccess" in 70-uaccess.rules and vsock does not.

Extra nuance: usermod fails for authd / Entra ID users

On hosts using Ubuntu authd with Microsoft Entra ID, the account is not in /etc/passwd, so:

sudo usermod -aG kvm $USER
# usermod: user 'user@company.com' does not exist

does nothing. gpasswd -a "$USER" kvm works because it resolves the user via NSS.

Workaround that fixed it immediately (no re-login required)

# 1. Ensure the module is loaded (persist across reboots)
sudo modprobe vhost_vsock
echo vhost_vsock | sudo tee /etc/modules-load.d/claude-cowork.conf

# 2. Give /dev/vhost-vsock the same uaccess treatment as /dev/kvm
echo 'SUBSYSTEM=="misc", KERNEL=="vhost-vsock", TAG+="uaccess"' | \
  sudo tee /etc/udev/rules.d/70-claude-cowork-vsock.rules
sudo udevadm control --reload-rules
sudo udevadm trigger --subsystem-match=misc --sysname-match=vhost-vsock

# 3. Optional belt-and-suspenders (works for authd users; usermod may not)
sudo gpasswd -a "$USER" kvm

After a full quit/relaunch of Claude Desktop, the log flipped from yukonSilver not supported to [Bundle:status] rootfs.img missing (i.e. supported, proceeding to download the VM bundle).

Suggestions for Anthropic / distro

1. Surface kvm_permission_denied (and which device failed: kvm vs vsock) in the UI and in cowork_vm_node.log.
2. Document the uaccess udev rule above, or ship it with the .deb.
3. Ideally push upstream so /dev/vhost-vsock gets TAG+="uaccess" in 70-uaccess.rules the same way /dev/kvm already does — that would fix stock Ubuntu/Mint installs without any user action.

Signalement en complément : sur ma machine (Linux), Cowork a cessé de pouvoir se connecter à ses dossiers locaux après le 11 août 2026. Je ne peux pas affirmer de lien de cause à effet, mais ce jour-là j'ai installé Playwright + Chromium via npx playwright install --with-deps chromium dans une session Claude Code (paquets système ajoutés : xvfb, polices, libatk*), sur cette même machine. Depuis, plus moyen de me connecter aux dossiers locaux depuis Cowork. Je n'ai pas de message d'erreur précis à partager pour l'instant. Est-ce que ça pourrait être lié aux permissions décrites dans ce ticket ?

Je crois qu'il s'agit probablement d'un mode de défaillance différent, mais c'est facile à distinguer.

Le bug décrit dans ce ticket est un blocage en amont du démarrage : la VM ne démarre jamais, toute commande shell renvoie « not supported on this device », et cowork_vm_node.log affiche [startVM] VM not supported (linux/x64), skipping. L'accès aux dossiers intervient à une étape ultérieure : c'est virtiofsd qui monte les répertoires partagés dans une VM qui, elle, a bien démarré. Première étape, donc : déterminer quelle phase échoue, en demandant à Claude d'exécuter n'importe quelle commande shell dans une session Cowork.

• « not supported on this device » → même blocage que dans ce ticket ; lancez les vérifications ci-dessous.
• le shell fonctionne mais les dossiers sont absents ou vides → problème différent, côté virtiofsd/montage.

Diagnostic :

ls -l /dev/kvm /dev/vhost-vsock; groups; lsmod | grep vhost_vsock
grep -iE "not supported|virtiofs|mount|denied|error" ~/.config/Claude/logs/cowork_vm_node.log | tail -40
df -h ~

Concernant Playwright : --with-deps ne fait qu'installer via apt des bibliothèques graphiques et des polices — je ne vois pas par quel mécanisme cela révoquerait l'accès à kvm/vsock, l'ACL uaccess étant réappliquée par logind à chaque ouverture de session. Deux explications plus banales collent mieux à la chronologie : l'espace disque consommé par l'installation de Chromium (Cowork demande ~10 Go libres pour l'image de la VM), ou une mise à jour de Claude Desktop sur la même période. Le journal devrait permettre de trancher.

---

Rédigé par Claude ; relu et publié par l'auteur de ce ticket.