[BUG] Windows: "Another program is using this file" after in-app update — happens even when quitting cleanly from the system tray (1.25927.0.0 → 1.26832.0.0)

Update — identified what holds the lock (Resource Monitor evidence)

I traced the file lock with Resource Monitor (CPU → Associated Handles, searched "Claude"). The processes holding open handles to the update folder are claude.exe itself — multiple child processes with different PIDs (at least 9 at once), not antivirus, Windows Search, or Explorer. No non-Claude process appears in the results.

All of them hold handles to files under the new package's app folder, e.g.:

C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64_...\app\resources.pak
...\app\resources\app.asar
...\app\icudtl.dat
...\app\v8_context_snapshot.bin
...\app\chrome_100_percent.pak
...\app\chrome_200_percent.pak
...\app\locales\zh-TW.pak

So this confirms the root cause: quitting from the tray does not terminate Claude's Electron child processes; they keep the WindowsApps app directory locked, and the MSIX update can't swap the files. A reboot only "works" because it's the only thing that kills the orphaned processes.

Workaround that avoids a reboot: taskkill /F /IM claude.exe /T to force-kill the whole process tree, then relaunch — the update then applies cleanly. But users shouldn't have to do this; a clean quit should already terminate every child process, or the updater should kill/await them before swapping files.

Environment: Windows (zh-TW locale), MSIX package at C:\Program Files\WindowsApps\Claude_...

I am experiencing what appears to be the same issue with Claude Desktop version 1.26832.0.0, but I found another reproducible trigger: it happens when the browser is opened from within Claude Code.

Before triggering the problem, I run:

Get-AppxPackage Claude |
    Select-Object Name, Version, Status

The package status is normal:

Name    Version       Status
----    -------       ------
Claude  1.26832.0.0   Ok

Then, when Claude Code opens the browser, Claude Desktop closes unexpectedly.

Immediately afterward, running the same PowerShell command shows:

Name    Version       Status
----    -------       --------------------------
Claude  1.26832.0.0   Modified, NeedsRemediation

This seems significant because the browser launch is not only causing Claude Desktop to terminate—it is also changing the Windows MSIX package state from Ok to Modified, NeedsRemediation.

This may indicate that opening the browser triggers a child process, file modification, or package-container conflict that leaves the Claude Desktop installation in an invalid state.

It would be useful to investigate:

• Which process or packaged file is being modified when the browser opens;
• Whether there is a conflict between Claude Code, the browser process, and the Claude Desktop MSIX package;
• Why this action changes the AppX package state to NeedsRemediation;
• Whether this is related to the file lock/update problem described in this issue.

Environment:

• Windows
• Claude Desktop/MSIX version: 1.26832.0.0
• Reproducible when the browser is opened from within Claude Code

Another data point, plus an answer to the "Is this a regression? I don't know" field — it is, and the boundary is measurable.

I hit a milder variant of this on the same package family: the dialog appears and the app does not come back, but it is launchable again immediately from the Start Menu. No logoff, no reboot. So the persistent-container case in this report and my transient case may share a symptom but not a root cause — details below, in case that split is useful for triage.

The measurement

The app logs both halves of the update restart to %APPDATA%\Claude\logs\main.log:

[info] beforeQuitForUpdate handler fired, going down for update
...
[info] [updater] Version changed since last launch: A → B
[info] [update-restart] Detected nav-restore marker, launching normally
[info] [stealth-relaunch] Loaded navigation history (N entries, active=M)

The gap between those two timestamps is a clean pass/fail signal. The self-restart takes ~32 s consistently. When it fails, a human has to click, so the gap blows out. That makes the failure detectable retroactively from logs, without needing to reproduce it live.

The regression boundary

Every update on this machine, oldest first:

| Date | Target version | Gap | Self-restart |
|---|---|---|---|
| 2026-07-07 | 1.18286.2 | 32 s | ok |
| 2026-07-11 | 1.20186.1 | 33 s | ok |
| 2026-07-14 | 1.20186.9 | 33 s | ok |
| 2026-07-15 | 1.21459.0 | 32 s | ok |
| 2026-07-16 | 1.21459.1 | 31 s | ok |
| 2026-07-16 | 1.21459.3 | 32 s | ok |
| 2026-07-17 | 1.22209.0 | 33 s | ok |
| 2026-07-19 | 1.22209.3 | 33 s | ok |
| 2026-07-22 | 1.24012.1 | 31 s | ok |
| 2026-07-27 | 1.24012.9 | 35 s | ok |
| 2026-08-04 | 1.24012.11 | 32 s | ok |
| 2026-08-05 | 1.25927.0 | 32 s | ok |
| 2026-08-10 | 1.26832.0 | 19 min | failed |
| 2026-08-12 | 1.28929.0 | 3 min 42 s | failed |
| 2026-08-15 | 1.30096.5 | 1 min 37 s | failed |
| 2026-08-18 | 1.32352.1 | 30 s | ok |
| 2026-08-19 | 1.32885.1 | 1 min 47 s | failed |

12/12 before 1.26832.0, then 4 failures in 5 updates. Same version this report names as its first occurrence. It is intermittent, not deterministic — 2026-08-18 succeeded — which is what you would expect from a race rather than a hard lock.

No lock was involved in my case

Worth separating from the container-pinning reports, because the deployment log says the package swap went through cleanly:

07:52:34  Deployment Register dequeued for package Claude_1.32885.1.0_x64__...
07:52:38  TerminateSingleService for update succeeded for service ... in package CoworkVMService
07:52:39  Moving package folder "\\?\C:\Program Files\WindowsApps\Claude_1.32352.1.0_x64__..."
          to "\\?\...\WindowsApps\Deleted\Claude_1.32352.1.0_x64__...". Result: 0x0.
07:52:39  Deployment operation Register ... completed successfully.

Result: 0x0, old folder moved, package Status: Ok. Nothing was holding a handle. The update itself is fine — what fails is the restart that follows it, ~5 s wide.

Likely mechanism for the transient variant

process.execPath inside an MSIX package is the versioned path under C:\Program Files\WindowsApps\Claude_<version>_x64__.../app\Claude.exe. If the restart is spawned from that path, it lands inside the window where Windows has the package flipped to disabled and is moving the old folder — and Windows answers with its shell dialog, whose caption is the file path. Which is exactly the dialog in this report.

Packaged apps are meant to be launched through their identity rather than the file path:

shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude

or programmatically via IApplicationActivationManager::ActivateApplication. Going through identity lets Windows serialize the request against the deployment instead of racing it. That would not help the cases here where the container stays pinned and a reboot is required — but it should remove the transient class entirely, and those may be a good share of these reports.

Workaround that avoids the reboot

For the transient variant, a scheduled task on event 400 in Microsoft-Windows-AppXDeploymentServer/Operational, filtered to PackageDisplayName = Claude, with a 20 s delay, then activating the AUMID. If the app did manage to restart on its own, it finds a running process and exits. Runs as the normal user, no elevation. Verified end to end except the activation branch itself, which needs the app to actually be down.

Environment

• Windows 11 Pro 26200, de-DE locale
• MSIX package Claude_pzs8sxrjxfjjc, install under C:\Program Files\WindowsApps\
• Package status Ok after every one of the failures above — the app is never in a broken state, it just does not come back
• CoworkVMService present since 2026-03-10, so it predates the regression boundary by five months and does not line up as the cause here