[BUG] Cowork Windows: sandbox-helper fails to unmount host share, VM service won't start (Win 11 Pro)

[rickardovidal]

Bug Description

Cowork on Windows fails to start with two distinct errors that occur in sequence:

1. Initial error — CLI output is not valid JSON due to sandbox-helper debug output contaminating stdout:

CLI output was not valid JSON. This may indicate an error during startup.
Output: sandbox-helper: failed to unmount host share (virtiofs at /mnt/.virtiofs-root: invalid argument, plan9 at /mnt/.virtiofs-root/shared: invalid argument)

2. After restarting Claude Desktop — The workspace fails with:

VM service not running. The service failed to start.

Steps to Reproduce

1. Open Claude Desktop on Windows 11 Pro
2. Try to use Cowork
3. First attempt shows the sandbox-helper: failed to unmount host share error
4. Restarting Claude Desktop changes the error to "VM service not running. The service failed to start."
5. Cycle repeats indefinitely

Troubleshooting Already Attempted

• Deleted vm_bundles/claudevm.bundle (rootfs.vhdx, sessiondata.vhdx, smol-bin.vhdx) to force a fresh re-download — same errors after rebuild
• Restarted Hyper-V services (vmms, HvHost) — both confirmed running, error persists
• Terminated all claude, cowork-svc, vmwp processes and restarted — no improvement
• Confirmed Hyper-V is fully enabled and functional (vmms: Running/Automatic, HvHost: Running/Manual)

Environment

Detail	Value
OS	Microsoft Windows 11 Pro 10.0.26200 (Build 26200)
Architecture	AMD64
Claude Desktop version	1.1.2998.0 (MSIX/AppX package)
Claude Code CLI version	2.1.39
Hyper-V vmms service	Running (Automatic)
Hyper-V HvHost service	Running (Manual)
Installation type	Microsoft Store / AppX (Claude_pzs8sxrjxfjjc)

Expected Behavior

Cowork should start the VM workspace successfully without sandbox-helper unmount errors.

Actual Behavior

The sandbox-helper fails to unmount host shares using both virtiofs and plan9 protocols with "invalid argument", which corrupts the JSON output stream and prevents the workspace from initializing. After restart, the VM service fails to start entirely.

Possibly Related Issues

• [BUG] [Cowork] Windows: VM starts successfully but crashes within 5 minutes, service unrecoverable (Win 11 Pro, Hyper-V) #25206 — VM starts but crashes within 5 minutes, service unrecoverable (Win 11 Pro)
• [BUG] [Cowork] Windows: sessiondata.vhdx not created + network diagnostics uses macOS commands #24974 — sessiondata.vhdx not created on Windows
• [BUG] Cowork VM boots successfully but API is unreachable on Windows #24945 — VM boots but API unreachable on Windows
• [BUG] Sandbox debug output contaminating JSON stream in Codespaces #12056 — Sandbox debug output contaminating JSON stream

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Cowork on Windows fails at startup: "sandbox-helper: failed to unmount host share (tried both virtiofs and Plan9): invalid argument" #25096
2. [BUG] Cowork Windows — sandbox-helper failed to unmount host share (virtiofs and Plan9) #25132
3. [BUG] CoWork for Windows #25377

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

[ErosEleutherios]

Confirming this issue on Windows 10 with v1.1.2998.0.

Additional related errors I'm experiencing:

1. sdk-daemon not connected - occurs after 1-5 successful Cowork requests
2. failed to write length: An operation was attempted on something that is not a socket
3. Same virtiofs/plan9 mounting failures when attempting folder selection

Failure pattern:

• Fresh install/restart → Cowork works briefly (1-5 requests)
• Then fails with one of the above errors
• Requires restart/reinstall for temporary fix
• Cycle repeats indefinitely

Regression:
v1.1.2685.0 worked reliably in temporary workspace mode (despite greyed-out folder UI). v1.1.2998.0 is significantly worse - unstable even without folder selection.

Impact:
Consuming significant usage limits on failed attempts. Cowork essentially unusable for any real work.

+1 for urgent fix or rollback to previous version.

[casperse]

Already reported, nice to see the updates coming out for windows daily :-)
I can see this was also on the Mac version in the beginning.
Hope to get it resolved no matter what I do I cant use Cowork any more.

[aaaageeeh]

Already reported, nice to see the updates coming out for windows daily :-) I can see this was also on the Mac version in the beginning. Hope to get it resolved no matter what I do I cant use Cowork any more.

Exact the same here

[jbfranks]

I was able to get around this by going to File -> Exit then restarting Claude Windows app. Then it worked for me.

[afnan007]

yes, exiting it from the taskbar tray menu and restarting resolves it.

[ErosEleutherios]

I'm experiencing both this issue and an additional VPN-related problem:
Issue 1 - Cowork hang/crash (this issue):

Can't use File → Exit, must kill via Task Manager
Restart works but is temperamental (inconsistent success rate)
Still on latest version with daily updates

The simple exit/restart workaround mentioned by @jbfranks and @afnan007 doesn't work reliably for me - the app won't exit gracefully when Cowork is in this failed state.

Issue 2 - VPN triggers "no connection" error (separate but related):

When VPN is active, Cowork fails with a connection error due to routing table conflicts. I've developed a PowerShell repair script that fixes this by:

Repairing routing table conflicts caused by VPN interaction
Restarting the CoworkVMService
More reliable than manual restart in my testing

Repair tool available here: https://github.com/AlbertSteptoe/Cowork-repair-tool

The temperamental restart behavior suggests there may be a race condition or timing issue during VM service recovery.

[lazmo88]

+1 exactly the same problem here with Win11 Pro.