›_ Claude Code Issues
Claude Code Issues / #89992

[BUG] Windows MSIX auto-update terminates running app — "Another program is currently using this file"

Status Open
Maintainer reply None cached
Activity 7 comments · opened Aug 27, 2026

Environment

  • Claude Desktop (MSIX), Windows 11 x64
  • Package family: Claude_pzs8sxrjxfjjc
  • Electron 42.10.0 / Node 24.18.1
  • Affected versions observed: 1.32352.x, 1.37937.1 → .2 → .3

Summary

Auto-update stages a new MSIX package, then cannot complete the swap because the
running app holds file handles inside its own package directory. Windows shows an
error dialog titled with the staged package path and terminates the app. From the
user's side this reads as the app crashing every few hours.

Error dialog

Title: C:\Program Files\WindowsApps\Claude_1.37937.2.0_...
Body:  Another program is currently using this file.

Evidence

  1. Four package versions accumulated in WindowsApps, two staged on the same day

(8/26 11:10 AM and 8/26 8:18 PM) — old versions were not cleaned up because the
swap kept failing.

  1. Reported appVersion advanced 1.37937.1 -> 1.37937.2 only via the crash, not a

clean restart.

  1. Crashpad\reports is empty — no minidump, consistent with external termination

by package deployment rather than an app fault.

  1. Fully quitting the app (tray + ending all Claude.exe) and relaunching let the

update complete, and the superseded package was then removed correctly.

Secondary issues

  • After the update, %LOCALAPPDATA%\Claude\logs was emptied. Prior logs (5.3 MB

main.log) were destroyed, which removes the evidence for exactly this class of
bug. Logging has not resumed in that location or in
LocalCache\Roaming\Claude\logs.

  • On the forced restart the Cowork agent device lease was not released, producing

"Another device is connected — A Cowork agent is already running on <device>" and
blocking startup until "Disconnect all and retry" was clicked.

Expected

The updater should quit and relaunch the app itself to release its handles, or defer
the swap until next launch — not let Windows kill it mid-session, and not destroy
logs on the way through.

View original on GitHub ↗

3 Comments

claell · 1 month ago

Confirming the same dialog on 2026-09-03, on a newer build and in a third UI locale.

Environment

  • Claude Desktop (MSIX) 1.44121.4.0, x64, package family Claude_pzs8sxrjxfjjc, Status: Ok, SignatureKind: Developer
  • Windows build 26200, x64, German UI

What I see

After unlocking the laptop this morning, every launch attempt shows a Windows dialog:

Title: C:\Program Files\WindowsApps\Claude_1.44121.4.0_x64...
Body:  Ein anderes Programm greift gerade auf diese Datei zu.

That is the German form of the string this issue reports in English ("Another program is currently using this file"). The title is truncated by the dialog; the installed package is Claude_1.44121.4.0_x64__pzs8sxrjxfjjc, which matches the visible prefix. Closing the dialog and relaunching reproduces it every time. No Claude.exe process is running at check time.

Updater trigger

%LOCALAPPDATA%\Claude\logs\main.log shows the idle stealth updater fired the same morning for exactly this version:

2026-09-03 10:53:08 [info] [updater] Update downloaded and ready to install { releaseName: 'Claude 1.44121.4' }
2026-09-03 11:03:38 [info] [stealth-update] Triggering stealth update after idle timeout
2026-09-03 11:03:38 [info] beforeQuitForUpdate handler fired, going down for update

The same idle-timeout pattern appears twice before in the same log (2026-08-28 and 2026-09-02). I previously knew this flow as a banner asking for a click to restart; these three runs restarted without one.

Container failure, not a file lock

Microsoft-Windows-AppModel-Runtime/Admin logs correlated failures for the same package on every launch attempt (German text):

  • Event 215, 0x80070020: the Desktop AppX container cannot be created, error converting the job
  • Event 208, 0x80070020: the process cannot be created, error configuring the runtime ([LaunchProcess])

In the same time window, other packaged apps (Python, Dell Command Update, ScreenSketch, Teams, Codex) create their containers normally, so this is specific to the Claude package. Microsoft-Windows-AppXDeploymentServer/Operational shows RegisterByPackageFullName with ForceTargetApplicationShutdownOption + RepairAppRegistrationOption completing successfully (event 400) on repeated attempts today, yet the next launch fails identically — a successful Register does not recover it.

Impact

The app is unusable until a sign-out or reboot; I have not rebooted yet, so that recovery is still the expectation from the linked reports rather than something I have re-verified here. Either way, an idle auto-update should never strand the package in a state where every manual relaunch shows a file-in-use dialog.

Related, for triage: #53247 owns the container-layer mechanism (misleading message, Register does not recover), #91482 covers the same stealth-on-idle trigger with the service/container conflict, and #90870 covers the restart firing without user action despite a staged banner.

claell · 1 month ago

This happened again to me last night. There I could witness this happening in real time. Hopefully it gets fixed very soon. Thank you.

shimon-eng · 1 month ago

Confirming the same dialog twice today (2026-09-06) on the newest build, x64. Two separate episodes, both fixed only by a reboot.

Environment

  • Claude Desktop (MSIX) 1.46388.3.0 -> 1.46388.4.0, package family Claude_pzs8sxrjxfjjc, x64
  • Windows 11 Pro 25H2, build 26200
  • Claude Code sessions running inside the app (several claude.exe processes plus the CoworkVMService service)

Update cadence (from Microsoft-Windows-AppXDeploymentServer/Operational, event 658)
Seven staged updates in five days, every one "marked for deferred registration because the previous version is still running":

2026-09-02 12:24  1.40609.0.0  -> 1.40609.1.0
2026-09-02 18:21  1.40609.1.0  -> 1.44121.2.0
2026-09-03 02:32  1.44121.2.0  -> 1.44121.4.0
2026-09-04 00:43  1.44121.4.0  -> 1.46388.1.0
2026-09-04 10:54  1.46388.1.0  -> 1.46388.2.0
2026-09-04 16:04  1.46388.2.0  -> 1.46388.3.0
2026-09-06 10:39  1.46388.3.0  -> 1.46388.4.0

Episode 1 (morning)
Rebooted 10:38, app launched 10:39:02 on 1.46388.3.0, and at 10:39:49 Windows had already staged 1.46388.4.0 and deferred it because 3.0 was running. Dialog title was the 1.46388.3.0 folder.

Episode 2 (afternoon) - repeated launch attempts never recover

12:45:16  603  RegisterByPackageFamilyName, ForceApplicationShutdownOption  (3.0 -> 4.0 update applied)
12:45:17  9648 TerminateSingleService CoworkVMService (3.0)
12:45:32  603  RegisterByPackageFullName 1.46388.4.0   <- every launch attempt below re-registers
12:47:25  603  RegisterByPackageFullName 1.46388.4.0
12:47:45  603  RegisterByPackageFullName 1.46388.4.0
12:48:23  603  RegisterByPackageFullName 1.46388.4.0
12:49:53  603  RegisterByPackageFullName 1.46388.4.0
12:52:51  603  RegisterByPackageFullName 1.46388.4.0
12:54:07  603  RegisterByPackageFullName 1.46388.4.0
12:54:46  reboot
12:55:24  app launches normally on 1.46388.4.0

Each of the seven re-registrations logged TerminateSingleService ... CoworkVMService ... successful and every event returned 0x0, yet each launch showed the dialog with the 1.46388.4.0 folder in the title. So the register succeeds, the service is killed, and the next launch still fails, matching the "successful Register does not recover it" observation above. Only a reboot cleared it.

Impact
Non-technical user, app unusable for ~10 minutes per update until reboot, twice today. The update frequency (seven in five days) makes this a daily problem rather than an occasional one.

Happy to pull more log detail if it helps.

Showing cached comments. Read the full discussion on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Installation & update problems, Windows & WSL problems, Crashes, hangs & freezes

Browse all Claude Code issue topics →