Cowork VM fails to start with Plan9 share error on systems with many drive letters (Windows)

Resolved 💬 2 comments Opened Apr 13, 2026 by victorchavezudg Closed May 23, 2026

Bug Description

Cowork workspace fails to start on Windows systems with multiple drive letters. The VM tries to mount all drive letters from C: through one letter past the last existing drive via Plan9 shares, and crashes when it encounters a non-existent drive letter.

Error Message

No se pudo iniciar el espacio de trabajo de Claude
failed to add Plan9 share 'i': HcsWaitForOperationResult failed with HRESULT 0x80070003

The share letter varies depending on which drive letter doesn't exist.

Environment

  • OS: Windows 10 Pro 10.0.19045
  • Claude Desktop: Latest (April 2026)
  • Drive configuration: 7 fixed NTFS drives (C: through I:)
  • Hyper-V and Containers features enabled

Steps to Reproduce

  1. Have a Windows system with multiple fixed drive letters (e.g., C: through I:)
  2. Open Claude Desktop -> Cowork tab
  3. Cowork VM attempts to start and fails with Plan9 share error

Root Cause Analysis

From Hyper-V Compute Operational logs (Get-WinEvent -LogName 'Microsoft-Windows-Hyper-V-Compute-Operational'):

  1. Cowork VM (cowork-vm-*) sequentially adds Plan9 shares for each drive letter starting from C:
  2. Each share maps a host drive letter (e.g., {"Name":"c","Path":"C:\\","Port":9902})
  3. All existing drives (C: through I:) mount successfully (result 0x00000000)
  4. The VM then attempts to mount the next sequential letter J:\ which does not exist
  5. The async notification returns 0x80070003 (ERROR_PATH_NOT_FOUND)
  6. The VM terminates with 0xC0370103

Key evidence: When a virtual J: drive was created using subst J: C:\path, the error moved to K:\. This confirms Cowork always tries one letter beyond the last existing drive (off-by-one bug).

Additional Context

The issue was compounded by a previously connected NAS disk that left phantom drive entries in the registry (HKLM:\SYSTEM\MountedDevices) for letters N: through W:. These phantom entries may have contributed to the drive enumeration issue.

Workaround

  1. Delete %APPDATA%\Claude\vm_bundles\claudevm.bundle (forces full VM reinstall)
  2. Clean phantom drive entries from HKLM:\SYSTEM\MountedDevices using PowerShell:

``powershell
Remove-ItemProperty -Path 'HKLM:\SYSTEM\MountedDevices' -Name '\DosDevices\X:' # for each phantom letter
``

  1. Restart PC
  2. Reopen Claude Desktop - Cowork will download and reinstall the VM
  3. Re-select project folders when prompted

Suggested Fix

The drive enumeration logic should only attempt to mount drives that actually exist and are accessible, rather than iterating past the last valid drive letter. Consider using [System.IO.DriveInfo]::GetDrives() and only mounting drives where IsReady == true.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗