Native ChromeOS release for Cowork — tiered sandboxed execution instead of requiring Crostini/KVM

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Cowork on Linux currently requires a KVM microVM (/dev/kvm + /dev/vhost-vsock), which is a hard wall on ChromeOS Crostini — Termina blocks vhost_vsock at the kernel level, so no amount of dependency installation can satisfy it (see #74587, and aaddrick/claude-desktop-debian#772). A community workaround exists (an opt-in bubblewrap sandbox, merged upstream in aaddrick/claude-desktop-debian#776) and it works, but it's a third-party patch to an unofficial package, not something the ChromeOS install base can rely on.

Given how large the install base is — and how varied it is, spanning browser-only users up through developers and power users running real Linux workflows — this seems worth solving at the source rather than leaving to a community patch indefinitely.

The current failure mode isn't really "Crostini is unsupported," it's "Cowork's isolation model assumes KVM is always available on Linux." That assumption breaks on Crostini specifically (nested virtualization blocked at the Termina layer) and doesn't apply at all on managed/education Chromebooks where Crostini is disabled entirely.

Proposed Solution

Most Cowork tasks don't need a full Linux environment at all — file read/write, web research, drafting, running scripts, light package installs. That class of work already has a mature, production-proven browser-sandboxed execution model: WASM-based runtimes like StackBlitz's WebContainers and Pyodide run real Node.js/npm and Python workloads, including installs and dev servers, entirely inside a browser tab, using Chrome's own sandbox (site isolation, per-process OS sandboxing, the V8 sandbox) as the security boundary — no VM, no KVM, no vsock.

A native ChromeOS release of Cowork (as a proper ChromeOS app or Isolated Web App, rather than routing through Crostini) could default to that model:

Default tier: WASM-sandboxed execution for the majority of tasks. This works on every Chromebook, including managed/education devices where Crostini is disabled entirely — not just ones with Linux enabled.

Escalation tier: WASM shims only go so far. Real software development work — actual git (not just an in-browser reimplementation), compiled toolchains, native CLI tools like bash, grep, sed, make, and Python/Node packages that need native binary extensions rather than pure-WASM equivalents — needs a genuine POSIX environment with real syscalls. That's the actual case for Crostini as an opt-in escalation tier: some Cowork tasks are real development work that a browser sandbox structurally can't fully replicate. Route those through Crostini where it's available and enabled, same as today.

This also removes the need for "Claude in Chrome" as a separate extension on Chromebooks specifically — a native ChromeOS app would have in-app browser driving as a first-class capability rather than a bolted-on extension.

Alternative Solutions

Currently using a community workaround: aaddrick/claude-desktop-debian#776 adds an opt-in bubblewrap Cowork backend for KVM-less Linux hosts. It works, but it's a third-party patch to an unofficial packaging project, not something Anthropic ships or supports directly, and it required real troubleshooting (a rollback after an intermediate build silently broke the patch during an upstream bundle restructuring) to get working reliably.

Simply "fixing the Crostini gate" (e.g. detecting Crostini and falling back to a KVM-less path within the existing Linux client) was also considered, but doesn't address Chromebooks where Crostini is disabled entirely, and still carries a VM-oriented isolation model onto a platform where a lighter, browser-native sandbox would work for most tasks anyway.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

Example scenario, ChromeOS Crostini:

I use Claude Desktop's Cowork feature on a Chromebook via the Crostini Linux container. The official Cowork isolation model requires KVM (vhost_vsock), which Crostini's Termina VM blocks at the kernel level, so Cowork cannot start at all out of the box.

A community package (aaddrick/claude-desktop-debian) added an opt-in bubblewrap-based sandbox as a workaround, but it required tracking a third-party repo, applying non-official patches, and troubleshooting a real regression that broke the Desktop app entirely after an update. None of this should be necessary for a feature as common as running Cowork tasks that only need file access and a sandboxed shell/browser, not full VM isolation.

With a native ChromeOS-first release (a Chrome PWA using WASM/browser-sandboxed execution as the default tier, with Crostini as an opt-in escalation tier for tasks that genuinely need native Linux tools like git), Cowork would work out of the box on any Chromebook, including managed/education devices where Crostini isn't even enabled. This would save Chromebook users from needing to discover, install, and maintain an unofficial packaging workaround just to use a core feature.

Additional Context

Related issues: anthropics/claude-code#74587 (original bug report: Cowork dependency preflight incorrectly checks virtiofsd as an installable APT package rather than checking for the working binary; auto-closed as stale, reopening comment posted) and aaddrick/claude-desktop-debian#772 and #776 (community opt-in bubblewrap Cowork backend for KVM-less hosts, the workaround this request would make unnecessary).

Precedent for browser-sandboxed execution being viable for most Cowork-style tasks without a VM: StackBlitz WebContainers (real Node.js/npm running in-browser) and Pyodide (Python in-browser) are both shipping, real-world examples of this approach at scale.