Claude Desktop (Windows/MSIX) recurring "Another program is currently using this file" on auto-update, requires OS reboot to recover — affects multiple users

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?

Environment

OS: Windows 11 Pro, build 10.0.26200 (64-bit)
Install type: MSIX package, Claude_<version>_x64__pzs8sxrjxfjjc
Affected versions observed in one day: 1.37937.3.0 → 1.40609.1.0 → 1.44121.4.0 (auto-updated multiple times same day)
Affects multiple users on the same org deployment, not isolated to one machine

Symptom
Every morning (and repeatedly through the day, roughly once per auto-update cycle), a Windows dialog appears:

C:\Program Files\WindowsApps\Claude_<version>... — "Another program is currently using this file."

Settings → Apps → Installed apps → Claude → Repair also fails with: "We couldn't repair this app because it's currently running. Close the app and try again" — even immediately after closing all visible Claude windows.

What we ruled out before concluding this is an app bug

taskkill /F /IM Claude.exe /T reports "process not found" at the exact moment the dialog is showing — so no live process is holding the file under that name.
Despite that, within seconds a fresh Claude.exe process tree (new PIDs, full set of Electron child processes — GPU, crashpad-handler, renderer, utility services) is running again, confirming the app is being relaunched automatically, not stuck.
Checked and eliminated as causes:
"Run on startup" toggle (Settings → General) — off, but also inconsistent (reappeared as "on" after being turned off once — separate cosmetic/persistence bug worth noting)
"System tray" toggle ("Keep Claude running in the system tray") — turned off
No Windows Scheduled Task for Claude (Get-ScheduledTask)
No HKCU\...\CurrentVersion\Run registry entry for Claude
Waiting up to 1 hour after the dialog appears does not resolve it; Repair still fails afterward.
Only reliable recovery found so far: full OS restart.

Suspected root cause
The update/deployment flow appears to close the running app to swap package files, then relaunch it (possibly via RegisterApplicationRestart or Restart Manager as part of MSIX servicing) before the file swap/registration has fully committed — causing a race where the relaunch collides with the in-progress update, and leaving the package manager believing the app is still "running" even when no process is found by name.

Impact
Multiple team members require a full machine restart most mornings to get Claude Desktop working, since neither closing the app, killing the process, nor Repair recovers it.

Requested

Investigation into the update/relaunch sequencing for the Windows MSIX build.
If possible, a way to disable the "reopen automatically after update" behavior, or a fix to sequence the relaunch after the file swap fully commits.

What Should Happen?

Environment

OS: Windows 11 Pro, build 10.0.26200 (64-bit)
Install type: MSIX package, Claude_<version>_x64__pzs8sxrjxfjjc
Affected versions observed in one day: 1.37937.3.0 → 1.40609.1.0 → 1.44121.4.0 (auto-updated multiple times same day)
Affects multiple users on the same org deployment, not isolated to one machine

Symptom
Every morning (and repeatedly through the day, roughly once per auto-update cycle), a Windows dialog appears:

C:\Program Files\WindowsApps\Claude_<version>... — "Another program is currently using this file."

Settings → Apps → Installed apps → Claude → Repair also fails with: "We couldn't repair this app because it's currently running. Close the app and try again" — even immediately after closing all visible Claude windows.

What we ruled out before concluding this is an app bug

taskkill /F /IM Claude.exe /T reports "process not found" at the exact moment the dialog is showing — so no live process is holding the file under that name.
Despite that, within seconds a fresh Claude.exe process tree (new PIDs, full set of Electron child processes — GPU, crashpad-handler, renderer, utility services) is running again, confirming the app is being relaunched automatically, not stuck.
Checked and eliminated as causes:
"Run on startup" toggle (Settings → General) — off, but also inconsistent (reappeared as "on" after being turned off once — separate cosmetic/persistence bug worth noting)
"System tray" toggle ("Keep Claude running in the system tray") — turned off
No Windows Scheduled Task for Claude (Get-ScheduledTask)
No HKCU\...\CurrentVersion\Run registry entry for Claude
Waiting up to 1 hour after the dialog appears does not resolve it; Repair still fails afterward.
Only reliable recovery found so far: full OS restart.

Suspected root cause
The update/deployment flow appears to close the running app to swap package files, then relaunch it (possibly via RegisterApplicationRestart or Restart Manager as part of MSIX servicing) before the file swap/registration has fully committed — causing a race where the relaunch collides with the in-progress update, and leaving the package manager believing the app is still "running" even when no process is found by name.

Impact
Multiple team members require a full machine restart most mornings to get Claude Desktop working, since neither closing the app, killing the process, nor Repair recovers it.

Requested

Investigation into the update/relaunch sequencing for the Windows MSIX build.
If possible, a way to disable the "reopen automatically after update" behavior, or a fix to sequence the relaunch after the file swap fully commits.

Error Messages/Logs

Steps to Reproduce

Environment

OS: Windows 11 Pro, build 10.0.26200 (64-bit)
Install type: MSIX package, Claude_<version>_x64__pzs8sxrjxfjjc
Affected versions observed in one day: 1.37937.3.0 → 1.40609.1.0 → 1.44121.4.0 (auto-updated multiple times same day)
Affects multiple users on the same org deployment, not isolated to one machine

Symptom
Every morning (and repeatedly through the day, roughly once per auto-update cycle), a Windows dialog appears:

C:\Program Files\WindowsApps\Claude_<version>... — "Another program is currently using this file."

Settings → Apps → Installed apps → Claude → Repair also fails with: "We couldn't repair this app because it's currently running. Close the app and try again" — even immediately after closing all visible Claude windows.

What we ruled out before concluding this is an app bug

taskkill /F /IM Claude.exe /T reports "process not found" at the exact moment the dialog is showing — so no live process is holding the file under that name.
Despite that, within seconds a fresh Claude.exe process tree (new PIDs, full set of Electron child processes — GPU, crashpad-handler, renderer, utility services) is running again, confirming the app is being relaunched automatically, not stuck.
Checked and eliminated as causes:
"Run on startup" toggle (Settings → General) — off, but also inconsistent (reappeared as "on" after being turned off once — separate cosmetic/persistence bug worth noting)
"System tray" toggle ("Keep Claude running in the system tray") — turned off
No Windows Scheduled Task for Claude (Get-ScheduledTask)
No HKCU\...\CurrentVersion\Run registry entry for Claude
Waiting up to 1 hour after the dialog appears does not resolve it; Repair still fails afterward.
Only reliable recovery found so far: full OS restart.

Suspected root cause
The update/deployment flow appears to close the running app to swap package files, then relaunch it (possibly via RegisterApplicationRestart or Restart Manager as part of MSIX servicing) before the file swap/registration has fully committed — causing a race where the relaunch collides with the in-progress update, and leaving the package manager believing the app is still "running" even when no process is found by name.

Impact
Multiple team members require a full machine restart most mornings to get Claude Desktop working, since neither closing the app, killing the process, nor Repair recovers it.

Requested

Investigation into the update/relaunch sequencing for the Windows MSIX build.
If possible, a way to disable the "reopen automatically after update" behavior, or a fix to sequence the relaunch after the file swap fully commits.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.44121.4.0

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_