claude-code - 💡(How to fix) Fix [BUG] Claude Desktop Windows ARM64 — in-app update fails with 'Another program is currently using this file'; stale AppContainer Job leaked by AppInfo service blocks update + launch

Summary

Claude Desktop on Windows 11 ARM64 fails to update via the in-app updater with the dialog "Another program is currently using this file" pointing at C:\Program Files\WindowsApps\Claude_<version>_arm64__pzs8sxrjxfjjc\. After dismissing the dialog, Claude Desktop also refuses to launch — the same error reappears. The dialog is misleading: extensive handle.exe scanning shows no file handles are open on the install folder. The real blocker is a kernel-level AppContainer Job object for the previous Claude Desktop version that the Windows Application Information (AppInfo / UAC) service refuses to release without a reboot.

A secondary contributor is the CoworkVMService Windows service shipped with Claude Desktop — it auto-starts on boot, loads DLLs from the install folder, and re-acquires its handles within seconds of being stopped, so manual Stop-Service is not a stable workaround.

Environment

Steps to reproduce

1. Run Claude Desktop ARM64 build 1.8555.1.0 for some time; at least one launch is elevated/UAC-triggered (e.g. a feature that prompts UAC).
2. Accept the in-app "Update available" prompt that offers 1.8555.2.0.
3. The updater downloads + registers the new package successfully (event log confirms Deployment Register operation ... finished successfully for Claude_1.8555.2.0_arm64__pzs8sxrjxfjjc).
4. Mid-finalization, dialog appears: C:\Program Files\WindowsApps\Claude_1.8555.2.0_ar... — Another program is currently using this file.
5. Click OK to dismiss. The app appears to exit.
6. Try to launch Claude Desktop from Start Menu → same dialog reappears, app never opens.

Actual behavior

• In-app update dialog reports file is in use, but no usermode handle exists on the install folder.
• AppX package status is Ok and Add-AppxPackage -Register against the manifest succeeds, but launch still fails.
• Microsoft Store has no "Claude Desktop" entry (MSIX is sideloaded direct from Anthropic), so the standard "Get updates" path is unavailable.

Diagnostic findings (elevated handle.exe scan)

svchost.exe        pid: 12684  type: Job   NT AUTHORITY\SYSTEM
  \Container_Claude_1.8555.1.0_arm64__pzs8sxrjxfjjc-S-1-5-21-<SID>

cowork-svc.exe     pid: 47644  type: File  NT AUTHORITY\SYSTEM
  C:\ProgramData\Claude\Logs\cowork-service.log

(handle scan for 'Program Files\WindowsApps\Claude' = "No matching handles found")

Service identification:

• svchost.exe PID 12684 → service: Appinfo (Application Information — the UAC elevation broker). This service holds the Job object for Container_Claude_1.8555.1.0_arm64__.... Note this references the previous version even though 1.8555.2.0 is the only registered package. Appinfo cannot be safely stopped without breaking UAC for the entire session.
• cowork-svc.exe PID 47644 → service: CoworkVMService (display name Claude, StartMode Auto), running from C:\Program Files\WindowsApps\Claude_1.8555.2.0_arm64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe. Stop-Service CoworkVMService releases its handles, but the service auto-restarts within ~30 seconds.

Suspected root cause

When Claude Desktop 1.8555.1.0 was previously launched in a context that touched UAC (any in-app action that triggered an elevation broker call), Windows' Appinfo service opened a handle to the AppContainer's Job object and never released it after the app exited. When the in-app updater later upgraded the registration to 1.8555.2.0, the package metadata flipped but the kernel still has a live Job named with the old version string (Container_Claude_1.8555.1.0_...). AppX deployment finalization and subsequent launch attempts hit a naming/ACL conflict on the container and surface as a generic "file in use" error pointing at the install folder.

Additional pressure from CoworkVMService auto-starting from the install folder while the updater is mid-flight likely worsens the timing window.

Workarounds tried (none stable)

The only confirmed fix is a full reboot to clear the AppInfo-held Job object reference.

Suggested fixes

1. Updater pre-flight check: before initiating AppX deployment, the in-app updater should call OpenJobObject / enumerate \BaseNamedObjects\Container_Claude_* and warn the user if a stale-version Job exists, recommending a reboot.
2. Set CoworkVMService StartMode to Manual so it does not auto-acquire DLL handles immediately after boot (start it on first Claude Desktop launch instead).
3. Surface a better error message than "Another program is currently using this file" — at minimum include the package full name and the HRESULT, since the actual lock holder is not a usermode process.
4. Investigate why AppInfo retains the Job ref — possibly a missing CloseHandle in an elevation-broker code path when the AppContainer'd app exits.

Logs / artifacts available

• Microsoft-Windows-AppXDeploymentServer/Operational event log: shows successful registration of 1.8555.2.0 alongside (unrelated) Clipchamp deletion errors.
• Full handle64a.exe -a -u Claude_1.8555 elevated scan output (sanitized): available on request.
• Get-AppxPackage output confirming Status=Ok for both packages.

Happy to provide more diagnostics; the machine is in the broken state right now (pre-reboot).