[BUG] Cowork workspace fails to start when encrypted/inaccessible drives present (Plan9 share HRESULT 0x80310000)

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?

Cowork workspace fails to start because the VM startup tries to add a Plan9 share for all Windows drive letters, including drives that are encrypted and inaccessible. When it encounters such a drive, the HCS call fails and the entire workspace startup aborts instead of gracefully skipping the inaccessible drive.

Error message:

Failed to start Claude's workspace
failed to add Plan9 share 'e': HcsWaitForOperationResult failed with HRESULT 0x80310000: {"Error":-2144272384,"ErrorMessage":""}

Drive E: is an encrypted volume that cannot be exposed to the Plan9 filesystem. The workspace should skip it and continue mounting other drives.

Related: #43070 reports the same HRESULT 0x80310000 error on drive x, likely the same root cause (inaccessible drive).

What Should Happen?

The add_plan9_shares step should gracefully skip drives that fail to mount rather than aborting the entire VM startup. A single inaccessible drive should not prevent Cowork from starting. Suggested behavior:

1. Try to add Plan9 share for each drive
2. If a share fails, log a warning and continue to the next drive
3. Only abort if all shares fail or if a critical drive (like C:) can't be mounted

Error Messages/Logs

failed to add Plan9 share 'e': HcsWaitForOperationResult failed with HRESULT 0x80310000: {"Error":-2144272384,"ErrorMessage":""}
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.

Steps to Reproduce

1. Have a Windows machine with an encrypted or otherwise inaccessible drive (e.g., BitLocker-encrypted volume, disconnected removable drive, or certain network-mapped drives)
2. Open Claude Desktop on Windows
3. Attempt to start a Cowork workspace
4. Workspace fails at the add_plan9_shares step with HRESULT 0x80310000

Claude Model

Opus

Is this a regression?

Not sure (Cowork may have worked before the encrypted drive was present)

Last Working Version

_No response_

Claude Code Version

Latest Claude Desktop (Windows)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• OS: Windows 11 Pro 10.0.26220 (Build 26220)
• WSL: WSL2 with Ubuntu default, reports healthy via wsl --status
• Drive E: Encrypted volume, inaccessible to standard filesystem APIs
• Reboot, wsl --shutdown, and Restart-Service vmcompute do not resolve the issue since the drive remains encrypted/inaccessible
• No user-configurable setting exists in Claude Desktop config to exclude specific drives from Plan9 sharing

Workaround for others: You can temporarily hide the problematic drive from Windows enumeration via registry (reversible, run as Administrator):

# Hide drive E: (bitmask: A=1, B=2, C=4, D=8, E=16, etc.)
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" -Name "NoDrives" -Value 16 -Type DWord
# Then restart Claude or run: wsl --shutdown

# To undo:
Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" -Name "NoDrives"