[BUG] Windows MSIX auto-update corrupts package (Modified, NeedsRemediation) - app unlaunchable, Repair fails
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?
Claude Desktop on Windows refuses to launch: "You'll need to go to advanced options and select Repair". Get-AppxPackage shows Status: Modified, NeedsRemediation after a background auto-update (1.25927.0.0 -> 1.26832.0.0). This happened 5+ times between Aug 5-7 2026 (twice in one day). Smart App Control is OFF, so it is not SAC blocking. Settings > Repair fails ("Could not repair the app. Try again."), Reset does not help, and re-registering via Add-AppxPackage -DisableDevelopmentMode -Register AppXManifest.xml runs without error but Status stays Modified. The only recovery is: kill claude/cowork processes, Remove-AppxPackage, reboot (skipping the reboot causes 0x80073CF6 on reinstall), then fresh install from claude.com/download - which lasts only until the next auto-update breaks it again.
What Should Happen?
Auto-update should never leave the MSIX package in Modified/NeedsRemediation state. The updater should defer until the app and background services are fully stopped (or self-heal a modified package), so the app keeps launching after every update.
Error Messages/Logs
Get-AppxPackage *Claude* -> Status : Modified, NeedsRemediation
Settings > Advanced options > Repair -> "Could not repair the app. Try again."
Reinstall without reboot -> Installation failed: AddPackage failed with HRESULT 0x80073CF6Steps to Reproduce
- Install Claude Desktop (MSIX) from claude.com/download on Windows 11 x64
- Use it normally and leave it running in the tray for a day or two
- A background auto-update runs
- Try to launch the app: Windows blocks it; Get-AppxPackage shows Modified, NeedsRemediation
Claude Model
_No response_
Is this a regression?
Yes, this worked in a previous version
Last Working Version
1.25927.0.0 (each version works until its own auto-update corrupts it)
Claude Code Version
1.26832.0.0 (Claude Desktop MSIX, Claude_1.26832.0.0_x64__pzs8sxrjxfjjc)
Platform
Other
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Impact: effectively unusable for a non-technical user - requires a PowerShell uninstall + reboot + reinstall cycle every 1-2 days. Possibly related: #83932, #63397, #57221, #76357 (update deploying while claude.exe/CoworkVMService are still running).
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Independent confirmation of this exact failure pattern on Windows 11 x64.
Environment:
OS image version: 10.0.26200.8973
Claude Desktop: 1.26832.0.0
Package family: Claude_pzs8sxrjxfjjc
After Claude Desktop unexpectedly exited, PowerShell reported:
Name : Claude
Version : 1.26832.0.0
Status : Modified, NeedsRemediation
InstallLocation : C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc
The AppXDeploymentServer log shows the update from 1.25927.0.0 to 1.26832.0.0 occurring at 22:15:49 local time:
Finished resolving action lists. DeploymentRequest action lists: updateList:
Claude_1.25927.0.0_x64__pzs8sxrjxfjjc is updating to Claude_1.26832.0.0_x64__pzs8sxrjxfjjc.
The old package was moved into WindowsApps\Deleted and the new package registration reported success. Immediately afterward Windows logged:
error 0x80070015: Unable to notify pre-launch service for app Claude_pzs8sxrjxfjjc!Claude install/uninstall.
CoworkVMService events around the incident:
22:14:04 Claude VM Service stopped.
22:15:50 Claude VM Service starting.
22:31:21 Claude VM Service stopped.
At 22:31 and again at 22:34 Windows performed package repair and registration operations using RepairAppRegistrationOption and ForceTargetApplicationShutdownOption.
The AppX log explicitly says it attempted and successfully repaired ACLs on:
C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc
The subsequent Register operation reported "finished successfully."
Despite those successful registration and ACL repair events, Get-AppxPackage Claude continued to report:
Status : Modified, NeedsRemediation
One additional diagnostic caveat: I ran:
DISM /Online /Cleanup-Image /ScanHealth
Windows reported:
The component store is repairable.
The operation completed successfully.
I am currently running:
DISM /Online /Cleanup-Image /RestoreHealth
I am including this because component store corruption could be contributory on this machine. I am not claiming Claude caused that corruption.
The useful part for this issue is that the Claude failure, package update, CoworkVMService state changes, 0x80070015, repeated AppX remediation attempts, and persistent Modified, NeedsRemediation status all occurred in the same incident window.
I can provide the full AppX deployment event excerpt, DISM/CBS logs, or other sanitized logs if useful.
+1, confirming this on my end too. Same failure mode (Modified/NeedsRemediation after
background MSIX update, repair fails, only fix is kill processes + remove package + reboot
One detail that might narrow down the race condition: in my case the crash consistently
happens while Claude Code is actively executing an agentic task (file operations), not
just during idle background use. So the update deployment seems to be colliding with an
active claude.exe process specifically while it's doing work, not just "running in the
tray" — might point more precisely at what's failing to release the file lock.
Same issue here — still occurring on the latest version. Adding corroborating evidence from another affected machine.
Environment: Windows 11 Pro (build 26200), MSIX package
Claude_1.32352.0.0_x64__pzs8sxrjxfjjc.Three separate blow-ups on Aug 15 / 17 / 18 with 42 AppX deployment errors total in Event Viewer (
Microsoft-Windows-AppXDeploymentServer/Operational):0x80073D02(package in use),0x80073CF6(registration failure),0x80073CF0,0x80073CFF, plus the warning "file system entries for package Claude_pzs8sxrjxfjjc could not be cleaned up after reboot".Two log lines that point at the root cause (Claude's own components holding locks during package servicing):
EBUSY: resource busy or lockedcopyingchrome-native-host.exeout ofC:\Program Files\WindowsApps\Claude_....One data point that may help: on 1.32352.0.0 a plain PC reboot completed the pending install within ~1 minute — no uninstall/reinstall needed (the failed install at 10:35 succeeded at 10:37, right after the 10:36 reboot). So the lock-holder dies at reboot and the deployment retry then succeeds.
Currently working around it with
HKLM\SOFTWARE\Policies\Claude\disableAutoUpdates = 1.+1 for having the updater stop all Claude background services (VM service, native host) before servicing the package, and defer/retry gracefully instead of leaving the package in Modified/NeedsRemediation.