[BUG] Windows (MSIX): update fails with 'Another program is currently using this file' — app unlaunchable until reboot (every update)
Bug Report: Claude Desktop (Windows) — Update fails with "Another program is currently using this file"; app unlaunchable until reboot
Product: Claude Desktop for Windows (Microsoft Store / MSIX install)
Installed version at time of report: 1.20186.0.0 (Claude_1.20186.0.0_x64__pzs8sxrjxfjjc)
OS: Windows 11
Reproducibility: 100% — occurs on every update since the app was first installed (20+ times on this machine)
Summary
Each time Claude Desktop applies an update, the app closes to update and then fails, showing the Windows dialog:
"Another program is currently using this file." C:\Program Files\WindowsApps\Claude_1.20186.0.0_x64__pzs8sxrjxfjjc\...
The app then will not relaunch — retrying even 30+ minutes later gives the same error. Only a full Windows restart resolves it, after which the app opens on the new version.
Verified root cause (diagnosed live on the affected machine)
After the app "closes" for the update, two things keep running and hold file locks on the MSIX package directory, which blocks the update from applying and the app from relaunching:
CoworkVMService— a Windows service (DisplayName "Claude", StartType Automatic, runningcowork-svc.exe) belonging to the Claude Cowork feature (recently GA on Windows). It stays Running after the app window closes.- ~15 lingering
Claude.exeprocesses from the package (C:\Program Files\WindowsApps\Claude_1.20186.0.0_x64__pzs8sxrjxfjjc\app\Claude.exe) that do not exit when the app closes for update.
Because CoworkVMService is a persistent auto-start service independent of the app window, closing the app or waiting does not release the locks — only a reboot restarts the service and clears the stuck processes. This exactly matches the "reboot is the only fix" symptom.
Evidence collected (Get-AppxPackage / Get-Process / Get-Service):
Get-Service CoworkVMService→ Status: Running, StartType: Automatic, DisplayName: Claude- ~15
Claude.exeprocesses alive under the WindowsApps package path after the app had closed for update - Package
Claude_1.20186.0.0_x64__pzs8sxrjxfjjc, Status: Ok
Steps to reproduce
- Claude Desktop downloads an update and closes to apply it.
- Error appears: "Another program is currently using this file" (WindowsApps package path).
- Reopening the app (immediately or after 30+ minutes) shows the same error.
- A Windows restart fixes it; the app opens on the new version.
Expected behavior
The updater should stop CoworkVMService and terminate all package-owned Claude.exe processes (release every file handle on the MSIX package) before applying the update, then relaunch cleanly. No reboot should ever be required.
Impact
- App is completely unusable until a full Windows restart — on every update.
- Interrupts active work each update cycle and forces a laptop reboot.
Suggested fix
Make the update/relaunch flow: (1) signal CoworkVMService to stop and wait for cowork-svc.exe to exit, (2) confirm all Claude.exe helper processes have terminated, (3) apply the MSIX update, (4) restart the service and app. This guarantees no file locks survive into the update.
Manual workaround for affected users (no reboot needed)
When the error appears, release the locks instead of rebooting:
- Stop the service:
Stop-Service -Name CoworkVMService -Force - End all
Claude.exeprocesses from the WindowsApps package (Task Manager → end eachClaude.exe, or PowerShell). - Relaunch Claude Desktop — the update applies and the app opens normally.
(This is a workaround, not a fix — the updater should handle it automatically.)
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗