[BUG] CoworkVMService attempts to mount nonexistent drive letter (S:) as Plan9 share — persists after full reinstall

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?

CoworkVMService fails to start with the error:
failed to add drive share S: share path not found: S:\
There is no S: drive on the host system. No physical disk, no mapped network drive, no subst virtual drive, no entry visible in Disk Management. The drive letter S: does not exist anywhere on the machine.
This means the Cowork VM's drive enumeration logic is detecting a phantom drive letter that has no corresponding host volume, then treating the mount failure as fatal.
Key differentiator from related issues
This is not the same as #44486 (external USB drive fails to mount) or #29583/#24927 (non-home-directory drives rejected). Those involve real drives that exist on the host but can't be shared. In this case, the drive letter does not exist at all — the enumeration itself is returning a false positive.

What Should Happen?

The drive enumeration should not pick up drive letters that have no backing volume/partition.
Even if a phantom letter is enumerated, failure to share it should be a logged warning, not a fatal crash.

Error Messages/Logs

Failed to start Claude's workspace
failed to add drive share S: share path not found: S:\
Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace.

Steps to Reproduce

Steps to Reproduce

Clean Windows 11 Enterprise 25H2 machine with no S: drive assigned anywhere
Install Claude Desktop (latest version, Windows packaged app)
Launch Claude → Start Cowork
CoworkVMService fails with failed to add drive share S: share path not found: S:\

Remediation steps already attempted (all failed)

Full uninstall of Claude Desktop
Deleted all contents of %AppData%\Claude\ and %LocalAppData%\Claude\
Cleaned Claude-related Windows Registry entries
Reinstalled Claude Desktop from scratch
Verified via subst command that S: is not a virtual drive (subst S: rejected — no such drive)
Verified via Disk Management that no volume is assigned letter S:
Confirmed no network drive mapped to S: (net use shows no S: mapping)

The error persists after full wipe and reinstall, indicating the phantom drive reference is not coming from Claude's own configuration or persisted state.
Possible Root Cause
The drive enumeration likely uses a Windows API (e.g., GetLogicalDrives(), Win32_LogicalDisk via WMI, or HKLM\SYSTEM\MountedDevices) that returns stale or phantom drive letters. Potential sources:

A lingering entry in HKLM\SYSTEM\MountedDevices from previously attached hardware
A WMI provider returning a cached/stale drive letter
A third-party driver or storage filter registering a drive letter without a mounted volume
The HCS compute system configuration caching drive mappings at the system level

Since the error survives a full Claude uninstall/reinstall, the source is clearly something the enumeration reads from the OS, not from Claude's own config.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

this worked in a previous version (prior to the change that mounts all fixed drives into the VM).

Claude Code Version

Version 1.1617.0 (8d6345)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Suggested fix

Validate drive accessibility before attempting Plan9 share. Before calling HcsModifyComputeSystem for a drive, verify the path actually exists and is accessible (e.g., GetVolumeInformation() or a simple directory existence check).
Make individual drive mount failures non-fatal. Wrap each Plan9 share addition in error handling that logs a warning and continues, rather than terminating the entire service. This would also fix #44486.
Consider filtering the drive list to only include drives with a valid volume GUID path, excluding phantom/stale entries.

Related issues

#44486 — CoworkVMService crashes when external/USB drive cannot be mounted as Plan9 share (same crash behavior, different trigger)
#29583 — Cannot use folders outside home directory on Windows (broader drive access issue)
#24927 — Folder picker rejects non-home drives on Windows