[BUG] Cowork error: "failed to add Plan9 share 'e':"

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 VM fails to start when any fixed drive is BitLocker-locked (or otherwise inaccessible)

Summary

Claude desktop's cowork workspace (the Linux VM) refuses to boot if any fixed drive on the Windows host cannot be attached as a Plan9 share. A single locked or inaccessible volume aborts VM startup entirely, even when the user has no intention of ever using that drive from cowork.

Expected behavior: drives that cannot be shared should be skipped with a warning, and the VM should boot with the remaining shareable drives.

Environment

• OS: Windows 11 Pro 10.0.26200
• Claude desktop version: 1.569.0.0 (Claude_1.569.0.0_x64__pzs8sxrjxfjjc)
• Cowork VM bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
• Regression: worked through 2026-04-04, started failing 2026-04-05 after the 1.569.0.0 update

Repro

1. Have a fixed drive on the Windows host that is BitLocker-locked at Windows login time (in my case, E: — always locked, never auto-unlocked).
2. Launch Claude desktop and open cowork.
3. VM startup fails.

Error shown in UI

Failed to start Claude's workspace
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.

Restarting and reinstalling the workspace do not resolve it — the drive remains locked, so the share keeps failing.

Relevant log excerpt (%APPDATA%\Claude\logs\cowork_vm_node.log)

2026-04-05 07:24:58 [info] [VM:steps] vm_boot completed (289ms)
2026-04-05 07:24:58 [info] [VM:steps] add_plan9_shares started
2026-04-05 07:24:58 [error] [VM:start] VM boot failed: failed to add Plan9 share 'e': HcsWaitForOperationResult failed with HRESULT 0x80310000: {"Error":-2144272384,"ErrorMessage":""}
2026-04-05 07:24:58 [info] Dispatching startup error: failed to add Plan9 share 'e': ...
2026-04-05 07:24:58 [error] [VM:start] Startup failed: Error: failed to add Plan9 share 'e': ...
    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 (...index.js:8021:45736)
2026-04-05 07:24:58 [info] [VM:start] Auto-reinstalling workspace after startup failure

The app also auto-triggers a workspace reinstall in response to this failure, which is wasted work — the bundle isn't broken, a host volume is just unavailable.

Root cause (as observed)

The add_plan9_shares VM-boot step enumerates all fixed drives on the host and attempts to add each one as a Plan9 share into the VM. If any share-add call returns a failing HRESULT from HCS (Host Compute Service), the whole step throws and startVM rejects. The VM never finishes booting.

This makes every fixed drive a hard boot-time dependency, even though cowork only needs drives for projects the user actually opens. Locked BitLocker volumes, disconnected USB drives, and stale mapped network drives can all trigger this.

Requested fix

Skip drives that cannot be shared, with a warning log, and continue VM startup.

Specifically:

• Wrap each addPlan9Share(driveLetter) call in a try/catch.
• On failure, log a warning (e.g. "Skipping drive 'E:' — cannot attach as Plan9 share (HRESULT 0x80310000). Projects on this drive will be unavailable inside the workspace.").
• Continue with the remaining drives. Only fail add_plan9_shares if zero drives attached successfully (and arguably not even then — cowork could still run on VM-local storage).
• If the user later opens a project on a skipped drive, surface a clear error at that point (not during VM boot).

Ideally, consider lazy/on-demand sharing — only attach a drive when a project on it is opened — but the try/catch-and-skip approach is a much smaller change and fixes the regression.

Workarounds (for other users hitting this)

None of these are user-friendly; hence this ticket.

• A. Enable BitLocker auto-unlock on the affected drive: manage-bde -autounlock -enable E: (requires system drive to be BitLocker-protected; changes security posture).
• B. Take the drive offline in Disk Management (Set-Disk -Number N -IsOffline $True) — but this breaks other apps that need the drive.
• C. Unlock the drive manually before launching Claude each session, and disable Claude's auto-start at login.
• D. Patch app.asar to try/catch the share call — breaks on every Claude desktop update.

Additional notes

• Earlier Claude desktop versions (pre-1.569.0.0) did not exhibit this on the same machine, even though E: has always been BitLocker-locked. Either drive enumeration or share-failure handling changed in 1.569.0.0.
• HRESULT 0x80310000 is the generic BitLocker / FVE error code, consistent with attempting to share a locked volume.

What Should Happen?

It should skip this error like it apparently did in previous versions

Error Messages/Logs

Steps to Reproduce

See markdown on What Wrong

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.92

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_