[BUG] Cowork fails with Plan9 share 'd': HcsWaitForOperationResult 0x800703ed after update - Windows

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/43452
2. https://github.com/anthropics/claude-code/issues/43074
3. https://github.com/anthropics/claude-code/issues/43239

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

same because of encrypted drive

I get "failed to add Plan9 share 's': HcsWaitForOperationResult failed with HRESULT 0x80070005: {"Error":-2147024891,"ErrorMessage":""}", and this happened right after update to 1.569.0. I have a system drive S:, but this is a very common mapping. Why should Claude fail on being unable to map a minor drive to the Linux VM?

hello,
do you find a fix ?

No, not yet, but I assume unmounting S: (in my case) would work.

Hey @Jaifroid,
Same I'm actually removing bitlocker.

It's work like a charm.

Environment

• OS: Windows 11 Home
• CPU: AMD
• Claude Desktop: latest version (post-update)
• Install type: MSIX (Microsoft Store)

---

Error

Failed to start Claude's workspace
failed to add Plan9 share 'g': HcsWaitForOperationResult failed with HRESULT 0x800703ed: {"Error":-2147023891,"ErrorMessage":""}
Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace.

Note: the failing share letter is g — not d or h as reported in other threads. This may indicate the VM service is attempting to mount a G: drive specifically, rather than the home directory. Worth investigating whether the share letter is being assigned by drive letter rather than a fixed identifier.

---

Steps already attempted (none resolved the issue)

• Restarted Claude Desktop
• Restarted the computer (multiple times)
• Stopped and restarted the vmcompute service via elevated PowerShell (Stop-Service vmcompute -Force / Start-Service vmcompute)
• Deleted %APPDATA%\Claude\vm_bundles\ and %APPDATA%\Claude\claude-code-vm\ folders
• Granted SYSTEM full permissions to %APPDATA%\Claude via icacls
• Checked and confirmed Hyper-V and Virtual Machine Platform are enabled in Windows Features
• Full uninstall and reinstall of Claude Desktop
• Reinstalled the workspace from within the app

---

Additional context

The error is reproducible 100% of the time. The VM boots (the error occurs at the add_plan9_shares step, not during vm_boot), which is consistent with the pattern described in this issue and #43290.

Happy to provide cowork-service.log or cowork_vm_node.log if helpful - please advise where to share them.

Todavía no se sabe como solucionar?

Todavía no se sabe como solucionar?

well, happily, I didn't pay year subscription, so I'm inclined to find another orchestrating solution

My thread, dormant after the useless AI Bot has been open 4 days, and a promise of an email from a human, remains with ZERO response. Anthropic "support" hides behind a stack of "read these 75 links," while they turn out fantastic LLMs wrapped in bugs. My failure occurred the moment I ran out of tokens and was told to wait for a refresh the next day. Fine with me; I proceeded using Cursor. But the tokens replenished, the token grab resumed, and from then on:

Failed to add Plan9 share 'g': HcsWaitForOperationResult failed with HRESULT 0x800703ed

Tried everything suggested--but unfixable. Somehow, they reached into the bowels of Windows OS and broke something, then walked away, leaving me hanging. Oh, except one thing... they grabbed a chunk of my money in exchange for tokens I can't use.

So I will cling to this thread - hoping a fix comes along.

New release just came out - fixed everyting - suggest you update now.

I am having the same issue.failed to add Plan9 share 'i': HcsWaitForOperationResult failed with HRESULT 0x800703ed: {"Error":-2147023891,"ErrorMessage":""}

• Claude Cowork worked on my machine before (no changes that should affect it)
• Claude Desktop app is installed on C: drive, which is not encrypted. I do have an encrypted drive present in my system, but neither Claude Desktop App nor the main OS are installed on it. "I" from the error message is the drive letter, so i'm guessing it's involved somehow.
• Version as of writing is 1.1617.0 (8d6345), which it tells me is latest. Issue has persisted for several days and a couple of updates...have been waiting patiently in hopes that one of the updates would fix.
• Tried the Anthropic Fin chatbot and it suggested open a Windows Firewall rule and setting WSL networking mode to mirrored. Made both changes & rebooted, still getting the error.
• I have docker installed if that somehow could be relevant.

Follow-on to my previous comment: found the issue is related to the encrypted drive being connected to the system. I physically disconnected the encrypted drive, and Cowork is able to start.

Would still consider this a bug, as mentioned in other comments in this and similar issues, the presence of an encrypted drive in my system should not in any way impact Claude Cowork. If I had to speculate, I'm guessing Cowork is set up to map all drives on the system to its workspace and when this mount fails on an encrypted drive or partition, it prevents the workspace from loading. I'm guessing the intent is to ensure the workspace can access folders in any drive. Suggest the workspace gracefully skip encrypted drives. As a quick fix, suggest offering a config option so we can designate drive letters for drives that Cowork should exclude, which would give users an easy workaround for this specific problem and also enable a path for users who want to prevent Cowork from mounting certain drives even if they're not encrypted (due to sensitive data, etc.).

Same issue — root cause identified: cowork-svc.exe attempts to mount non-existent A:\ drive

Environment:

• OS: Windows 10 Home (19045.6466)
• Claude Desktop: 1.1.8629.0
• Virtualization: HyperVisorPresent=True, VirtualMachinePlatform enabled, Hyper-V not available (Home edition)
• BitLocker: C: drive fully encrypted (TpmPin + RecoveryPassword)

From cowork-service.log, the service explicitly tries to mount A:\ as a Plan9 share:

[VM] Adding Plan9 share via HcsModifyComputeSystem: name=a path=A:\ port=9900 flags=0x10 hasToken=true
[HCS] Config: {"ResourcePath":"VirtualMachine/Devices/Plan9/Shares","RequestType":"Add","Settings":{"Name":"a","AccessName":"a","Path":"A:\\","Port":9900,"Flags":16}}
[VM] Failed to add Plan9 share 'a': HcsWaitForOperationResult failed with HRESULT 0x800703ed

Drive A: does not exist on this system (no floppy, no volume, not in Disk Management). Windows 10 reserves letter A: for legacy floppy and blocks reassignment via subst. Removing the MountedDevices registry entry for \DosDevices\A: had no effect — the service hardcodes A:\ regardless of registry state.

Cowork was working on this machine until ~March 25, 2026. The failure started after a Claude Desktop auto-update.

Suggested fix: In cowork-svc.exe, wrap each Plan9 share addition in error handling that logs a warning and continues rather than terminating when a drive letter is inaccessible or does not exist.

Idk if it's the same issue exactly but I'm having an issue and here's the attached summary from Opus and recommended fix for Anthropic to deploy.

cowork_plan9_bug_report.pdf

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