›_ Claude Code Issues
Claude Code Issues / #43074

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

Status Closed — not planned
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 11 comments · opened Apr 3, 2026 · closed May 23, 2026

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"

View original on GitHub ↗

11 Comments

github-actions[bot] · 4 months ago

Found 1 possible duplicate issue:

  1. https://github.com/anthropics/claude-code/issues/43070

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

anoumaru · 4 months ago

I confirm that, I have a BitLocker-encrypted volume

Simbe · 4 months ago

I have the exact same issue with encrypted (bitlocker) and locked volume present. Only way to bypass this currently is to disconnect this drive.

gralewski · 4 months ago

same with bitlocker encrypted volume (and locked)

Jaifroid · 4 months ago

I have this issue with my system drive S: "failed to add Plan9 share 's': HcsWaitForOperationResult failed with HRESULT 0x80070005: {"Error":-2147024891,"ErrorMessage":""}". Happened right after update to 1.569.0, and worked fine before. Windows 11 Pro. Very frustrating.

globalhead · 4 months ago

Same issue with encrypted drive.
Wasted a lot of time on this.
The error message couldn't be more misleading.

cptnbucknasty · 4 months ago

Similar error for me.
Failed to start Claude's workspace
failed to add Plan9 share 'e': HcsWaitForOperationResult failed with HRESULT 0x800703ed
Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace.

Hacking-Notes · 4 months ago

Same issue for me

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

Karboknight · 4 months ago

Same general issue here. VM startup enumerates all drive letters indiscriminately, including unmounted/ghost letters, causing Plan9 share failures.

Environment:

  • Windows 11 Pro (recently upgraded from Home)
  • Claude Desktop v1.1617.0.0 (MSIX install)
  • Hyper-V, Windows Hypervisor Platform, Virtual Machine Platform, and WSL all enabled
  • CoworkVMService running
  • Multiple drives present: C: (system), plus encrypted volumes and other non-standard drives

Summary:
Cowork's VM startup fails at the add_plan9_shares step because it attempts to mount every drive letter the Windows volume database knows about -- including drives that are encrypted, drives that have been renamed, and drive letters that are no longer mounted but still reserved in the volume registry. Any single failure aborts the entire VM startup.

Reproduction (observed in one session):

  1. Launched Cowork with an encrypted F: drive, not mounted. VM boot failed:

failed to add Plan9 share 'f': HcsWaitForOperationResult failed with HRESULT 0x800703ed
(ERROR_UNRECOGNIZED_VOLUME -- Hyper-V's Plan9 server can't mount encrypted volumes.)

  1. Dismounted F: and renamed a separate E: drive to another letter. VM boot failed on the old E: letter:

failed to add Plan9 share 'e': HcsWaitForOperationResult failed with HRESULT 0x80070003
(ERROR_PATH_NOT_FOUND -- the VM config was cached from a previous session and refused to re-enumerate. "Skipping auto-reinstall (already attempted once)" appeared in the log.)

  1. Manually deleted vm_bundles\claudevm.bundle and rebooted to force a clean rebuild. On the next launch, VM startup failed at the Configuring Windows VM service step with "VM service not running. The service failed to start." (likely stale service state after manual cleanup).
  2. After rebooting and letting Claude rebuild the bundle from scratch, the VM now fails on a K: drive -- which is not actually mounted. K: is a ghost letter reserved by the Windows volume database from the previously-renamed F: drive. Get-PSDrive does not show K: as an active drive, but Cowork still tries to Plan9-share it.

Root cause (as best I can tell from the outside):
Cowork's drive enumeration at VM startup appears to pull from the raw Windows volume registry (or equivalent low-level source) rather than filtering to currently mounted, ready, filesystem-backed drives. This causes three distinct failure modes:

  • Encrypted volumes (VeraCrypt, BitLocker-to-Go, Cryptomator, etc.) crash VM boot with ERROR_UNRECOGNIZED_VOLUME.
  • Drive letters that have been renamed or removed but remain in the volume database crash VM boot with ERROR_PATH_NOT_FOUND.
  • Any single drive failure aborts the entire VM startup -- there's no graceful skip-and-continue.
  • The VM config is cached aggressively and "Skipping auto-reinstall (already attempted once)" prevents the app from recovering without manual bundle deletion.

Suggested fixes:

  1. Enumerate shareable drives via Get-PSDrive -PSProvider FileSystem semantics (or equivalent: only drives with IsReady = true, a recognized filesystem, and an accessible root). Skip encrypted, network, removable, and ghost-letter drives by default.
  2. On Plan9 share failure for any individual drive, log a warning and continue rather than aborting the entire VM startup.
  3. Expose a user-facing setting to explicitly choose which drives/folders are shared into the VM, rather than auto-sharing everything.
  4. Re-enumerate the drive list on every VM start rather than caching. If caching is needed for performance, invalidate the cache whenever the host drive topology changes.
  5. Surface the underlying error in the UI rather than the generic "VM service not running" message, which sent me down the wrong troubleshooting path for an hour (NAT, WinNAT, VPN, TEMP directory) before the log revealed it was actually a Plan9 mount failure on an unmounted drive letter.

Log excerpts (latest three failures):

2026-04-11 18:50:31 [info] [VM] Loading vmClient (TypeScript) module...
2026-04-11 18:50:31 [info] [VM] Module loaded successfully
2026-04-11 18:50:32 [info] [KernelBugMonitor] State reset
2026-04-11 18:50:32 [info] [VM:start] Beginning startup, bundlePath=C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
2026-04-11 18:50:32 [info] [VM:start] Bundle version: <redacted>
2026-04-11 18:50:32 [info] [VM:start] VM instance ID: <redacted>
2026-04-11 18:50:32 [info] [VM:steps] download_and_sdk_prepare started
2026-04-11 18:50:38 [info] [VM:steps] download_and_sdk_prepare completed (6326ms)
2026-04-11 18:50:38 [info] [VM:steps] load_swift_api started
2026-04-11 18:50:38 [info] [VM:steps] load_swift_api completed (1ms)
2026-04-11 18:50:38 [info] [Callbacks] Initializing VM event callbacks...
2026-04-11 18:50:38 [info] [Callbacks] VM event callbacks initialized
2026-04-11 18:50:38 [info] [VM:start] Copying smol-bin.x64.vhdx to bundle: C:\Program Files\WindowsApps\Claude_1.1617.0.0_x64__pzs8sxrjxfjjc\app\resources\smol-bin.x64.vhdx -> C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\smol-bin.vhdx
2026-04-11 18:50:38 [info] [VM:start] smol-bin.x64.vhdx copied successfully
2026-04-11 18:50:38 [info] [VM:start] Configuring Windows VM service...
2026-04-11 18:50:38 [info] [VM:start] Windows VM service configured
2026-04-11 18:50:38 [info] [VM:steps] create_network started
2026-04-11 18:50:38 [info] [VM:steps] create_network completed (1ms)
2026-04-11 18:50:38 [info] [VM:steps] create_vm_config started
2026-04-11 18:50:38 [info] [VM:steps] create_vm_config completed (79ms)
2026-04-11 18:50:39 [info] [VM:steps] vm_boot started
2026-04-11 18:50:39 [info] [VM:steps] vm_boot completed (199ms)
2026-04-11 18:50:39 [info] [VM:steps] add_plan9_shares started
2026-04-11 18:50:39 [error] [VM:start] VM boot failed: failed to add Plan9 share 'f': HcsWaitForOperationResult failed with HRESULT 0x800703ed: {"Error":-2147023891,"ErrorMessage":""}
2026-04-11 18:50:39 [info] Dispatching startup error: failed to add Plan9 share 'f': HcsWaitForOperationResult failed with HRESULT 0x800703ed: {"Error":-2147023891,"ErrorMessage":""}
2026-04-11 18:50:39 [error] [VM:start] Startup failed: Error: failed to add Plan9 share 'f': HcsWaitForOperationResult failed with HRESULT 0x800703ed: {"Error":-2147023891,"ErrorMessage":""}
at A1n (C:\Program Files\WindowsApps\Claude_1.1617.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:1759:4749)
at async Object.startVM (C:\Program Files\WindowsApps\Claude_1.1617.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:6677:6906)
at async C:\Program Files\WindowsApps\Claude_1.1617.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:8:344292
at async Session.<anonymous> (node:electron/js2c/browser_init:2:116330)
2026-04-11 18:50:39 [info] [VM:start] Skipping auto-reinstall (already attempted once)

2026-04-11 19:11:31 [info] [VM:steps] add_plan9_shares started
2026-04-11 19:11:31 [error] [VM:start] VM boot failed: failed to add Plan9 share 'e': HcsWaitForOperationResult failed with HRESULT 0x80070003: {"Error":-2147024893,"ErrorMessage":""}
2026-04-11 19:11:31 [info] Dispatching startup error: failed to add Plan9 share 'e': HcsWaitForOperationResult failed with HRESULT 0x80070003: {"Error":-2147024893,"ErrorMessage":""}
2026-04-11 19:11:31 [error] [VM:start] Startup failed: Error: failed to add Plan9 share 'e': HcsWaitForOperationResult failed with HRESULT 0x80070003: {"Error":-2147024893,"ErrorMessage":""}
at A1n (C:\Program Files\WindowsApps\Claude_1.1617.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:1759:4749)
at async Object.startVM (C:\Program Files\WindowsApps\Claude_1.1617.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:6677:6906)
2026-04-11 19:11:31 [info] [VM:start] Skipping auto-reinstall (already attempted once)

2026-04-11 19:20:41 [info] [VM:start] Copying smol-bin.x64.vhdx to bundle: C:\Program Files\WindowsApps\Claude_1.1617.0.0_x64__pzs8sxrjxfjjc\app\resources\smol-bin.x64.vhdx -> C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\smol-bin.vhdx
2026-04-11 19:20:41 [info] [VM:start] smol-bin.x64.vhdx copied successfully
2026-04-11 19:20:41 [info] [VM:start] Configuring Windows VM service...
2026-04-11 19:20:46 [error] [VM:start] Startup failed: Error: VM service not running. The service failed to start.
at rot (C:\Program Files\WindowsApps\Claude_1.1617.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:275:28688)
at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
at async Object.configure (C:\Program Files\WindowsApps\Claude_1.1617.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:275:33518)
at async A1n (C:\Program Files\WindowsApps\Claude_1.1617.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:1759:3954)
at async Object.startVM (C:\Program Files\WindowsApps\Claude_1.1617.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:6677:6906)

Related existing issues: #25419 (sandbox-helper host share mount failures), #25206 (VM starts then crashes), #25136 (yukonSilver unsupported), #27010 (WinNAT not persisting). This appears to be a distinct but related class of issue in the same Plan9/drive-sharing subsystem.

github-actions[bot] · 3 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

github-actions[bot] · 1 month ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Windows & WSL problems

Browse all Claude Code issue topics →