[BUG] Cowork sandbox VM leaks on Windows - orphaned vmmem/vmwp (cowork-vm-*) keeps running after app quit

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?

The Cowork sandbox VM (HCS compute system cowork-vm-8597c77a) was leaked and ran orphaned for 2.5 days, holding ~1.5 GB RAM (vmmem) and generating background network traffic.

• The VM was created ~7 minutes after Windows boot when the Claude desktop app started.
• At some point the owning process exited without tearing the VM down (the parent PID of vmwp.exe no longer existed).
• Fully quitting the Claude desktop app did NOT stop the VM - the new app instance did not own it.
• The VM survived sleep/resume cycles until it was killed manually with elevated hcsdiag kill <GUID>.

Trust/visibility problem: in Task Manager the VM only appears as generic vmmem/vmwp.exe with no indication it belongs to Claude, so the user suspected malware/spyware and started killing VM processes.

What Should Happen?

• The sandbox VM is terminated when the owning app/session exits (including crash/update paths).
• On startup, the app detects and re-adopts or removes orphaned cowork-vm-* compute systems.
• Ideally the VM memory process is identifiable (e.g. vmmemCowork) or documented, so users do not mistake it for malware.

Error Messages/Logs

hcsdiag list (elevated):
  cowork-vm-8597c77a
      VM,                       Running, C7FBA014-8A24-5AC9-BA3D-18E4BCD91E07

Process evidence:
  vmwp.exe  PID 2928  created 2026-07-04 08:43:20, parent PID 7460 (no longer exists -> orphan)
  vmmem     PID 2568  ~1.5 GB working set, child of vmwp
  Last real boot: 2026-07-04 08:36:41 (VM created ~7 min after boot; machine up 2.5 days)

Not WSL: Ubuntu distro reported Stopped the whole time; wsl --shutdown had no effect.
Fix that worked: elevated hcsdiag kill C7FBA014-8A24-5AC9-BA3D-18E4BCD91E07 - VM gone, traffic stopped, did not return on app restart (sandbox VM is created on demand).

Steps to Reproduce

Exact trigger unknown - likely the owning Claude process exiting abnormally (crash or update) while the sandbox VM is running. Observed sequence:

1. Boot Windows and start the Claude desktop app (Cowork sandbox VM cowork-vm-* is created).
2. The owning process exits without cleanup (parent PID of vmwp.exe is gone).
3. Quit the Claude desktop app completely.
4. vmmem/vmwp.exe keep running indefinitely; elevated hcsdiag list still shows cowork-vm-* as Running, across sleep/resume.

Claude Model

_No response_

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.197

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

• Windows 11 Pro 10.0.26200 (build 26200.8655), x64
• Desktop app: Claude 1.18286.0.0 x64 (MSIX)
• Claude Code runtime: 2.1.197
• VM platforms installed: WSL2 + Virtual Machine Platform only; Hyper-V management service (vmms) not installed; Docker Desktop installed but disabled at startup and not running - nothing else could have created this VM.
• Related but distinct: #29045 (VM spawns on every launch), #73694 (CoworkVMService file lock during update); neither covers the orphan/leak-after-quit case.