[BUG] Cowork (Windows): VM ID derived from user SID only — second Claude Desktop instance can't start its VM (0x8037010f)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet — closest is #67972 (same symptom, auto-closed as stale and locked; the bot asked for a new issue referencing it). This report adds the root cause and a concrete fix.
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

On Windows, Cowork's VM ID is derived from the Windows user SID alone, while CoworkVMService keys its sessions by SID and the Claude Desktop data folder. So two Claude Desktop instances with different --user-data-dir (two accounts, e.g. personal + work) get two service sessions that both try to create a Hyper-V compute system with the same ID. Whichever starts second always fails while the first VM runs:

• The second instance's Cowork / local-folder access is unusable ("Workspace unavailable. The isolated Linux environment on this device failed to start.").
• The error is reported as HYPERVISOR_SERVICE_ERROR, which reads as "virtualization is broken" although the first VM is running fine.

Evidence from C:\ProgramData\Claude\Logs\cowork-service.log (username and SID redacted):

[Server] Reusing existing session for <SID>:C:\Users\<user>\AppData\Roaming\Claude
[Server] Created new VM session for <SID>:C:\Users\<user>\AppData\Local\ClaudeProfile-Work
[HCS] Calling HcsCreateComputeSystem with id=cowork-vm-6aec8e4f        <- instance A
[HCS] Calling HcsCreateComputeSystem with id=cowork-vm-6aec8e4f        <- instance B, same id
[HCS] HcsWaitForOperationResult returned: hr=0x8037010f
[HCS] Result JSON: {"Error":-1070137073,"ErrorMessage":"A virtual machine or container with the specified identifier already exists."}
[VNet] Virtual network stopped

The ID is cowork-vm- + the first 8 hex chars of sha256(<SID string>) — the sha256 of my SID starts with 6aec8e4f (symbol vm.VMIDForSID in cowork-svc.exe). The data folder plays no part, although the service receives it (Configuring VM for sid=<SID> userDataDir=...).

What Should Happen?

Each Desktop data folder gets its own VM, consistent with the per-folder sessions. Suggested fix in VMIDForSID: hash the SID together with the case-folded userDataDir, e.g. cowork-vm- + sha256(SID + "\0" + lower(userDataDir))[:8], and keep the SID-only ID for the default data folder so existing installs are unaffected.

At minimum, if one VM per user is intentional: detect 0x8037010f and tell the user another Claude Desktop instance's Cowork VM is running, instead of HYPERVISOR_SERVICE_ERROR.

Error Messages/Logs

[VM:start] VM boot failed: HCS operation failed: failed to create compute system: HcsWaitForOperationResult failed with HRESULT 0x8037010f: {"Error":-1070137073,"ErrorMessage":"A virtual machine or container with the specified identifier already exists."}
[VM:start] HCS error detected, available=true, missing=[], sentinel=HYPERVISOR_SERVICE_ERROR
[VM:start] Startup failed: Error: HYPERVISOR_SERVICE_ERROR

Steps to Reproduce

1. Run Claude Desktop normally (data in %APPDATA%\Claude), signed in to account A, and start anything that uses Cowork / a local folder, so its VM boots.
2. Start a second instance with its own data folder directly under %LOCALAPPDATA%: Claude.exe --user-data-dir="%LOCALAPPDATA%\ClaudeProfile-Work", sign in to account B.
3. In instance B, start a Cowork task or a cloud session that uses a local folder.
4. Instance B fails with the log lines above. Quit instance A from the tray and retry: instance B's VM can then be created.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Desktop 2.16120.0.0 (MSIX / Microsoft Store), bundled Claude Code 2.1.284

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

• Windows 11 Pro 10.0.26200 (x64), Azure AD-joined. CoworkVMService: LocalSystem, WIN32_PACKAGED_PROCESS.
• Previously reported on Claude Desktop 1.12603.1.0 in #67972; still present in 2.16120.0.0.
• Not verified: the [VNet] Virtual network stopped line right after the failed create suggests the failure path may tear down the virtual network the running VM uses.
• Related but separate: the service rebuilds the bundle path as %LOCALAPPDATA%|%APPDATA%\<basename(userData)>, so a nested --user-data-dir can never boot (VHDX file not found), and junctions are refused (is a symlink or junction, refusing to open). A data folder directly under %LOCALAPPDATA% works around that; documenting the constraint would help.