### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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.3

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

Status Open

Maintainer reply None cached

Workaround ✓ Mentioned in description ↑

Activity 3 comments · opened Aug 26, 2026

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:

Updater/launcher pre-flight check for stale Container_Claude_* Job objects before relying on a generic "file in use" error.
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.
Surface a more specific error message identifying the actual lock holder.
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.

View original on GitHub ↗

3 Comments

aleozlx · 1 month ago

Same failure, Windows 11 x64, Claude_1.46388.1.0_x64__pzs8sxrjxfjjc superseding 1.44121.4.0. Adds two data points beyond what's here and in #61635:

The Job blocks launch with zero member processes. Elevated handle.exe found Container_Claude_1.44121.4.0_x64__pzs8sxrjxfjjc-<SID> held by svchost.exe (Appinfo). Its sole member was an orphaned MCP-server child (python.exe) that outlived the Claude session — same mechanism as #62419. Killing that process did not release the Job. I opened the Job directly via NtOpenJobObject + QueryInformationJobObject(JobObjectBasicProcessIdList): it reported 0 assigned processes, yet the object still resolved by name and Restart-Service Appinfo -Force (via killing its svchost PID, since graceful Stop-Service fails) did not clear it — handle -a Container_Claude still found it after the restart.

Sign-out does not clear it either, only a full reboot did. This argues against a per-logon Appinfo cache as the retention mechanism (sign-out tears down session kernel objects) — whatever's pinning the empty Job survives both a targeted Appinfo restart and full session teardown, and only resolves on OS restart.

Given #59934 documents a working non-destructive recovery (Add-AppxPackage -Register against the current manifest, no reboot), it'd be useful to know whether that only works for the pre-Job-formation failure mode (208 without a leaked Job) versus this one (Job confirmed present, empty, unreleasable) — in my case it did not help once the Job had already formed. Happy to share the full NtJob/QueryInformationJobObject PowerShell repro if useful for triage.

ReveurGAM · 1 month ago

Recurrence, 2026-09-04, Windows 11 x64. Independently confirms both of @aleozlx's points above, plus one correlation and one piece of tooling worth sharing.

Currently registered: Claude 1.46388.2.0 (Get-AppxPackage; full package string assumed Claude_1.46388.2.0_x64__pzs8sxrjxfjjc based on the consistent family ID below, not returned verbatim by that command). Elevated handle -a -u "Container_Claude" found: svchost.exe (PID 2136), type Job, owner NT AUTHORITY\SYSTEM, holding Container_Claude_1.44121.4.0_x64__pzs8sxrjxfjjc — the same superseded version @aleozlx reports, despite our two machines landing on different current versions (1.46388.1.0 vs 1.46388.2.0). The identical leaked-version string across two independent machines suggests something specific to 1.44121.4.0 (or its update path), not a purely random per-machine leak.

tasklist /svc confirmed PID 2136 = Appinfo, matching this report and #61635.

Additional data points from this machine's history with this bug (not all re-tested tonight specifically):

Windows' built-in "Repair" app-troubleshoot flow has, in past occurrences, completed without clearing the underlying condition — consistent with repair operating at package-registration level, not releasing a kernel handle held by an unrelated service.
A custom recovery script (process-tree kill, CoworkVMService stop, Electron-lockfile clear) has also not resolved this in past occurrences — none of those steps touch AppInfo.
Can independently confirm sign-out does not clear it either (matching @aleozlx's point 2).

New tonight: added an automated preflight check to that recovery script. Before running any of the steps in (2), it does an elevated handle -a -u "Container_Claude" scan, compares the leaked version against Get-AppxPackage's current version, and if they differ, reports the mismatch (leaked version, current version, holding PID/service) and exits rather than running steps already known not to help. This is a working implementation of Suggested Fix #1 from the original #61635 report ("updater pre-flight check for stale Job objects"). It correctly detected tonight's leak, matching the manual scan exactly. Happy to share the PowerShell function if it's useful for anyone triaging this.

The only fix that has ever worked on this machine is a full reboot — confirmed for the original occurrence (8/25); reboot for tonight's is pending as of this comment. This is a confirmed recurrence across two different version pairs on my own machine (1.34493.1.0 → 1.37937.0.0 originally, now 1.44121.4.0 → 1.46388.2.0), and matches @aleozlx's independent report on a third pairing (1.44121.4.0 → 1.46388.1.0) — not a one-time event.

If you'd like a copy of the script, which also holds another, untested option (remarked out), let me know. I start it with a .bat file that is elevated.

dvwatkins · 1 month ago

Independent reproduction of this issue on a newer Claude Desktop build.

Environment

Windows 11 Pro 25H2, x64
Current Claude Desktop: Claude_1.46388.4.0_x64__pzs8sxrjxfjjc
Package status: Ok
Recurrent issue, not a one-time installation failure

Symptoms
Claude Desktop suddenly exited during use and could not be relaunched. Subsequent launch attempts produced the Windows dialog:

Another program is currently using this file.

AppModel Runtime consistently logged:

Event 208
0x80070020: Cannot create the process for package
Claude_1.46388.4.0_x64__pzs8sxrjxfjjc
because an error was encountered while configuring runtime. [LaunchProcess]

Event 215
0x80070020: Cannot create the Desktop AppX container for package
Claude_1.46388.4.0_x64__pzs8sxrjxfjjc
because an error was encountered converting the job.

I worked through process/service elimination before rebooting:

No Claude.exe remained running.
Stopped CoworkVMService successfully and confirmed cowork-svc.exe exited. No change.
Killed the surviving Claude chrome-native-host.exe. No change.
No git.exe/fsmonitor process was present.
Process Explorer searches against the Claude package/path did not reveal the holder.
Get-AppxPackage continued to report Status: Ok.

I then used Sysinternals Handle 5.0:

handle64.exe -a -u "Container_Claude"

svchost.exe   pid: 6928   type: Job   NT AUTHORITY\SYSTEM
\Container_Claude_1.46388.1.0_x64__pzs8sxrjxfjjc-S-1-5-21-...-1001

The owning service is definitively AppInfo:

tasklist /svc /fi "services eq Appinfo"

svchost.exe   6928   Appinfo

WMI independently confirms:

Name      : Appinfo
State     : Running
ProcessId : 6928
StartMode : Manual

The significant point is that the currently registered Claude package is 1.46388.4.0, while AppInfo is retaining a Container_Claude Job for the superseded 1.46388.1.0 version.

This appears to independently reproduce the core mechanism described in this issue on the current 1.46388 release line.

I also attempted:

Stop-Service Appinfo -Force

but Windows refused the service stop. I did not force-kill the AppInfo svchost.exe or use handle -c against the Job because of the potential for system instability.

I have not yet rebooted because I have a long-running development session active and wanted to preserve the failure state for diagnosis.

As a preventive measure, I have now applied Anthropic's documented policy:

HKLM\SOFTWARE\Policies\Claude
disableAutoUpdates = 1

The recurring nature of this failure and the fact that the stale Job references an older Claude build raise the question of whether the Desktop MSIX update lifecycle can leave an AppInfo-held Job behind when transitioning versions.

I have retained the full AppModel Runtime logs and PowerShell/Sysinternals diagnostic output if they would be useful to the Desktop engineering team.