claude-code - 💡(How to fix) Fix CoWork fails to start on Windows 11 Pro - Plan9 share Z: conflict with EFI System Partition [2 comments, 3 participants]

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 every time it is launched. The workspace never initializes and the vm_bundles directory remains empty after every reinstall attempt. Root cause: CoWork is hardcoded to use drive letter Z: for its Plan9 share, which conflicts with machines that already have Z: assigned - in this case, to the EFI System Partition.

After removing the Z: assignment via diskpart, the error code changed from 0x80070005 (Access Denied) to 0x80070003 (Path Not Found) - meaning the letter conflict was resolved but the workspace bundle still never downloaded. The vm_bundles directory remained empty after every "Reinstall Workspace" attempt. Additionally, the EFI partition re-grabs Z: after every reboot, so the conflict returns unless manually cleared each session.

What Should Happen?

CoWork should start working

Error Messages/Logs

Error Messages
Error 1 - Access Denied (most frequent, appears on every launch)
Failed to start Claude's workspace
failed to add Plan9 share 'z': HcsWaitForOperationResult failed with HRESULT 0x80070005: {"Error":-2147024891,"ErrorMessage":""}

Error 2 - Path Not Found (appeared after Z: drive letter was manually freed)
Failed to start Claude's workspace
failed to add Plan9 share 'z': HcsWaitForOperationResult failed with HRESULT 0x80070003: {"Error":-2147024893,"ErrorMessage":""}

Steps to Reproduce

Steps to Reproduce

Have a Windows 11 machine where Z: is assigned to any partition (especially EFI/System) Install Claude Desktop and attempt to launch CoWork CoWork fails immediately with HRESULT 0x80070005

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Claude Desktop v1.569.0.0.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

PowerShell

Additional Information

Troubleshooting Steps Already Completed

Full uninstall via Settings > Apps Manually deleted %AppData%\Roaming\Claude Manually deleted %LocalAppData%\Packages\Claude_pzs8sxrjxfjjc Clean reinstall of latest Claude Desktop Verified Hyper-V is enabled (State: Enabled) Verified vmcompute and vmms services are running Verified user is in Hyper-V Administrators group Manually created vm_bundles directory and granted SYSTEM full control Removed Z: drive letter from EFI partition via diskpart and mountvol Z: /D Used "Reinstall Workspace" option in Claude Desktop after freeing Z: Checked Windows System Event Log for Hyper-V errors - only informational networking events, no errors

Ruled Out

Z: mapped as a network drive Z: mapped as a subst virtual drive Hyper-V not enabled Hyper-V services not running User missing from Hyper-V Administrators group Wrong permissions on vm_bundles

Current State CoWork still fails after all of the above. The vm_bundles directory stays empty and no workspace bundle is ever created or downloaded. The only log file present (chrome-native-host.log) contains only browser bridge activity - nothing related to the VM or workspace initialization. C:\Users\Doron\AppData\Local\Claude
├── Logs
│ └── chrome-native-host.log ← browser bridge only, no CoWork logs └── vm_bundles\ ← empty, nothing ever written here

Expected Behavior

CoWork should dynamically find an available drive letter rather than hardcoding Z: If the workspace bundle download fails, the app should surface a specific error "Reinstall Workspace" should log what it is doing and whether the download succeeded or failed HCS error codes should map to plain-language messages with specific remediation steps

Suggested Fix CoWork should not be hardcoded to Z:. It should either:

Scan for an available drive letter at startup, or Allow the user to configure the drive letter used for the Plan9 share

This is a realistic conflict on any machine with many drives, storage devices, network shares, or certain OEM configurations that assign letters to system partitions.