Bug report: Claude Desktop (MSIX) launch blocked by leaked Cowork VM file handles

Companion note (plain-language version): [[Claude Desktop Launch Failure (claude 2026-08-18) ELI5]].

All findings below were collected live during the incident by Claude Code running on the affected machine. Timestamps are local (Israel), 2026-08-18.

Environment

• Windows 11 Pro 10.0.26200, x64
• Claude Desktop Claude_1.32352.0.0_x64__pzs8sxrjxfjjc (MSIX, WindowsApps), installed from Claude-e33b9a2c87bcb6d670dae34471d8b60f7aa790ae.msix
• Claude Code CLI 2.1.220–2.1.234 also active on the machine (unrelated to the failure; its claude.exe daemons live in ~\.local\bin)
• Cowork/VM feature had been used in the morning session (rootfs.vhdx present in package LocalCache)

Symptom

Every launch attempt of the desktop app shows a Windows dialog:

C:\Program Files\WindowsApps\Claude_1.32... — "Another program is currently using this file."

No app process is ever created. No crash dump, no WER report, no Application-log error.

Timeline (from AppXDeploymentServer/Operational and CoworkVMService logs)

• 03:07–03:08 — Deployment Add of 1.32352 with DeferRegistrationWhenPackagesAreInUse (old version running). Succeeds.
• 05:08 — second identical deferred Add. Succeeds.
• 07:08:51 — Register with ForceApplicationShutdownOption succeeds; app launches and runs a normal session at 07:09 (cache, cookies, sentry session, and vm_bundles\claudevm.bundle\rootfs.vhdx all written 07:09). A Cowork utility VM is started during this session.
• 13:12–13:21 — nine launch attempts. Each triggers RegisterByPackageFullName with ForceTargetApplicationShutdownOption, RepairAppRegistrationOption; every one finishes successfully (event 400), resiliency files _4 through _12. The app still never starts, same sharing-violation dialog each time.

Diagnosis

1. Restart Manager (RmGetList) on app\claude.exe and AppxManifest.xml: no user-mode process holds these files, yet activation fails with a sharing violation.
2. A leftover utility VM was found running: vmmemCmZygote (PID 2700), plus vmcompute/vmms; hcsdiag list denied without Hyper-V admin rights. The 07:09 session's Cowork VM was never torn down.
3. Conclusion: the leaked VM held kernel-side handles (VSMB/HCS mappings) on files inside the package directory. Kernel/VM handles are invisible to Restart Manager and Task Manager, which explains "file in use" with no owning process. AppX repair cannot clear them, hence the successful-repair-but-failed-launch loop.
4. Reboot resolved it immediately. First post-boot launch succeeded.

Red herrings eliminated (worth fixing anyway)

• CoworkVMService (display name "Claude", WIN32_PACKAGED_PROCESS, AUTO_START, LocalSystem, binary inside the MSIX at app\resources\cowork-svc.exe):
• Its own log warns on every start/stop: failed to configure recovery actions ... open service: Access is denied. The service cannot manage its own SCM recovery settings.
• Service DACL is D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;...;;;S-1-5-80-...) — Authenticated Users can start/stop it (no elevation needed!), but nobody, including Administrators, holds DC (change config). Set-Service -StartupType Disabled fails elevated. Stop→auto-restart on every package activation makes the service effectively unkillable during troubleshooting.
• No deployment errors at any point; the package was never corrupt. Reinstall was unnecessary.

Suggested fixes for Anthropic

1. Ensure Cowork utility VMs are torn down on session end and on app exit; add an orphan-VM sweep at app startup (enumerate HCS compute systems owned by the package, kill stale ones) so a leaked VM cannot brick the next launch.
2. Surface a real error: detect activation failure caused by in-use package files and tell the user what holds them (or that a reboot is needed) instead of the raw shell dialog.
3. Revisit CoworkVMService ACL/recovery design: the service cannot configure its own recovery actions, and admins cannot change its start type — hostile to both the service and to debugging.
4. Minor, separate: sessions attached over Remote Control appear in the desktop app under "Others" with a connection codename (desktop-…-mighty-alpaca) instead of the session's stored name and project folder (both present in the local job record).

Reporting route

/bug from Claude Code, or github.com/anthropics/claude-code/issues; this note is self-contained for either.

---

This report was written by Fable 5 after a human user experienced the bug and needed help with the technical terms and the proper English wording.