[BUG] Windows: Claude Desktop MSIX package reverts to Modified, NeedsRemediation within minutes of clean install; Repair impossible due to CoworkVMService
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?
Summary
On Windows 11, the Claude Desktop MSIX package (Claude 1.26832.0.0) enters a Modified, NeedsRemediation state within minutes of a clean install and the app fails to launch. Every non-destructive remedy fails. Reproduced across three separate clean installs over four days.
Steps to reproduce
- Install Claude Desktop for Windows from claude.com/download
- Use the app normally (Cowork and Code sessions)
- Within minutes to hours, the app fails to launch with the Windows MSIX error directing the user to Settings > Apps > Advanced options > Repair
Get-AppxPackage *laude* | Select StatusreturnsModified, NeedsRemediation
Why Repair cannot succeed
CoworkVMService runs as SYSTEM with Automatic startup. Observed behaviour:
- Stopping the service via
Stop-Service CoworkVMService -Forceworks, but the service restarts during the repair operation itself, so Repair reports "We couldn't repair this app because it's currently running" even when the service is confirmedStoppedimmediately before clicking Repair. Set-Service CoworkVMService -StartupType Manualfails withAccess is deniedeven from an elevated administrator prompt, apparently due to a hardened service security descriptor. The user therefore cannot prevent the restart.- On the attempt where the service stayed down, Repair failed with "We couldn't repair this app. Try again in a bit."
Add-AppxPackage -Register AppXManifest.xmlcompletes without error but leaves Status unchanged atNeedsRemediation.
Net effect: the only remaining remedy is removing the package. Remove-AppxPackage -PreserveApplicationData fails with HRESULT 0x80073CFA because that flag only applies to development-mode deployments, so removal necessarily discards the app data container.
Impact
Removing the package destroys the working-directory bindings for existing sessions. After reinstall, every session prompts "Select folder for local session" before it will run. No warning is presented that following the remedy Windows itself recommends will have this effect.
Latest reinstall stayed functional for approximately 45 seconds before returning to NeedsRemediation.
Environment
- Windows 11 (build 26100)
- Claude Desktop
Claude_1.26832.0.0_x64__pzs8sxrjxfjjc - Windows Defender only; no third-party antivirus; protection history shows no quarantine entries for Claude or WindowsApps
vmcomputeandhnsboth Running- Single user session (
query userconfirms no second session) - Deployment ActivityId from a failed removal:
05569a82-2688-0007-a8c0-aa058826dd01
Requests
- Confirm whether
CoworkVMServicebeingAutomaticwith a restrictive security descriptor is intended, given it makes the documented Repair path unusable. - Provide a supported non-destructive recovery path for
NeedsRemediation. - Warn users before package removal that working-directory bindings will be lost.
What Should Happen?
someone should get back to me instead of ignoring me
Error Messages/Logs
Steps to Reproduce
it shuts down in the middle of stuff
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Claude Desktop for Windows 1.26832.0.0 Package: Claude_1.26832.0.0_x64__pzs8sxrjxfjjc
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗