[BUG] Windows (MSIX) 1.30096.1.0: in-app update fails with "Another program is currently using this file"; app unlaunchable until reboot

Preflight Checklist

• [ ] 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

The first box is deliberately unchecked, because the honest answer is no. I searched first and found several open reports of the same failure: #76357, #77421, #84962, #75337, #77379, #83968, #80286, #73107, #42776. I am filing this anyway because my package version, 1.30096.1.0, is newer than any version named in those threads, and because I measured which processes hold the package folder open. Close this as a duplicate if the newer-version evidence is better placed as a comment on #76357.

What's Wrong?

Claude Desktop for Windows is installed as an MSIX package. Every time the app offers an update, the update fails. The app closes to restart, and then Windows shows this dialog:

C:\Program Files\WindowsApps\Claude_1.30096.1.0_x... Another program is currently using this file.

After that dialog appears, the app will not start. Every later launch attempt produces the same dialog. Only a restart of Windows clears it. After the restart the app opens normally.

This happens on every update notice, not occasionally.

What Should Happen?

The update should install and the app should relaunch on the new version, without a Windows restart and without a dialog about a file in use.

Error Messages/Logs

Dialog title:  C:\Program Files\WindowsApps\Claude_1.30096.1.0_x...
Dialog body:   Another program is currently using this file.
Buttons:       OK

Steps to Reproduce

1. Install Claude Desktop for Windows as an MSIX package (winget id Anthropic.Claude).
2. Use the app until it shows the notice that a new version is available.
3. Accept the update. The app closes to restart.
4. The dialog above appears instead of the new version starting.
5. Try to launch the app again. The same dialog appears.
6. Restart Windows. The app now launches.

Environment

| Item | Value |
|---|---|
| Claude Desktop package | Claude_1.30096.1.0_x64__pzs8sxrjxfjjc |
| Package install location | C:\Program Files\WindowsApps\Claude_1.30096.1.0_x64__pzs8sxrjxfjjc |
| winget package id | Anthropic.Claude |
| Claude Code version in the app | 2.1.229 |
| OS | Windows 11 Pro, build 10.0.26200 |
| Install type | MSIX |

Additional measurement

I could not measure during the failure, because the machine had to be restarted to make the app usable again. The following numbers come from a normal, healthy run of the app after the restart. They identify which processes hold files inside the package folder that the update has to replace.

Command:

handle.exe -nobanner Claude_1.30096.1.0_x64__pzs8sxrjxfjjc

Result:

• 63 open handles into C:\Program Files\WindowsApps\Claude_1.30096.1.0_x64__pzs8sxrjxfjjc.
• Every one of those handles belongs to claude.exe.
• Those handles are spread across 12 claude.exe processes, all started by one launch of the app.
• No other program held a handle inside that folder.

Process list from the same run:

Get-Process | Where-Object { $_.Path -like 'C:\Program Files\WindowsApps\Claude*' } |
    Select-Object Id, ProcessName, StartTime, Path

Two limits on this measurement, stated so nobody over-reads it:

1. handle.exe ran without administrator rights, so it could only see this user's processes. It does not rule out the svchost.exe and AppContainer causes described in #77379 and #83968.
2. These handles are from a healthy run, not from the failed update. They show which program holds the folder open in normal operation. They do not prove which handle survived into the failed update.

Workaround that avoids the failure

Install the update with winget while the app is closed, rather than accepting the in-app update:

winget upgrade --id Anthropic.Claude

Note for anyone reading this thread and trying the obvious workaround first: quitting from the system tray before the update is reported not to be enough (#84962).