[BUG] Cowork: RPC error -1 virtiofs/Plan9 mount fails with "Plan9 mount failed: bad address"

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/25419
2. https://github.com/anthropics/claude-code/issues/25132
3. https://github.com/anthropics/claude-code/issues/25096

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

just got this error on claude cowork: RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

I am also receiving a repeated error after trying to send a second prompt in Claude Cowork:

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

About My PC -
Alienware Aurora R16
Product ID: 00391-90050-00000-AA930
Processor: Intel(R) Core(TM) i9-14900KF (3.20 GHz)
RAM: 64.0 GB
Graphics Card: NVIDIA GeForce RTX 4090
System Type: 64-bit operating system, x64-based processor
OS: Windows 11 Pro for Workstations build 26200.7840

i also recieved only way to get rid of it is ending claude app tasks on task manager and restart the app 2-3 times

also getting this error on claude cowork: RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

I have the same issue and after multiple restarts still cannot get it to work. Seems to definitely be optimized for mac and not windows

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

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

still cant use cowork due to this error

I'm having the same issue:

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

Using claude cowork on windows 11

Same issue:

Windows 11 Home
Dell, Intel processor
Virtualization enabled in BIOS
Virtual Machine Platform + Windows Hypervisor Platform both enabled
VPN disabled
Fresh reinstall done
Error: RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

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

Just upgraded from Windows Home to Windows Pro 11 and still getting the
RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

Environment

• OS: Windows 11 Pro 25H2 (Build 26200.7840)
• Virtualization: Hyper-V, Virtual Machine Platform, and WSL all enabled
• Claude Desktop: v1.1.3963.0 (MSIX package, fresh install 2025-02-22)
• Plan: Max ($100/month)
• Hardware: Lenovo laptop, x64

Behavior

• Fresh install after completely removing previous Squirrel and MSIX installations
• VM connects successfully ([startVM] VM already connected)
• Fails consistently at virtiofs mount step when spawning any Cowork process
• Error occurs on every attempt, not just after the first task
• Get-VM returns empty — no Hyper-V VM is visible despite cowork-svc running

Error from cowork_vm_node.log

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

What I've tried (none resolved the virtiofs issue)

• Clean uninstall and reinstall (removed all AppData, MSIX packages, and CoworkVMService)
• Ran sfc /scannow — found and repaired corrupt system files
• Ran DISM /Online /Cleanup-Image /RestoreHealth — completed successfully
• Restarted Hyper-V services (vmms, vmcompute)
• Full system reboot after repairs
• VPN disabled, network connectivity to api.anthropic.com confirmed working

Note

The MSIX install itself initially failed with 0x80073CF6 due to the corrupt system files. After SFC/DISM repairs, installation succeeded, but the Plan9 mount error persists.

I'm also having this issue. Would love to help troubleshoot. Like other users, I am on Windows 11, with virtualization enabled. The fixes detailed here do not reliably solve the problem.

Same here. F... Anthropic. MAX Plan

Same issue here. Lenovo ThinkPad T14, Windows 11, Team plan. Cowork was working fine until a few days ago — started failing suddenly with the exact same error (RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address). No system changes were made on my end. Restarting the app, restarting the PC, and reinstalling the workspace have not resolved the issue. Tasks occasionally complete (progress steps show green checkmarks) but the error appears at the end, preventing access to results.

Reproduces on Windows 11 Home Insider Preview (25H2)

Adding another data point — same error on an Insider build:

| | |
|---|---|
| Edition | Windows 11 Home Insider Preview |
| Version | 25H2 |
| OS Build | 26300.7877 |
| Experience Pack | 1000.26100.333.0 |
| Installed | 28/01/2026 |

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

Cowork fails on every attempt, not just after the first task.

Workaround status: Disabling Hyper-V is not viable — WSL2 and Docker Desktop are both essential to my workflow. No other workaround has resolved the issue.

This may be a coincidence, I had verified all my settings and did a
full reinstall of the desktop app yesterday with no luck. Today just for
kicks, I logged out, closed the app, and then hit ctrl alt del to open the
task manager and then found claude still running, right clicked, and ended
task to shut it down. I relaunched the desktop app logged in and error was
gone. Coincidence maybe, but easy to try. If you're still battling with
this one it's worth a shot after your reinstall.

On Mon, Feb 23, 2026 at 10:40 AM Caspar Addyman @.***>
wrote:

InfantLab left a comment (anthropics/claude-code#26554) <https://github.com/anthropics/claude-code/issues/26554#issuecomment-3945531584> Reproduces on Windows 11 Home Insider Preview (25H2) Adding another data point — same error on an Insider build: Edition Windows 11 Home Insider Preview Version 25H2 OS Build 26300.7877 Experience Pack 1000.26100.333.0 Installed 28/01/2026 Error: RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address Cowork fails on every attempt, not just after the first task. Workaround status: Disabling Hyper-V is not viable — WSL2 and Docker Desktop are both essential to my workflow. No other workaround has resolved the issue. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/26554#issuecomment-3945531584>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B6WWZXE6U2FPIEIFTNCYPCL4NMNNZAVCNFSM6AAAAACVRBWQSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNBVGUZTCNJYGQ> . You are receiving this because you commented.Message ID: @.***>

Editing to add: I missed the logout/login part of your method. I just tried that and it did get it working again. Not ideal, but better than restarting my whole system. Thank you.

This may be a coincidence, I had verified all my settings and did a full reinstall of the desktop app yesterday with no luck. Today just for kicks, I logged out, closed the app, and then hit ctrl alt del to open the task manager and then found claude still running, right clicked, and ended task to shut it down. I relaunched the desktop app logged in and error was gone. Coincidence maybe, but easy to try. If you're still battling with this one it's worth a shot after your reinstall. […](#)

FWIW: When I've ended the Claude instances running in task manager, reopened Claude Cowork and tried to resend the last message that threw the original error in this bug post, I then get this new error:

VM service not running. The service failed to start.

...and have to restart my computer to get it to work again. Happens multiple times/day.

Here's what I'm running it on in case it's useful info:

Processor AMD Ryzen 9 9900X 12-Core Processor (4.40 GHz)
Installed RAM 128 GB (126 GB usable)
System type 64-bit operating system, x64-based processor
Edition Windows 11 Pro
Version 25H2
OS build 26200.7840
Experience Windows Feature Experience Pack 1000.26100.291.0

That solved the problem! But Claude ran as 8 (!) separate processes/duplicates I had to end in the Task Manager. That must be a bug.

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

Same issue. Restarted cowork multiple times. Windows 11 Home.

RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address
Windows 11 Home
OS build: 26200.7840

after doing a login logout & force close in task manager. a different error appear again. reinstall the workspace doesn't solve the problem.

Failed to start Claude's workspace
VM service not running. The service failed to start.
Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace or share your debug logs to help us improve.

I've the same error on a clean machine from 0 nothing enabled by default only installation it's claude code.

I've had the same problem: RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

Tried it in onedirve folders and outside onedirve folders, no difference. tried it on folders with no files in them or just a basic .txt file.

Got it working by closing app, deleting vm_bundles and it worked for a while then breaks again mid-session. Windows 11, 9800x3d, 64mb RAM,

Root Cause Analysis: Cross-Drive Symlink + VirtioFS

Environment: Windows 11 Pro 10.0.26200, Claude Desktop (non-MSIX install)

Findings

I've identified a likely root cause specific to environments with cross-drive NTFS symlinks:

C:\Users\USER\.claude  →  D:\.claude  (symlink, cross-drive)
TEMP/TMP = D:\Rust\tmp  (non-system drive)

Cowork mounts .claude as one of its VirtioFS/Plan9 shares:

mounts=6 (outputs, .claude, .skills, .local-plugins, ..., uploads)

VirtioFS/Plan9 cannot follow Windows NTFS symlinks across drive boundaries. The VM attempts to mount C:\Users\USER\.claude but the actual data lives on D:\. From the VM's perspective, this is an unresolvable address → "bad address".

This is the same root cause as the EXDEV error reported in #25476 — cross-drive path resolution failures in the Cowork VM layer.

Additional Trigger: Spaces in Project Path

When opening a project like "CGAP 2026" (with a space), the mount path becomes:

--add-dir /sessions/.../mnt/CGAP 2026

Plan9 protocol has known instability with spaces in mount paths (same pattern as the Filesystem MCP cmd.exe /C quoting bug).

Diagnostics

| Check | Result |
|-------|--------|
| Get-NetNat | No cowork-vm-nat entry |
| sessiondata.vhdx | Not found (VM bundles never created) |
| MSIX package folder | Does not exist in %LOCALAPPDATA%\Packages |
| CLI vs Desktop conflict | Not affected (C:\Users\USER\.local\bin\claude.exe) |

Suggested Fix (for Anthropic)

1. Resolve symlinks before mounting: Use GetFinalPathNameByHandle / realpath equivalent to resolve the actual target path before passing to VirtioFS
2. Quote/escape mount paths: Ensure spaces in project folder names are properly handled in Plan9 mount arguments
3. Detect cross-drive symlinks and warn or auto-resolve at Cowork startup

Related Issues

• #25476 (EXDEV error — same cross-drive root cause)
• #24974 (Windows Cowork port incomplete)

Same error here. WINDOWS 11 PRO.

Same error for me. Windows 11.

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

Can't actually have any chats with cowork due to this error :(

Same Issue - Windows11 - any resolution yet on this?

Same Issue - Windows11 - any resolution yet on this?

started working after a couple of times sign out & sign ins

Same issue here.

It's still the same... aren't they going to fix it?

Workaround: Post-crash VirtioFS mount corruption on Windows 11 Home

Environment: Windows 11 Home, Claude Desktop (MSIX install), CoworkVMService running

Root Cause (in my case): After a system crash during an active Cowork session, the VirtioFS/Plan9 mounts were left in a corrupted state. The CoworkVMService remained running but was attempting to reconnect to mount points that no longer existed. Stale task output files (0-byte symlinks) in %TEMP%\claude\ confirmed the mounts were broken.

Symptoms:

• RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address on every Cowork task
• Cowork had been working perfectly for weeks prior to the crash

Workaround — run in an Administrator command prompt/PowerShell:

:: Stop the stuck CoworkVMService
net stop CoworkVMService

:: Clear stale Cowork task cache with broken symlinks
rmdir /s /q "%TEMP%\claude"

:: Clear MSIX temp state
del /s /q "%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\TempState\*"

:: Kill any lingering Claude processes
taskkill /f /im "Claude.exe"
taskkill /f /im "CoworkVMService.exe"

Then reopen Claude Desktop — Cowork will provision a fresh VM and new mount points. Project files are unaffected; this only clears Cowork's session/temp data.

Note: This fixed the issue in my specific case (crash-induced corruption). Others experiencing this error without a preceding crash may have a different underlying cause.

Suggestion to Anthropic: Cowork should detect stale/broken VirtioFS mounts on startup and automatically re-provision rather than repeatedly failing. A "Reset Cowork VM" option in settings would also help users recover from crashes without manual cleanup.

I got it a lot. I fixed by moving my files out of OneDrive and onto HardDrive. Downside cannot anymore access from iPad. Before I made the change had to restart PC every 15 minites. Haven't done it since I moved the files. I had configured the files to always be available offline, but that didn't help-

Workaround that fixed it for me (Windows 11 Home)

Symptoms:

RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address on every prompt
After closing and reopening: Failed to start Claude's workspace — Request timed out

Root cause:
Multiple stale claude processes (I had 10 running) were keeping dead mount addresses occupied. Every new Cowork session tried to claim an address that was already "taken" by a zombie process.

Fix:

1. Open Task Manager → go to Details tab
2. Find and End Task on every claude.exe process (there may be 5–10)
3. Reopen Claude Desktop
4. Log out → log back in
5. On first reopen you may see "Request timed out" — wait ~30 seconds and retry, the VM re-initializes

This is a temporary fix. The underlying bug (process cleanup not happening on close) needs to be fixed by Anthropic. Restarting Cowork periodically if it crashes after ~1 hour is the only other workaround until then.

PS. got claude to diagnose and resolve it.

The most common root cause is a cross-drive NTFS symlink on ~/.claude — VirtioFS can't follow symlinks across drive letters. A PowerShell one-liner checks for this. Spaces in project folder names also break Plan9 mount argument parsing. Diagnostics + fixes: https://cacheoverflow.dev/blog/r24-U-Uj

Same error here:

Win 11 Pro.
Extremely annoying I have to restart the PC each time to have claude work (not only Cowork, event chat and code from the win App), I think that Anthropic should address it asap.
I've tryied simply killing all claude processes but in my case it's not enough, I have to restart the entire PC

Additional data point: recurring virtiofs mount failure on Windows 11 Insider

Environment:

• OS: Windows 11 Insider Preview (build 26200.7840)
• CPU: Intel Core Ultra 7 265KF
• RAM: 64 GB
• Claude Desktop: v1.1.3963
• Claude Code SDK: v2.1.49

Behavior:
The Plan9 mount failed: bad address error recurs persistently since Feb 22, 2026 across multiple sessions and different working directories:

• Local path: C:\Users\...\Documents\Develop\PICis1 (no spaces, no symlinks, no cloud sync)
• Google Shared Drive: G:\Shared drives\... (also fails)

This rules out cross-drive symlinks, spaces in paths, and OneDrive/cloud sync as root causes — the error occurs on plain local NTFS directories as well.

Log evidence (session local_42bc7fdf, Mar 2):

00:34:30 [info] [FileWatching] Starting file watcher: C:\Users\...\PICis1
00:36:05 [info] [FileWatching] Starting file watcher: C:\Users\...\PICis1  (restart #2)
00:37:06 [info] [FileWatching] Starting file watcher: C:\Users\...\PICis1  (restart #3)
00:37:58 [error] Process spawn error: RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address
00:37:58 [info] [FileWatching] Starting file watcher: C:\Users\...\PICis1  (restart #4)
00:38:22 [error] Process spawn error: RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address
00:38:22 [info] [FileWatching] Starting file watcher: C:\Users\...\PICis1  (restart #5)
00:38:29 [warn] readLocalFile: failed to resolve file path for ...\PICis1/CLAUDE.md

The FileWatcher restarted 5 times in 4 minutes before ultimately failing to resolve CLAUDE.md, causing Cowork to hang.

Confirmed non-factors:

• .claude directory is NOT a symlink (LinkTarget is empty)
• Working directory is NOT a symlink
• No spaces in path (PICis1)
• Documents folder is NOT redirected (standard C:\Users\...\Documents)
• Hyper-V services running

Windows features enabled:

• Virtual Machine Platform ✅
• Windows Hypervisor Platform ✅

Force-restarting Claude Desktop sometimes temporarily resolves the issue, but it returns within minutes to hours.

Running into the same issue.

this is a recurrent error , always is the same after 10 iterations.

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] I am using the latest version of Claude Desktop

What's Wrong?
Claude in Chrome extension cannot connect to Claude Desktop on Windows 11 Home.
Every time Claude Desktop attempts to connect to the Chrome extension,
a popup appears saying "Login to Claude in Chrome - Make sure you are signed
in to Claude in Chrome with the same account as Claude Desktop."

However, both are signed in with the same account (lovespiritgrowth@gmail.com).
When attempting to use Cowork mode, the error appears:
RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address

Steps to Reproduce

1. Install Claude Desktop on Windows 11 Home (Version 25H2, Build 26200.7840)
2. Install Claude in Chrome extension in Chrome browser
3. Sign in to both with the same account
4. Open Claude Desktop → switch to Cowork mode or attempt Chrome connection
5. Error appears immediately

Expected Behavior
Claude in Chrome should connect successfully to Claude Desktop and allow
browser automation.

Actual Behavior

• Popup: "Login to Claude in Chrome" (despite correct account on both sides)
• Cowork error: RPC error -1: failed to ensure virtiofs mount:

Plan9 mount failed: bad address

Environment

• OS: Windows 11 Home, Version 25H2, Build 26200.7840
• Hardware: HP
• Claude Desktop: latest version
• Chrome Extension: Claude in Chrome (Beta)
• Account: Pro plan
• WSL2: Installed (Ubuntu, version 2.6.3) ✅
• Virtual Machine Platform: Enabled ✅
• Windows Hypervisor Platform: Enabled ✅

Additional Notes
I followed all troubleshooting steps including:

• Verified same account on both Desktop and Chrome extension ✅
• Enabled Virtual Machine Platform via DISM ✅
• Installed WSL2 with Ubuntu ✅
• Created new Chrome profile with correct account ✅
• Restarted Chrome before Claude Desktop ✅
• Fully restarted computer ✅

None of the above resolved the issue. This appears to be the same bug
reported in issues #26554, #25663, and #26873.

worked for me (Windows 11 Home) using VirtualBox instead of Hyper-V. Dunno why...

This worked for me:

1. Close claude and kill all claude zombies using task manager.
2. Go to Services and look for CoWorkVMService -> it should be stopped.
3. Start the CoWorkVMService manually - wait for a bit ~ a couple of minutes.
4. Start your Claude Desktop and proceed as normal - the workspace for CoWork takes a while to start up though.

Tested on Windows 11 Pro. Have a go to see if it helps you.

Same issue for the last few days. Makes cowork almost unusable.

I tried all the workarounds but the issue remains persistent for me and has made Cowork unsusable

Sharing some findings for anyone on Windows 11 Home — there's a specific variant of this that behaves differently and the usual fixes don't work.

Check your %APPDATA%\Claude\logs\main.log and search for vm_network_mode. If it says ics, that's the culprit. Home doesn't have the NetNat WMI class, so Cowork falls back to ICS mode. This means vEthernet (cowork-vm-nat) won't show up in your adapters, Get-NetNat throws "Invalid class", and the DNS/NAT fixes floating around this thread simply don't apply to you.

The failure pattern is also more aggressive than what others are describing — it wasn't crashing after an hour for me, it was crashing after one message.

What actually worked: kill all Claude Desktop processes in Task Manager first, then restart the "Claude" service (that's the display name for CoworkVMService) either from the Services tab or PowerShell. After a clean restart I was getting multiple messages through fine. Doesn't fix the root issue obviously, but it's a reliable way to recover when it hits.

Hopefully useful for the Home users in this thread. Would be good to know if there's any plan to stabilize the ICS path — it's not like we can just switch to NAT mode.

Same issue.

System: windows 11, 32GB RAM non-oc, RTX4070, RTX5070, Ryzen 7900, Claude Max.

I tried everything. First it looks like it is fixed but after couple of tasks it gives the same error :/

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.

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

### 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.

Thanks for this! Since I installed and implemented your scripts, I have not had the error recur. At least so far!

Thanks again!

> ### Solución alternativa de la comunidad: kit de herramientas de reparación automatizada para Windows > Seguí encontrando este mismo error y me cansé de reiniciar, así que creé un conjunto de scripts de PowerShell que lo solucionan sin reiniciar y evitan que vuelva a aparecer. > Qué hace: > > Mata los procesos de Claude, detiene CoworkVMService, purga el caché de VM obsoleto, reinicia el servicio y vuelve a iniciar Claude. > El script de prevención configura los ajustes de energía/suspensión/hibernación de Windows que provocan que el montaje se rompa > El monitor de estado en segundo plano detecta automáticamente las fallas de VirtioFS y ejecuta la solución en cuestión de segundos > Funciona tanto con MSIX (Store) como con instalaciones tradicionales, con o sin administrador > > Lo que no toca: archivos de configuración, servidores MCP, conversaciones (solo el caché de la máquina virtual). > Repositorio: https://github.com/JesperLive/ClaudeFix > Probado en Windows 10 y 11. Agradecemos sus comentarios, especialmente si se encuentra con casos extremos que no puede manejar. ¡Gracias por esto! Desde que instalé e implementé tus scripts, el error no se ha repetido. ¡Al menos hasta ahora! ¡Gracias de nuevo!

I used the workaround yesterday and it was a disaster. It kept downloading the 2-3 GB of resources it needs to start CoWork, and it felt like it was losing track of what we were working on in the tasks... I had to uninstall it. A disaster. thanks

The problem persists. WINDOWS 11 PRO. Infuriating...

> > ### Solución alternativa de la comunidad: kit de herramientas de reparación automatizada para Windows > > Seguí encontrando este mismo error y me cansé de reiniciar, así que creé un conjunto de scripts de PowerShell que lo solucionan sin reiniciar y evitan que vuelva a aparecer. > > Qué hace: > > > > Mata los procesos de Claude, detiene CoworkVMService, purga el caché de VM obsoleto, reinicia el servicio y vuelve a iniciar Claude. > > El script de prevención configura los ajustes de energía/suspensión/hibernación de Windows que provocan que el montaje se rompa > > El monitor de estado en segundo plano detecta automáticamente las fallas de VirtioFS y ejecuta la solución en cuestión de segundos > > Funciona tanto con MSIX (Store) como con instalaciones tradicionales, con o sin administrador > > > > Lo que no toca: archivos de configuración, servidores MCP, conversaciones (solo el caché de la máquina virtual). > > Repositorio: https://github.com/JesperLive/ClaudeFix > > Probado en Windows 10 y 11. Agradecemos sus comentarios, especialmente si se encuentra con casos extremos que no puede manejar. > > > ¡Gracias por esto! Desde que instalé e implementé tus scripts, el error no se ha repetido. ¡Al menos hasta ahora! > ¡Gracias de nuevo! I used the workaround yesterday and it was a disaster. It kept downloading the 2-3 GB of resources it needs to start CoWork, and it felt like it was losing track of what we were working on in the tasks... I had to uninstall it. A disaster. thanks

I'll investigate this, but it would be easier if you had some more information to go with. the log file, windows version, admin or not, what version of Claude Desktop etc. - Ether way, thank you for trying, I am sorry this didn't at least help your issue. In all fairness, its a work around to something that shouldn't be happening in the first place. Lets hope that a proper fix will be implemented sooner rather than later.

EDIT:

Thanks for the feedback — that's really helpful. The issue was that every time the fix script ran, it purged the VM cache (~2-3 GB of bundled resources the Cowork VM needs to boot). That forced a full re-download on every fix cycle, which is slow and disruptive. If the health monitor (Watch) was also running, it could trigger additional fix cycles automatically, compounding the problem.

In v4.5.0 we addressed this:

• -KeepCache flag on Fix-ClaudeDesktop — skips the cache purge entirely, so the VM restarts using its existing resources instead of re-downloading everything. The health monitor (Watch) now uses this flag by default for its auto-fix cycles, so background repairs are fast and non-destructive.
• Cache purge is still the default when you run Fix manually (since a corrupted cache is sometimes the actual problem), but you can pass -KeepCache if you want the faster path.
• The README now includes a note explaining when to use each mode.

If you grab the latest zip, the Watch script won't nuke your cache anymore. Manual fix still does by default, but -KeepCache is there when you want speed over thoroughness.

I've been encountering this on Win 11 pro.

Enough for me has been to open an admin level powershell and do

net stop CoworkVMService

which says it's failed, but wait 20 seconds and do

net start CoworkVMService

and up it comes. Didn't even stop Claude desktop while I did it.

> > > ### Solución alternativa de la comunidad: kit de herramientas de reparación automatizada para Windows > > > Seguí encontrando este mismo error y me cansé de reiniciar, así que creé un conjunto de scripts de PowerShell que lo solucionan sin reiniciar y evitan que vuelva a aparecer. > > > Qué hace: > > > > > > Mata los procesos de Claude, detiene CoworkVMService, purga el caché de VM obsoleto, reinicia el servicio y vuelve a iniciar Claude. > > > El script de configuración para prevenir los ajustes de energía/suspensión/hibernación de Windows que provoca que el montaje se rompa. > > > El monitor de estado en segundo plano detecta automáticamente las fallas de VirtioFS y ejecuta la solución en cuestión de segundos > > > Funciona tanto con MSIX (Store) como con instalaciones tradicionales, con o sin administrador > > > > > > Lo que no toca: archivos de configuración, servidores MCP, conversaciones (solo el caché de la máquina virtual). > > > Repositorio: https://github.com/JesperLive/ClaudeFix > > > Probado en Windows 10 y 11. Agradecemos sus comentarios, especialmente si se encuentra con casos extremos que no puede manejar. > > > > > > ¡Gracias por esto! Desde que instalé e implementé tus scripts, el error no se ha repetido. ¡Al menos hasta ahora! > > ¡Gracias de nuevo! > > > Ayer usé la solución alternativa y fue un desastre. Seguía descargando los 2-3 GB de recursos necesarios para iniciar CoWork, y parecía que perdía la cuenta de lo que estábamos haciendo en las tareas... Tuve que desinstalarla. Un desastre. Gracias. Investigaré esto, pero sería más fácil si tuvieras más información. El archivo de registro, la versión de Windows, si eres administrador o no, qué versión de Claude Desktop, etc. En cualquier caso, gracias por intentarlo. Lamento que esto no haya solucionado tu problema. Siendo justos, es una solución temporal a algo que no debería estar sucediendo. Esperemos que se implemente una solución adecuada lo antes posible. EDITAR: Gracias por los comentarios; son muy útiles. El problema era que cada vez que se ejecutaba el script de corrección, purgaba la caché de la máquina virtual (unos 2-3 GB de recursos que la máquina virtual de Cowork necesita para arrancar). Esto obligaba a una nueva descarga completa en cada ciclo de corrección, lo cual es lento y disruptivo. Si el monitor de estado (Watch) también se estaba ejecutando, podía activar ciclos de corrección adicionales automáticamente, agravando el problema. En la v4.5.0 abordamos esto: -KeepCacheMarca en Fix-ClaudeDesktop: omite por completo la purga de caché, por lo que la máquina virtual se reinicia usando sus recursos existentes en lugar de volver a descargar todo. El monitor de estado (Watch) ahora usa esta marca por defecto para sus ciclos de reparación automática, por lo que las reparaciones en segundo plano son rápidas y no destructivas. La purga de caché sigue siendo la opción predeterminada cuando ejecuta Fix manualmente (ya que a veces un caché dañado es el problema real), pero puede omitirla -KeepCachesi desea la ruta más rápida. * El archivo README ahora incluye una nota que explica cuándo utilizar cada modo. Si descargas el archivo zip más reciente, el script Watch ya no borrará tu caché. La corrección manual sigue funcionando por defecto, pero -KeepCachees útil cuando priorizas la velocidad sobre la minuciosidad.

Thank you for your help. I'm using Windows 11 Pro, the latest version of Claude Desktop, and I'm an administrator. I'll try your latest update and let you know. Thank you very much.

Hey folks, we believe this is fixed in 1.1.5749 which was released over the weekend. Please update and let me know below if the issue persists

I'm still receiving the error RPC error -1: failed to ensure virtiofs mount: Plan9 mount failed: bad address.

we are still getting this error with a Windows Claude Cowork user on premium seat for Claude Teams today, @MarshallOfSound

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.