[BUG] Cowork on ChromeOS/Crostini: impossible remediation — Termina kernel lacks CONFIG_VHOST_VSOCK, and tooltip has typo "vhost_vsok"

Preflight Checklist

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

What's Wrong?

On ChromeOS/Crostini (official Linux beta of Claude Desktop, installed in the Crostini Debian container), the Cowork tab is grayed out and its tooltip says Cowork requires vhost_vsock and suggests running sudo modprobe vhost_vsok.

That suggestion cannot ever work on Crostini, for two independent reasons:

1. The kernel was compiled without the driver. Crostini containers share the ChromeOS Termina VM kernel. Its build config shows the vhost-vsock driver is disabled entirely — neither built-in nor a module:

``
$ zcat /proc/config.gz | grep -E 'VHOST|VSOCK'
CONFIG_VSOCKETS=y
CONFIG_VSOCKETS_DIAG=y
CONFIG_VSOCKETS_LOOPBACK=y
CONFIG_VIRTIO_VSOCKETS=y
CONFIG_VIRTIO_VSOCKETS_COMMON=y
CONFIG_VHOST_MENU=y
# CONFIG_VHOST_NET is not set
# CONFIG_VHOST_VSOCK is not set
``

1. Modules can't be loaded from the container anyway. The LXC container has no /lib/modules directory and no modprobe; Crostini containers cannot insert modules into the Termina kernel by design.

Every other Cowork prerequisite the app probes for is satisfied on this machine:

• qemu-system-x86_64 7.2.22 installed
• OVMF firmware present at /usr/share/OVMF/OVMF_CODE_4M.fd
• virtiofsd available at /usr/libexec/virtiofsd (symlinked to the copy the app itself bundles at /usr/lib/claude-desktop/resources/virtiofsd, since Debian bookworm has no virtiofsd package)
• /dev/kvm present, user in the kvm group (nested KVM is exposed on this device)
• Guest-side vsock is built in (CONFIG_VIRTIO_VSOCKETS=y)

So the probe correctly reaches its final check and fails only on host-side vhost-vsock — but the remediation the UI offers is impossible to follow, and on this platform the requirement itself is unsatisfiable by the user.

Note this is distinct from #73568 and #72741: there, vhost_vsock is loaded and working on bare-metal Linux and the yukonSilver platform check still reports unsupported. Here the module genuinely cannot exist.

What Should Happen?

Two separable asks:

1. Detect ChromeOS/Crostini and show an accurate message. Crostini is easy to identify (e.g. /dev/.cros_milestone, /opt/google/cros-containers, or hostname penguin). Instead of suggesting a modprobe that cannot succeed, tell the user Cowork isn't currently possible on Crostini because the ChromeOS kernel lacks vhost-vsock support.
2. (Feature request) Consider a userspace fallback such as vhost-user-vsock (e.g. the rust-vmm vhost-user-vsock backend, or QEMU 7.2+'s vhost-user-vsock-device), which needs no kernel module. That would unblock Cowork on Crostini and on other hosts where /dev/vhost-vsock is unavailable (containers, some cloud VMs) but KVM is.

I've also filed a request on the ChromeOS side asking Google to enable CONFIG_VHOST_VSOCK in the Termina kernel.

Environment

• Claude Desktop 1.17377.1 (official Linux beta .deb)
• ChromeOS Crostini container: Debian GNU/Linux 12 (bookworm), x86_64
• Kernel (shared Termina VM kernel): 6.6.119-09251-gf81e51484dec
• QEMU 7.2.22 (Debian 1:7.2+dfsg-7+deb12u18+b2), OVMF 4M firmware, virtiofsd 1.13.2 (app-bundled binary)