[B[BUG] Cowork Windows - RPC error -1: virtiofs/Plan9 mount fails after brief use

[djv-ai]

Preflight Checklist

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

What's Wrong?

What's wrong?
Cowork on Windows fails with: RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

The error occurs repeatedly. Cowork works briefly after restarting Claude Desktop, then breaks again after a short time. Restarting does not permanently fix it.

Steps to reproduce:

1. Open Claude Desktop on Windows
2. Open Cowork tab
3. Run any task
4. Cowork works briefly then crashes with the error above
5. Restarting Claude Desktop temporarily fixes it but error returns

What I tried:

• Restarting Claude Desktop
• Killing all claude.exe processes in Task Manager
• Switching workspace folder from Desktop to a plain folder (C:\Users\User\COWORK)
• Running wsl --shutdown (WSL not installed)

System:

• OS: Windows 11 Home
• Product: Cowork on Claude Desktop (not Claude Code CLI)
• Subscription: Max plan
• WSL: Not installed

What Should Happen?

the system should be stable and not crash or become inactive intermittently

Error Messages/Logs

RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

Steps to Reproduce

not sure this possible as im ruining from my personal desktop

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

1.14010 (da63f3

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Cowork: RPC error -1 virtiofs/Plan9 mount fails with "Plan9 mount failed: bad address" #26554
2. RPC error -1: virtiofs mount failure after ~1 hour of use on Windows #27576
3. [Desktop/Windows] VirtioFS Plan9 mount goes stale after VM idle, breaks workspace sessions #28890

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[andynewlife]

Windows user. Same problem here

[ray-berg]

I had Claude Code build a monitor script to gather information related to this issue. I also had it generate this summary If it might help:

Hyper-V VM Stall: Root Cause Analysis of Recurring Plan9 Mount Failures

Summary

I built a real-time monitoring tool to diagnose the recurring RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address failures on Windows. After capturing 4 sessions totaling ~4.5 hours of data (233 spawn attempts, 140 failures), the root cause is clear: the Hyper-V lightweight VM enters a "silent stall" where vmmem stops consuming CPU while CoworkVMService falsely reports status "Running." Plan9 mounts fail because the guest kernel is unresponsive, not because of any network, memory, or filesystem issue.

Environment

Component	Value
OS	Windows 11 Enterprise (10.0.26200)
CPU	Intel Core i9-9900K (16 cores)
RAM	64 GB
Claude Desktop	v1.1.4498
Hyper-V	Enabled (VM Platform + Hypervisor Platform)
VM Config	4096 MB RAM, 2 vCPUs, LinuxKernelDirect boot

Monitoring Methodology

I wrote a PowerShell script that tails cowork_vm_node.log, coworkd.log, and cowork-service.log in real time, captures system snapshots on every spawn failure, and takes baseline measurements every 5 minutes including:

• vmmem process CPU time (cumulative CPU_s), working memory, and PID
• cowork-svc CPU/memory
• System memory, CPU%, Hyper-V event log entries, power state events
• Per-event correlation (consecutive failures, success rate, active processes)

Baselines are compared to compute a vmmem CPU delta per interval. A healthy VM consumes 20-40 CPU-seconds per 5-minute interval. A stalled VM consumes < 2 CPU-seconds.

The Smoking Gun: Live Capture of Stall Onset

Session 3 (v2.2 monitor, 09:11-10:48, 97 minutes) captured the transition from healthy to stalled in real time:

Time	vmmem CPU delta (per 5 min)	vmmem WorkingMB	Spawns	Phase
09:16 - 09:31	28-29s	2,412-2,414	All succeeding	Healthy
09:36	43.2s	3,318 (+904 MB jump)	All succeeding	Heavy load (4-5 concurrent)
09:41	131.4s	3,318	All succeeding	Peak activity
09:46	78.8s	3,318	All succeeding	Load tapering
09:51	35.4s	3,318	Last success at 09:51:53	Declining
09:56	11.5s	3,318	All failing	Degraded
10:01	0.7s	3,318	All failing	Stalled
10:06 - 10:47	0.7-0.8s	3,318 (frozen)	All failing	Stalled (no recovery)

The VM gradually stopped processing over ~15 minutes after a period of heavy concurrent activity. Working memory jumped by 904 MB during load and never freed — it locked at exactly 3,318 MB for the remaining 56 minutes of the session. CoworkVMService reported "Running" throughout.

All Session Data

Session 1: Mar 3, 06:05-07:38 (93 min)

• 79 successes, then 15 consecutive failures (no recovery)
• vmmem CPU delta dropped from 30-40s/interval to 0.5s at exact failure onset
• vmmem WorkingMB locked at 3,388 MB for 65+ minutes
• vmwp showed identical CPU stall
• No network issues, no memory pressure, no OOM, no cgroup failures

Session 2: Mar 3, 08:00-08:51 (51 min)

• Started with VM already stalled (carried over from Session 1)
• 24 consecutive failures, then cowork-svc self-recovered via VM restart
• 15 successes after restart, then stalled again — 10 more failures
• Proves the stall is recurring: VM restart does not fix the underlying cause

Session 3: Mar 3, 09:11-10:48 (97 min)

• Fresh VM start, clean slate
• 39 consecutive successes over ~39 minutes
• Gradual degradation captured live (table above)
• 57 consecutive failures with no recovery
• 10 vm_stall_detected alerts fired by monitor

Control Session: Mar 2, 16:49-06:05 (13 hours overnight)

• No VM active (cowork not in use)
• Zero crashes — confirms the problem is intrinsic to VM lifecycle

Stall Signature

Every stall exhibits the same characteristics:

1. vmmem CPU_s stops incrementing: delta drops from 20-40s per 5-min interval to 0.5-0.8s (effectively zero)
2. vmmem WorkingMB freezes: locks at exact value (3,388 or 3,318 MB), never freed
3. VmServiceStatus lies: reports "Running" while the VM is non-functional
4. vmmem is unkillable: Stop-Process returns "Access Denied" even as admin (it's a kernel pseudo-process)
5. vmwp stalls identically: same CPU freeze pattern as vmmem
6. No application-layer warning signs: no OOM, no cgroup failures, no network drops, no disk pressure
7. Binary state change: healthy one minute, stalled the next (or gradual over ~15 min in Session 3)

Failure Mechanism

cowork-svc creates process container in VM
  -> VM reports process_created (TotalActive increments)
  -> cowork-svc attempts virtiofs/Plan9 mount on vsock port 9999
  -> Guest kernel is unresponsive (CPU stalled)
  -> Mount times out with "bad address"
  -> spawn_failed logged
  -> No process_exited event (phantom process in VM's count)
  -> Retry in ~60 seconds (same result indefinitely)

Every single failure across all sessions produces the identical error:

RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

What Does NOT Cause the Stall

Based on the monitoring data, these can be ruled out:

• Network issues: Ethernet stayed connected throughout all sessions; no correlation with network events
• Memory pressure: System had 36+ GB free during stalls; no OOM events
• Sleep/wake: Session 3 stalled without any power events; Session 2's second stall also had no power event
• Disk space: 64+ GB free throughout
• cgroup failures: Zero across all sessions
• cowork-svc itself: Its CPU continued growing normally (processing retry attempts) while vmmem was frozen
• OneDrive sync: Working directory is OneDrive-synced, but the stall is a VM-level freeze unrelated to filesystem access patterns

Possible Aggravating Factor: Subnet Conflict

The VM's internal network is 172.16.10.0/24. My host machine has a VPN tunnel to a client site on the same subnet (172.16.10.0/24). While the Plan9 mount uses vsock (not TCP/IP), the subnet collision could cause routing confusion on the host's vEthernet (Default Switch) adapter. This is likely not the root cause (the issue is too widely reported), but it may contribute to instability on my system specifically.

Observations for Anthropic

1. cowork-svc can detect and recover (Session 2 showed a successful VM restart at 08:25), but the detection took 24 minutes / 24 failed spawns. Monitoring vmmem CPU delta could trigger recovery within one baseline interval (~5 min or less).

2. The stall correlates with heavy concurrent load (Session 3: 4-5 simultaneous processes, some running 8+ minutes). The VM handled the load, but stalled as it tapered off — suggesting resource exhaustion or state corruption that manifests post-workload.

3. VM restart doesn't fix the underlying cause — the stall recurred within 15 minutes in Session 2. Whatever corrupts the VM's I/O path survives a restart cycle, or the same trigger fires again quickly.

4. The VM's TotalActive process counter inflates during failures because process_created fires before the mount attempt, but no process_exited arrives when the mount fails. This phantom count may confuse internal bookkeeping.

Reproduction

This is highly reproducible on my system. The stall occurs within 15-60 minutes of active Cowork use. Simply using Cowork normally (multiple agent tasks) is sufficient to trigger it. No special steps required.

[Synthminds]

Same issue here

[JesperLive]

Community workaround: automated fix toolkit for Windows

I kept hitting this exact error and got tired of rebooting, so I built a set of PowerShell scripts that fix it without a reboot and prevent it from coming back.

What it does:

• Kills Claude processes, stops CoworkVMService, purges stale VM cache, restarts the service, relaunches Claude
• Prevention script configures Windows power/sleep/hibernate settings that cause the mount to break
• Background health monitor detects VirtioFS failures automatically and runs the fix within seconds
• Works with both MSIX (Store) and traditional installs, with or without admin

What it doesn't touch: config files, MCP servers, conversations — only the VM cache.

Repo: https://github.com/JesperLive/ClaudeFix

Tested on Windows 10 and 11. Feedback welcome — especially if you hit edge cases it doesn't handle.

[flemming-n-larsen]

I have the same issue. As soon as I give Coworker a task, it fails. I can use Claude Code without any issue.
This is frustrating, as I really want to burn some token with Claude Coworker!

I am running Coworker in the Claude window along Chat and Code on Windows 11 Pro, 25H2.
I have installed PowerShell 7.5.4, if that is important information?

[djwmobley]

System

• Machine: Alienware Aurora R13
• OS: Windows 11 Pro Build 26200 (25H2)
• CPU: Intel i9-12900KF
• RAM: 128GB
• Claude Desktop Version: Latest as of March 2026

Error

RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

Occurs immediately on every session — not intermittently after extended use.

Root Cause Identified

Windows 11 auto-enabled Virtualization Based Security (VBS) with HVCI on this machine. The hypervisor is fully consumed by the OS security stack, leaving VirtualMachineIsolation: False. Cowork's VM cannot initialize a virtiofs mount in this state.

Confirmed via diagnostics

Property	Value
VirtualMachineIsolation	False
VirtualizationBasedSecurityStatus	2 (Running)
CodeIntegrityPolicyEnforcementStatus	2 (Enforced)
VirtualizationFirmwareEnabled (WMI)	False (intercepted by VBS)
HypervisorPresent	True
WasEnabledBy (DeviceGuard + HVCI)	1 (set automatically by Windows, not GPO or MDM)

No vEthernet (cowork-vm-nat) adapter is created — the VM never fully initializes. Docker Desktop was not running. WSL was not involved.

Impact

VT-x is present and functional, but VBS holds exclusive use of it for kernel security features (HVCI). This is the default out-of-box state on Windows 11 Pro on modern hardware — meaning any machine with factory-default VBS/HVCI enabled will hit this silently.

Disabling HVCI via registry resolves the issue, but removes a Windows security feature most users should keep enabled. That is not an acceptable workaround to ask users to perform.

Request

Cowork needs to either:

1. Coexist with VBS/HVCI enabled, or
2. Detect this condition at startup and surface a clear, actionable error instead of a cryptic virtiofs failure