[BUG + WORKAROUND] Cowork Plan9 share hard-fails on VeraCrypt-encrypted partitions (RAW/unformatted drives) — v1.569.0 regression

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 to Claude Desktop v1.569.0, Cowork fails to start because the new version enumerates all drive letters and attempts to create Plan9 shares for each one. On systems with VeraCrypt whole-partition encryption, one drive letter is assigned to a physical partition that Windows sees as RAW/unformatted (VeraCrypt encrypts at the block level, then mounts the decrypted contents to a separate virtual drive letter). When HCS attempts to create a Plan9 share to this RAW partition, it fails with E_INVALIDARG or 0x800703ed because there is no valid filesystem to share.

The failure is fatal — Cowork does not skip the failed share or attempt to continue with remaining drives. The VM boots successfully but crashes at the add_plan9_shares step every time.

The following did not resolve the issue: restarting Claude, restarting the computer, reinstalling the workspace, full uninstall/reinstall, granting SYSTEM permissions on the MSIX AppData path, or removing NTFS compression from the bundle directory.

Confirmed workaround: Removing the drive letter from the encrypted partition in Windows Disk Management (VeraCrypt can still mount by device path via "Select Device"). After removing the letter and rebooting, Cowork starts normally.

What Should Happen?

Cowork should handle Plan9 share failures gracefully. If a share fails for a particular drive letter (RAW filesystem, inaccessible volume, etc.), it should log a warning and continue mounting the remaining shares. Only the user's home directory and working directories are essential — an inaccessible secondary drive should not prevent the entire VM from starting.

Ideally, Cowork should also filter drive types before attempting shares, skipping drives with RAW/unrecognized filesystems or drives that return errors when queried for volume information.

Error Messages/Logs

First boot after update (0x80070057 = E_INVALIDARG):

2026-04-05 20:46:18 [info] [VM:steps] add_plan9_shares started
2026-04-05 20:46:18 [error] [VM:start] VM boot failed: failed to add Plan9 share 'g': HcsWaitForOperationResult failed with HRESULT 0x80070057: {"Error":-2147024809,"ErrorMessage":""}

Subsequent attempts (0x800703ed):

2026-04-06 12:49:21 [info] [VM:steps] add_plan9_shares started
2026-04-06 12:49:21 [error] [VM:start] VM boot failed: failed to add Plan9 share 'g': HcsWaitForOperationResult failed with HRESULT 0x800703ed: {"Error":-2147023891,"ErrorMessage":""}

Last successful boot before the update:

2026-04-01 14:45:38 [info] [VM:steps] add_plan9_shares started
2026-04-01 14:45:38 [info] [VM:steps] add_plan9_shares completed (6ms)
2026-04-01 14:45:50 [info] [VM:start] Startup complete, total time: 13627ms

Update download that introduced the failure:

2026-04-02 20:45:53 [info] [warm] Fetching VM hash for version 1.569.0
2026-04-02 20:45:53 [info] [warm] VM hash for version 1.569.0: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d

Steps to Reproduce

1. Have a physical internal drive with VeraCrypt whole-partition encryption. Windows assigns this partition a drive letter (e.g., G:) but sees it as RAW/unformatted. VeraCrypt mounts the decrypted contents to a separate virtual drive letter (e.g., J:).
2. Update Claude Desktop to v1.569.0 or later (MSIX / Microsoft Store install).
3. Launch Claude Desktop and open the Cowork tab.
4. Cowork fails immediately at the add_plan9_shares step with the Plan9 share error referencing the encrypted partition's drive letter.
5. All standard recovery steps fail (restart Claude, restart computer, reinstall workspace, full reinstall).
6. To fix: Open Disk Management → right-click the RAW partition → Change Drive Letter and Paths → Remove the drive letter → Reboot → Cowork starts successfully. VeraCrypt can still mount the device using "Select Device" instead of a drive letter.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.1.5368.0

Claude Code Version

Claude Desktop 1.569.0 (MSIX / Microsoft Store)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• The drive letter in the error ('g' in this case) corresponds to the VeraCrypt-encrypted partition's Windows drive letter. Other users reporting similar Plan9 errors with different drive letters (e.g., 'd') may have analogous inaccessible drives.
• The VM boots successfully — vm_boot completed (251ms) — the failure occurs only at add_plan9_shares.
• The initial error code is 0x80070057 (E_INVALIDARG), which later shifts to 0x800703ed on repeated attempts within the same session.
• Prior to v1.569.0, Plan9 share mounting either did not enumerate all drive letters or handled failures gracefully (the add_plan9_shares step was not logged in earlier versions, and worked without issue when it began appearing in logs around March 21).
• This likely affects any system with a drive letter assigned to a volume that has no Windows-readable filesystem — not just VeraCrypt. BitLocker-locked volumes, hardware-encrypted drives awaiting unlock, or disconnected virtual drives could potentially trigger the same failure.
• Related issues:
• #43482
• #43290
• #43452