[BUG] Claude Desktop (Windows x64) — stale AppContainer Job leaked by AppInfo service blocks relaunch after ordinary crash (no update in progress)

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?

Claude Desktop crashed and would not relaunch, showing "Another program is currently using this file" pointing at C:\Program Files\WindowsApps\Claude_1.37937.0.0_x64__pzs8sxrjxfjjc\.... No in-app update was in progress at the time. An elevated handle.exe scan found the actual lock is a kernel-level AppContainer Job object, held by the Windows AppInfo (UAC) service, referencing an old, no-longer-registered Claude version — not the currently installed one. This matches the mechanism reported in anthropics/claude-code#61635, but with a different trigger context (see Additional Information).

Confirmed via troubleshooting: ending the full claude.exe process tree did not resolve it; a custom kill script confirmed neither a running process nor the Electron lockfile was the blocker; Stop-Service CoworkVMService -Force succeeded and stayed stopped with no effect on the launch failure; Set-Service CoworkVMService -StartupType Disabled failed with Access Denied (protected service ACL, consistent with #57371).

Same as #61635's theory: the Windows AppInfo (UAC elevation broker) service opened a handle to an AppContainer Job object for a Claude Desktop version that has since been superseded, and never released it. The stale handle blocks the currently-registered version from launching, surfacing as a generic "file in use" error that does not point at the real holder.

What Should Happen?

Claude Desktop should launch normally against the currently-registered package version. A stale Job object referencing a superseded, no-longer-installed version should not be able to block the current version from starting — and if the launcher/updater detects a generic "file in use" failure, it should identify the actual lock holder (service + object type) rather than surfacing an unspecific dialog that points at the install path itself.

Error Messages/Logs

Initial scan targeting the file path found nothing:

handle -a "WindowsApps\Claude_"
No matching handles found.


Broadened scan (elevated) targeting the AppContainer naming pattern from #61635 found the actual holder:

handle -a -u "Container_Claude"
svchost.exe   pid: 6452   type: Job   NT AUTHORITY\SYSTEM
  \Container_Claude_1.34493.1.0_x64__pzs8sxrjxfjjc-S-1-5-21-3600484967-2995034899-2738637813-1002


Confirmed the owning service:

tasklist /svc /fi "PID eq 6452"
svchost.exe   6452   Appinfo

Steps to Reproduce

Steps to reproduce

Not reliably reproducible on demand. Observed as: app became unresponsive/crashed during ordinary use (no update prompt visible), and subsequent launch attempts — from Start Menu, and after fully terminating all claude.exe processes — consistently returned the file-in-use dialog.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

About 3 months ago, whatever version was used then.

Claude Code Version

Version 1.37937.0 (61bfd4)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Claude Desktop app (Windows), not invoked from a terminal
Environment: Windows 11 Pro, Version 25H2 (OS Build 26200.9168), x64. Claude Desktop currently registered as Claude_1.37937.0.0_x64__pzs8sxrjxfjjc; leaked Job object references the superseded Claude_1.34493.1.0_x64__pzs8sxrjxfjjc. Diagnostic tool: Nthandle v5.0 (Sysinternals Suite, Microsoft Store/MSIX distribution). Not yet rebooted at time of filing — deliberately held off to capture diagnostics first. (Update, post-filing: a full reboot did resolve the launch failure, confirming the diagnosis.)

Differences from #61635, worth noting and not yet explained:

• Architecture: this report is x64; #61635 was ARM64.
• Trigger context: #61635 was observed during an in-app update and theorized the leak originated from a prior UAC-elevated action within Claude Desktop. Here, no update was in progress, and the reporter states they never use any UAC-elevated feature of Claude Desktop — the acquisition mechanism is therefore unconfirmed and may not match #61635's theory, or may indicate AppInfo can acquire/leak this handle without an explicit in-app elevation action.
• CoworkVMService respawn behavior: #61635 states the service "re-acquires its handles within seconds" of being stopped. Here, Stop-Service CoworkVMService -Force stayed stopped while the app remained closed — it appears to restart only when Claude Desktop itself launches, not independently.

Workarounds tried (none resolved short of the reboot): ending the process tree via Task Manager; the custom kill script; Stop-Service/Set-Service on CoworkVMService (see What's Wrong). Reboot is the only thing that resolved it.

Suggested fixes:

1. Updater/launcher pre-flight check for stale Container_Claude_* Job objects before relying on a generic "file in use" error.
2. Investigate why AppInfo retains the Job reference after the owning app version is superseded/exits — possible missing handle release in an elevation-broker code path.
3. Surface a more specific error message identifying the actual lock holder.
4. If confirmed this can occur without any user-initiated elevation, that broadens the scope of #61635's fixes — the leak may not require a UAC-triggered feature to occur.

Unrelated context: reporter has separately investigated a longer-running, distinct instability issue (intermittent "freeze-then-vanish" crashes with no forensic trace) — filed as a separate report; not confirmed to share a root cause with this issue.