[BUG] Cowork Windows — sandbox-helper failed to unmount host share (virtiofs and Plan9)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

After the Cowork Windows launch (Feb 10, 2026), attempting to start a Cowork workspace immediately fails with a sandbox VM error before any task execution begins. The VM's file-sharing layer fails to mount, preventing the workspace from initializing.

Error Message

CLI output was not valid JSON. This may indicate an error during startup.
Output: sandbox-helper: failed to unmount host share (tried both virtiofs and Plan9): invalid argument

The error occurs before any prompt is sent — the workspace never reaches a usable state.

Steps to Reproduce

1. Install Claude Desktop for Windows (latest version, downloaded Feb 11, 2026)
2. Open Claude Desktop
3. Switch to the Cowork tab
4. Send any message / attempt to start a task
5. Workspace fails immediately with the above error

Expected Behavior

Cowork workspace should initialize successfully and accept task input.

Actual Behavior

The sandbox VM fails at the host share mount step. Both virtiofs and Plan9 (the two filesystem sharing protocols between host and guest VM) fail with "invalid argument," suggesting the Hyper-V/VM file sharing layer cannot establish a mount point.

Attempted Workarounds

• Restarting Claude Desktop (full quit from system tray + relaunch): no change
• Rebooting machine: no change
• VM bundle delete: N/A — the vm_bundles directory at %APPDATA%\Claude\vm_bundles does not exist. The VM was never successfully created in the first place.

Environment

• OS: Windows 11 Home, Version 25H2, Build 26200 (registry reports "Windows 10 Home" — common after upgrade)
• Claude Desktop: Latest version (downloaded Feb 11, 2026)
• Architecture: x64
• Hyper-V available: Partial — hypervisor detected (WSL2 is active), but full Hyper-V is not available (Home edition limitation)
• Virtual Machine Platform enabled: Yes (InstallState = Enabled)
• Windows Hypervisor Platform enabled: No (Disabled) ← possibly relevant
• VPN/Tailscale running: No
• Antivirus: Windows Defender (Real-Time Protection enabled)

Additional Context

This appears to be a Day 1 Windows launch issue. The error is distinct from the API reachability issues reported in #24918, #24945, and #24962 — this failure occurs earlier in the boot sequence at the filesystem mount layer, before the VM reaches network configuration.

Key finding: The Windows Hypervisor Platform optional feature is disabled, while Virtual Machine Platform is enabled. This may be the root cause — the sandbox VM may require HypervisorPlatform to be explicitly enabled for the virtiofs/Plan9 file sharing to work, even though WSL2 functions without it.

The dual-protocol fallback (virtiofs → Plan9) both failing with "invalid argument" suggests either:

1. The host-side VMBus/Hyper-V file sharing service is not running or not configured — potentially because HypervisorPlatform is disabled
2. A Windows Home edition compatibility issue (Home lacks full Hyper-V management tools)
3. The VM bundle was never successfully created (%APPDATA%\Claude\vm_bundles directory does not exist)

Regular Chat mode works without issues. Only Cowork is affected.