[BUG] Cowork: Plan9 mount failed: bad address on every spawn after first session — VM unrecoverable without full restart (Windows, v1.1.4498)

Resolved 💬 3 comments Opened Mar 2, 2026 by liveanew Closed Mar 6, 2026

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?

After a fresh VM boot, the first Cowork session spawns and runs successfully. Once that session ends with code=0 (a clean exit), all subsequent spawn attempts immediately fail with:
RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address
The VM remains "connected" from Claude's perspective ([startVM] VM already connected) but the Plan9/VirtioFS subsystem inside the VM is no longer able to mount folders into new sessions. The VM cannot recover without a full Claude restart.
Additionally, on every Claude restart the full VM bundle (rootfs.vhdx, vmlinuz, initrd) is re-downloaded from scratch despite files having been successfully downloaded and validated in the previous session, indicating a path resolution issue between the MSIX package path and the non-Store %APPDATA%\Claude\ path where files are actually written.

What Should Happen?

Cowork should be able to spawn multiple sessions within the same VM instance without VirtioFS mounts failing after the first session ends. Previously downloaded VM bundle files should persist and be reused across restarts without requiring repeated re-downloads.

Error Messages/Logs

Successful first spawn:
[VM:start] Startup complete, total time: 31392ms
[Keepalive] Starting (interval=2000ms)
[Spawn:vm] Spawn succeeded in 7020ms
[Process] Exited, code=0, signal=null


Immediate failure on next spawn attempt:
[Spawn:vm] Spawn failed: RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address
[Process] Error: RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address
[CoworkVMProcess] kill failed with error: RPC error -1: process not found
VM shutdown timeout on Claude quit:
[VM:shutdown] App quit, stopping VM...
[VM:shutdown] Failed: Error: Request timed out


Repeated re-download on every restart:
[Bundle:status] rootfs.vhdx missing
[warm] No warm file found for rootfs.vhdx at current version
[cache] No cached compressed file for rootfs.vhdx
rootfs.vhdx not found, downloading...

Steps to Reproduce

  1. Launch Claude Desktop and open Cowork
  2. Allow VM to boot (takes ~30 seconds, "Startup complete" logged)
  3. Start a new Cowork session — confirm it spawns successfully
  4. Wait for the session to complete or start a new one
  5. Observe immediate Plan9 mount failed: bad address error on any subsequent spawn attempt
  6. Quit Claude — observe VM shutdown times out after ~30 seconds
  7. Relaunch Claude — observe full VM bundle re-downloaded from scratch despite files existing on disk from prior session

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown — issue began mid-session on 1.1.4498.0 after Claude in Chrome extension installation.

Claude Code Version

Claude Desktop 1.1.4498.0 (installed via MSIX, path: C:\Program Files\WindowsApps\Claude_1.1.4498.0_x64__pzs8sxrjxfjjc\)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

  • VM bundle downloads to %APPDATA%\Claude\vm_bundles\claudevm.bundle but Claude appears to look for files in %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\ on each launch, causing repeated unnecessary re-downloads
  • hcsdiag kill cowork-vm returns "A virtual machine or container with the specified identifier does not exist" — confirming VM is fully dead between launches despite Claude not being able to shut it down cleanly
  • The mcp__Claude_in_Chrome MCP server remains referenced in all spawn configs even after the Chrome extension was fully uninstalled
  • Related issues: #27801, #25419, #25206, #25206, #24070

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗