[BUG] Cowork on Windows fails at startup: "sandbox-helper: failed to unmount host share (tried both virtiofs and Plan9): invalid argument"

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?

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 sandbox-helper cannot unmount the host filesystem share, which corrupts the JSON startup handshake and prevents Cowork from launching.

Regular Chat mode works fine — only Cowork is affected.

What I've Tried

• wsl --shutdown followed by relaunch → same error
• Setting "sandbox": { "enabled": false } in ~/.claude/settings.json → no effect (error occurs before config is read)
• Rebooting → same error

Environment

• OS: Windows 11 Pro version 24h2 build 26.100.7840 — edit as needed] (Build [your build number])
• **Claude Desktop version 1.1.2685 (f39a62)
• WSL2: installed and updated (wsl --update)
• Architecture: x64

What Should Happen?

Cowork workspace should start successfully and be ready to accept tasks.

Error Messages/Logs

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

Steps to Reproduce

1. Open Claude Desktop on Windows
2. Go to the Cowork tab
3. Send any message/task
4. Error appears immediately at startup

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Version 1.1.2685 (f39a62)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

• Regular Chat mode works fine, only Cowork is affected
• wsl --shutdown + relaunch does not fix it
• Setting "sandbox": { "enabled": false } in settings.json has no effect
• Related to #24918, #24945, #24962 but different root cause (filesystem sharing fails before network/API)