Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Cowork fails with HRESULT 0x80310000 when second physical drive is BitLocker-locked — hard failure with no fallback [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#44992•Fetched 2026-04-09 08:15:55
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
Khufu001Khufu001
Participants
github-actions[bot]github-actions[bot]Khufu001Khufu001
Timeline (top)
labeled ×4commented ×1cross-referenced ×1

Error Message

Error Messages/Logs

Error displayed in Claude Desktop: failed to add Plan9 share 'd': HcsWaitForOperationResult failed with HRESULT 0x80310000: {"Error":-2144272384,"ErrorMessage":""} 2026-04-07 22:01:19 [error] [VM:start] VM boot failed: failed to add Plan9 share 'd': HcsWaitForOperationResult failed with HRESULT 0x80310000: {"Error":-2144272384,"ErrorMessage":""}

  • Related issues with same error but root cause not previously identified: #43452, #43070, #43482

Root Cause

Cowork fails to start with HRESULT 0x80310000 (FVE_E_LOCKED_VOLUME) because it attempts to add a Plan9 share for every lettered drive on the system, including drives that are BitLocker-locked and intentionally inaccessible. There is no graceful fallback — the entire workspace fails hard.

Code Example

**Error displayed in Claude Desktop:**

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


**From cowork_vm_node.log:**

2026-04-07 22:01:18 [info] [VM:steps] add_plan9_shares started
2026-04-07 22:01:19 [error] [VM:start] VM boot failed: failed to add Plan9 share 'd': HcsWaitForOperationResult failed with HRESULT 0x80310000: {"Error":-2144272384,"ErrorMessage":""}
2026-04-07 22:01:19 [info] [VM:start] Skipping auto-reinstall (already attempted once)


**Root cause confirmed via manage-bde:**

manage-bde -status D:

Lock Status:       Locked
Protection Status: Unknown
Encryption Method: XTS-AES 256


HRESULT 0x80310000 = FVE_E_LOCKED_VOLUME ("This drive is locked by BitLocker Drive Encryption.")
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

Cowork fails to start with HRESULT 0x80310000 (FVE_E_LOCKED_VOLUME) because it attempts to add a Plan9 share for every lettered drive on the system, including drives that are BitLocker-locked and intentionally inaccessible. There is no graceful fallback — the entire workspace fails hard.

In my case, I have two physical drives:

  • C: — my personal drive (Windows installation, BitLocker unlocked)
  • D: — another windows installation drive (BitLocker-locked, inaccessible by design)

Cowork attempts to share D: into the VM, hits the BitLocker lock, and aborts entirely. Reinstalling the workspace does not resolve the issue because the root cause is the drive enumeration logic, not the bundle.

This is also a privacy and security concern: Cowork should not be trying to access another drive without permission and it should be able to function without that access.

What Should Happen?

Cowork should either:

  • Only share drives the user explicitly selects or consents to, OR
  • Gracefully skip drives that are inaccessible rather than failing the entire workspace startup

Error Messages/Logs

**Error displayed in Claude Desktop:**

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


**From cowork_vm_node.log:**

2026-04-07 22:01:18 [info] [VM:steps] add_plan9_shares started
2026-04-07 22:01:19 [error] [VM:start] VM boot failed: failed to add Plan9 share 'd': HcsWaitForOperationResult failed with HRESULT 0x80310000: {"Error":-2144272384,"ErrorMessage":""}
2026-04-07 22:01:19 [info] [VM:start] Skipping auto-reinstall (already attempted once)


**Root cause confirmed via manage-bde:**

manage-bde -status D:

Lock Status:       Locked
Protection Status: Unknown
Encryption Method: XTS-AES 256


HRESULT 0x80310000 = FVE_E_LOCKED_VOLUME ("This drive is locked by BitLocker Drive Encryption.")

Steps to Reproduce

  1. Have a Windows machine with two physical drives, both with BitLocker enabled
  2. Have the second drive (D:) locked/inaccessible
  3. Install Claude Desktop and open the Cowork tab
  4. Workspace fails immediately at the add_plan9_shares step

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

unknown

Claude Code Version

v1.1062.0.0 (MSIX)

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

  • C: drive BitLocker status: Unlocked, Protection On, XTS-AES 128, 100% encrypted
  • D: drive BitLocker status: Locked, XTS-AES 256
  • Attempted fixes that did not resolve the issue: restarting Claude, restarting computer, reinstalling workspace, running icacls to grant SYSTEM full permissions on the Claude MSIX package folder
  • Related issues with same error but root cause not previously identified: #43452, #43070, #43482

extent analysis

TL;DR

Modify the drive enumeration logic in Cowork to either only share user-selected drives or gracefully skip inaccessible drives.

Guidance

  • Identify the drives that are BitLocker-locked and inaccessible, and modify the Cowork configuration to exclude these drives from the Plan9 share.
  • Implement a try-except block in the add_plan9_shares step to catch the HRESULT 0x80310000 error and skip the drive if it is locked.
  • Consider adding a user consent mechanism to allow users to select which drives to share, enhancing privacy and security.
  • Review related issues (#43452, #43070, #43482) to ensure the fix addresses the root cause and prevents similar errors.

Example

# Pseudocode example of modified add_plan9_shares step
foreach drive in drives:
    try:
        add_plan9_share(drive)
    except HRESULT 0x80310000:
        # Drive is locked, skip it
        print(f"Skipping drive {drive} due to BitLocker lock")
        continue

Notes

The fix may require changes to the Cowork codebase and potentially the Claude Desktop application. It is essential to test the modified code thoroughly to ensure it works as expected and does not introduce new issues.

Recommendation

Apply a workaround by modifying the drive enumeration logic to skip inaccessible drives, as upgrading to a fixed version is not currently available. This approach will allow Cowork to function without attempting to access locked drives, addressing the privacy and security concerns.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#installation#embedding generation#cache error#pipeline error#runtime error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Cowork fails with HRESULT 0x80310000 when second physical drive is BitLocker-locked — hard failure with no fallback [1 comments, 2 participants]