Cowork fails with Plan9 share 'd' — disk with unknown filesystem (Linux/ext4) causes HcsWaitForOperationResult 0x800703ed after update to v1.569.0.0

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?

After updating Claude Desktop to v1.569.0.0, Cowork fails to start every time with:

failed to add Plan9 share 'd': HcsWaitForOperationResult failed with HRESULT 0x800703ed: {"Error":-2147023891,"ErrorMessage":""}

The system has a physical disk (Intel SSDPE2KE064T8, 6.4TB NVMe) assigned drive letter D: but formatted with a non-Windows filesystem (Linux ext4). Windows reports it as DriveType=3 (Local Fixed Disk) but with FileSystemType=Unknown and Size=0.

In v1.1.7714.0 the same disk was present and add_plan9_shares completed successfully in 5–11ms. In v1.569.0.0 it fails immediately with no recovery — crashing the entire VM startup. The user never granted Claude any explicit access to D:.

What Should Happen?

Claude should gracefully skip or handle drives with unreadable/unknown filesystems (e.g. Linux ext4, btrfs) instead of crashing the entire Cowork VM startup. Ideally, add_plan9_shares should catch the HCS error per-drive, log a warning, and continue with the remaining drives — or provide a config option to exclude specific drive letters.

Error Messages/Logs

From cowork_vm_node.log:

--- BROKEN (v1.569.0.0) ---
2026-04-04 20:14:42 [info] [VM:steps] add_plan9_shares started
2026-04-04 20:14:42 [error] [VM:start] VM boot failed: failed to add Plan9 share 'd': HcsWaitForOperationResult failed with HRESULT 0x800703ed: {"Error":-2147023891,"ErrorMessage":""}
2026-04-04 20:14:42 [error] [VM:start] Startup failed: Error: failed to add Plan9 share 'd': HcsWaitForOperationResult failed with HRESULT 0x800703ed
    at ugn (C:\Program Files\WindowsApps\Claude_1.569.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:1665:4545)
    at async Object.startVM (...)

--- WORKING (v1.1.7714.0) ---
2026-03-31 17:13:48 [info] [VM:steps] add_plan9_shares started
2026-03-31 17:13:48 [info] [VM:steps] add_plan9_shares completed (5ms)
2026-03-31 17:13:57 [info] [VM] Network status: CONNECTED

--- Drive info ---
DeviceID: D:  DriveType: 3 (Local Fixed Disk)  FileSystemType: Unknown  Size: 0
Physical disk: INTEL SSDPE2KE064T8 (6.4TB NVMe, GPT) — formatted with Linux filesystem

Steps to Reproduce

1. Have a Windows system with a physical disk formatted with a non-Windows filesystem (e.g. Linux ext4) assigned a drive letter (e.g. D:). Windows will show it as DriveType=3 but FileSystemType=Unknown with Size=0.
2. Install or update Claude Desktop to v1.569.0.0.
3. Open Claude Desktop and navigate to Cowork tab.
4. Cowork immediately fails with: failed to add Plan9 share 'd': HcsWaitForOperationResult failed with HRESULT 0x800703ed
5. Reinstalling the workspace does not help — the error persists on every launch.

Note: The same setup worked perfectly on v1.1.7714.0.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.1.7714.0 (Claude Desktop)

Claude Code Version

1.569.0.0 (Claude Desktop for Windows)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

System:

• OS: Windows 11 Pro 10.0.26200 (Build 26200.8117)
• Windows Update KB5086672 installed 2026-04-02 (2 days before issue started)
• Drives: C: (NTFS, 1TB), D: (Linux filesystem, 6.4TB NVMe — INTEL SSDPE2KE064T8), Z: (Network drive)

Root cause analysis:
The add_plan9_shares step in v1.569.0.0 appears to call HCS API for ALL logical drives including those with unknown/unreadable filesystems. HCS returns 0x800703ed (ERROR_UNIDENTIFIED_ERROR) when trying to create a Plan9 share for a volume it cannot read.

In v1.1.7714.0 the same drive was present and the step completed successfully — suggesting the old version either skipped unreadable drives or handled the error gracefully.

Workaround applied: Taking Disk 2 offline via diskpart (offline disk) makes D: invisible to Windows/HCS and allows Cowork to start normally. This is disruptive but effective.

Request: Please add per-drive error handling in add_plan9_shares so that a single unreadable drive doesn't block the entire Cowork VM startup. A config option to exclude specific drive letters would also help.