Windows ARM64: desktop app cannot fully quit or self-update — packaged service pins the MSIX folder

Summary

On Windows ARM64 there is no supported way to fully quit Claude Desktop, and as a direct consequence the app cannot reliably self-update. Two separate things keep running after every window is closed.

1. A LocalSystem service pins the package folder

Claude Desktop installs as a sideloaded MSIX (Claude_<ver>_arm64__pzs8sxrjxfjjc, SignatureKind = Developer). It registers a LocalSystem Windows service CoworkVMService (display name "Claude") whose binary runs from inside the package folder:

C:\Program Files\WindowsApps\Claude_<ver>_arm64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

The service outlives the UI, so it holds a handle on the exact directory an update has to replace. Updates then fail with 0x80073D02, surfaced as "Another program is currently using this file". Restart Manager (RmStartSession / RmRegisterResources / RmGetList) confirms this service as the handle holder.

The in-app "Relaunch to update" pill does not clear it, because a relaunch never stops the service — it is trigger-started on \.\pipe\cowork-vm-service, so a surviving app process brings it straight back.

2. The helper tree outlives the UI

A live session traced to 83 processes across 8 executables: 25 conhost.exe, 21 claude.exe, 9 powershell.exe, 8 node.exe, 8 cmd.exe, 8 codex.exe, 3 bash.exe, 1 cowork-svc.exe. MCP servers and their shells are the bulk of it, and they persist after the window closes.

Impact

The only workarounds are both bad. Reinstalling from the signed installer works but forces a re-login every time. Otherwise users have to hand-write a process-tree killer — and that is genuinely easy to get wrong, because matching on executable name fails in both directions: killing only claude.exe strands the MCP servers (they hang off cmd.exe/node.exe and carry no Claude-ish name), while killing every node.exe/codex.exe destroys unrelated processes that merely share an executable. Correct behavior requires walking the process tree by ancestry, downward only, with a PID-reuse guard.

Requests

1. A real "quit completely" that stops CoworkVMService and reaps the helper tree.
2. An updater that stops its own service before staging the new package.
3. Failing both, document the manual recovery, since 0x80073D02 gives users no indication that a service is the cause.

Environment

• Windows 11 Pro 26200, ARM64
• Claude Desktop MSIX 1.37937.0.0
• Claude Code 2.1.241