[SOLUTION] RPC error -1: virtiofs mount Plan9 mount failed: bad address — Working Recovery Script + Fix Pattern (Windows 11 Pro)

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?

Related to: #27576 and many similar virtiofs/Plan9 mount issues

Summary

This is a solution post, not a new bug — sharing what consistently works to recover from the RPC error -1 / virtiofs mount / Plan9 mount failed: bad address error on Windows 11 Pro with Claude Code (Cowork/Desktop).

This error has bricked my sessions dozens of times and I've finally nailed down a reliable recovery pattern. Posting here since #27576 and others describe the same symptoms but don't include a working fix.

---

Error Message

RPC error -1 sending FID (virtiofs mount, Plan9 mount failed: bad address)

Also sometimes appears as:

• sandbox connection failed
• Failed to start session: virtiofs mount error
• Sessions hang on "Starting..." indefinitely

---

Environment

• OS: Windows 11 Pro (24H2, Build 26100)
• CPU: AMD Ryzen 9 7950X
• RAM: 64GB DDR5
• Virtualization: AMD-V enabled, Hyper-V active
• Claude Desktop: Latest as of March 2026
• WSL2: Present (Ubuntu 22.04)

---

Root Cause (Best Guess)

The virtiofs shared filesystem between the host and the lightweight Linux VM becomes corrupted or stale when:

1. The host machine sleeps/hibernates mid-session
2. A session crashes or is force-killed
3. Multiple Claude Desktop windows are opened simultaneously
4. Windows Update restarts background Hyper-V services
5. WSL2 and Claude's VM compete for virtualization resources

The VM's Plan9/virtiofs mount point fails to re-establish cleanly, and subsequent session starts inherit the broken state.

---

Recovery Script (PowerShell — Run as Administrator)

This is what consistently fixes it for me:

# Step 1: Kill all Claude processes
Get-Process | Where-Object { $_.ProcessName -like "*claude*" -or $_.ProcessName -like "*anthropic*" } | Stop-Process -Force

# Step 2: Stop the Hyper-V VM used by Claude
# (Claude uses a lightweight VM — stopping it forces a clean slate)
Get-VM | Where-Object { $_.Name -like "*claude*" -or $_.Name -like "*anthropic*" } | Stop-VM -Force -ErrorAction SilentlyContinue

# Step 3: Clear stale VM/session state
# These paths may vary — check your AppData
$claudePaths = @(
    "$env:LOCALAPPDATA\AnthropicClaude\sessions",
    "$env:LOCALAPPDATA\AnthropicClaude\vm-state",
    "$env:TEMP\anthropic-*",
    "$env:TEMP\claude-*"
)
foreach ($p in $claudePaths) {
    if (Test-Path $p) {
        Remove-Item -Recurse -Force $p
        Write-Host "Cleared: $p"
    }
}

# Step 4: Restart Hyper-V services (this is the key step)
Restart-Service vmcompute -Force
Restart-Service vmms -Force

# Step 5: Wait for services to stabilize
Start-Sleep -Seconds 5

# Step 6: Restart Claude Desktop
Start-Process "$env:LOCALAPPDATA\AnthropicClaude\claude.exe"

Write-Host "Done — Claude should start with a fresh VM session"

---

Prevention Tips

After dozens of occurrences, these habits have reduced frequency by ~90%:

1. Don't sleep/hibernate mid-session — close Claude first, or at least end the active session
2. One window at a time — multiple Claude Desktop windows seem to increase mount conflicts
3. Restart Claude after Windows Updates — especially ones touching Hyper-V or WSL
4. If a session hangs on "Starting..." for >30 seconds — don't wait. Kill it and run the recovery script. Waiting longer seems to make the state worse.
5. Keep WSL2 updated — run wsl --update periodically since Claude's VM and WSL2 share virtualization infrastructure

-Although the issues above were essentially resolved by my script*
---

What Would Help From Anthropic's Side

1. Automatic stale mount detection — if the virtiofs mount fails, detect it and auto-recover instead of throwing an opaque RPC error
2. Session recovery — when a session dies from this error, the work is lost. Some kind of session state persistence or auto-save would be huge
3. Better error messaging — "RPC error -1" tells users nothing. A message like "VM filesystem mount failed — try restarting Claude" would save hours of debugging
4. Conflict detection with WSL2 — if WSL2 is actively using resources that conflict, surface a warning

---

Frequency

• Before recovery script: once every 15-60 minutes during moderate use
• After adopting prevention habits: ~So far it's been eliminated - 36 hours in.
• Recovery time with script: <30 seconds (vs. 10-30 min of trial and error before)

Hope this helps others hitting the same wall. Happy to provide logs or additional detail if the team wants to investigate the mount lifecycle.

What Should Happen?

Sessions should recover gracefully from virtiofs mount failures without requiring manual intervention. Specifically:

1. If the VM's filesystem mount becomes stale, Claude should detect and auto-recover (re-mount or restart the VM transparently)
2. Session state should persist across crashes so work isn't lost
3. Error messages should be actionable — e.g., "VM mount failed, restarting..." instead of "RPC error -1"
4. Conflicts with WSL2/Hyper-V should be detected and surfaced as warnings

Error Messages/Logs

RPC error -1 sending FID (virtiofs mount, Plan9 mount failed: bad address)

Sometimes also:
sandbox connection failed
Failed to start session: virtiofs mount error

Steps to Reproduce

This is intermittent and triggered by environmental conditions rather than specific user actions:

1. Use Claude Desktop (Cowork mode) on Windows 11 Pro with Hyper-V and WSL2 active
2. Run a session that involves file operations (read/write in the mounted workspace)
3. Allow the machine to sleep/hibernate while a session is active, OR force-kill a session, OR open multiple Claude Desktop windows
4. Attempt to start a new session
5. Session fails with RPC error -1 sending FID (virtiofs mount, Plan9 mount failed: bad address)
6. Subsequent session starts also fail until the VM state is manually cleared

The error is most reliably triggered by sleep/hibernate mid-session on a machine running both WSL2 and Claude Desktop.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Latest (Claude Desktop / Cowork mode, March 2026)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

JSomm32@pm.me