[BUG] Claude Desktop (Windows MSIX) silently becomes Modified, NeedsRemediation mid-session with no deployment operation in the AppXDeploymentServer log

Status Closed — duplicate
Reported on v2.1.222
Maintainer reply None cached
Activity 8 comments · opened Aug 5, 2026 · closed Aug 25, 2026

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?

I had the Claude desktop working very well until the latest update. From that moment on, the app wont remain functional and keeps breaking after a few minutes of work. And after break, it wont repair and the only solution is to fully remove it, reinstall it and it happens again. I went through full rectifying procedure with Claude.ai to fix it and it never fixed and Claude actually gave up and asked me to file the issue here.

What Should Happen?

Claude desktop app should just keep working without breaking (total shutdown which requires full uninstallation and reinstallation)

Error Messages/Logs

Steps to Reproduce

Ruled out:
Auto-updater — disableAutoUpdates = 1 in HKLM:\SOFTWARE\Policies\Claude; version never changed
CoworkVMService file locks — log shows TerminateSingleService and service termination succeeding cleanly
Windows cumulative update — KB5101711 installed 7/30, app worked normally for a week after
Defender — no detections on Claude or WindowsApps; Controlled Folder Access disabled
Disk — healthy, no NTFS/disk/stornvme errors in System log
DISM /RestoreHealth and sfc /scannow — both run, both clean, no durable effect
File deletion — package folder present and intact after failure

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.222

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

4 Comments

eliminated · 25 days ago

I'm having the same issue as well, hope the dev can fiax this.

abuba200611-cmd · 22 days ago

I'm experiencing the exact same issue on Windows. Claude Desktop works fine initially, then fails with "Can't open this app" mid-session — specifically when Claude Code triggers browser automation to interact with a website.

I've tried:

  • Full uninstall + reinstall (multiple times, including a fresh 246MB installer)
  • Removing the AppX package via PowerShell (Get-AppxPackage -AllUsers Claude | Remove-AppxPackage -AllUsers) as admin
  • Freeing disk space
  • Restarting the PC after each attempt

Each time, it works briefly after reinstall, then breaks again — sometimes seemingly at random. This strongly suggests a bug in how Claude Desktop (MSIX) handles being invoked/communicated with by Claude Code, rather than a local installation issue.

intro-tan · 13 days ago

Same issue here. Reproduced on a different environment, which may help narrow the cause.

Environment

  • Claude Desktop 1.30096.5.0 (Claude_1.30096.5.0_x64__pzs8sxrjxfjjc)
  • Windows 11 Pro for Workstations, build 10.0.26200
  • GPU: AMD Radeon RX 6950 XT (discrete, not integrated)
  • Installed via MSIX from claude.ai/download, elevated

Behavior
Package reverts to Modified, NeedsRemediation immediately on first launch after a clean install. The window renders briefly (I can see the UI), then the app exits. Every subsequent launch shows the Windows "Can't open this app / select Repair" dialog.

Ruled out

  • Full uninstall + reboot + reinstall, repeated several times — same result every time
  • Add-AppxPackage -DisableDevelopmentMode -Register AppXManifest.xml — completes without error, Status unchanged
  • Settings > Repair and Reset — both fail with "We couldn't repair/reset this app. Try again in a bit."
  • VirtualMachinePlatform enabled; CoworkVMService confirmed Running
  • DISM /RestoreHealth and sfc /scannow — both clean, no effect
  • Defender: real-time protection on, tamper protection on, no quarantine entries for Claude or WindowsApps; no third-party AV
  • Disk: 745 GB free on C:
  • VMware services stopped as a test — no change
  • Launching with --disable-gpu — no change (likely not the GPU-crash variant reported in #82967 / #83028, given the discrete GPU)

Logs
AppXDeploymentServer/Operational reports the deployment as fully successful (Deployment Add operation ... finished successfully), with no errors. Package still lands in Modified, NeedsRemediation.

cowork-service.log shows the service starting cleanly — signature verification passes (Anthropic, PBC), HCS/HCN DLLs load, named pipe server listening, Service ready. The only warning:

intro-tan · 13 days ago

Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.

Application event log has the same:

Claude VM Service: failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access is denied.

Note the difference from the reports above: for me it fails on the very first launch after a clean install, not after minutes of use. Deployment reports success, so the installer never surfaces the broken state.

Related: #85887, #83932, #81747, #82967, #83028

Showing cached comments. Read the full discussion on GitHub ↗