Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Claude Desktop (Windows MSIX, 1.32885.1.0) installs cleanly and verifies as
Status: Ok. A single launch flips the package to "Modified, NeedsRemediation".
The app window never appears. Windows Repair and Reset both fail.

The transition leaves no trace in any Windows log — not the Application log,
not AppXDeploymentServer/Operational, not Get-AppxLog. No claude.exe
Application Error, no WER report, no crash dump.

Full removal + reinstall restores Ok, and the next launch breaks it again.
An unbounded loop. Cowork is unusable as a result.

What Should Happen?

Launching the app should not invalidate its own package. Status should remain
Ok after launch, and Cowork should start.

If Windows does mark the package Modified, something should log why — currently
nothing does.

Error Messages/Logs

Get-AppxPackage -Name Claude   →  Status: Ok                         (before launch)
[launch once]
Get-AppxPackage -Name Claude   →  Status: Modified, NeedsRemediation (after launch)

Microsoft-Windows-AppModel-Runtime/Admin:
  17:24:44  210  Created Desktop AppX container for Claude_1.32885.1.0_x64__pzs8sxrjxfjjc
  17:24:44  201  Created process 6220 for Claude_pzs8sxrjxfjjc!Claude  [LaunchProcess]
  17:24:51  217  Destroyed Desktop AppX container

cowork-service.log (identical every session — configure never arrives):
  Claude VM Service starting...
  Waiting for configuration from app via 'configure' method...
  Service ready. Listening on \\.\pipe\cowork-vm-service

Steps to Reproduce

Reproduction
Clean removal: Remove-AppxPackage -AllUsers + Remove-AppxProvisionedPackage, reboot, verify both empty
Install via Claude Setup.exe as Administrator
Before launching: Get-AppxPackage -Name Claude → Status: Ok
Launch Claude Desktop once. Window does not appear.
Get-AppxPackage -Name Claude → Status: Modified, NeedsRemediation
Settings → Advanced options → Repair → "We couldn't repair this app. Try again in a bit."

100% reproducible across many cycles.

Evidence
Install succeeds
17:23:56 Event 400 Deployment Add operation ... finished successfully.
17:23:56 Event 613 Overall time: 25188 ms
Hardlinking evaluation cost: 235 ms
Stage required cost: 20906 ms
Machine register cost: 843 ms
17:23:56 Get-AppxPackage → Status: Ok

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.24012.9.0

Claude Code Version

2.1.231 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

[BUG] Claude Desktop (Windows MSIX) transitions from Ok to Modified, NeedsRemediation on first launch, with no deployment event in any Windows log

Preflight

• I have searched existing issues
• This is a single bug report
• Using the latest Claude Desktop release (1.32885.1.0)

Summary

Claude Desktop installs cleanly and verifies as Status: Ok. A single launch flips the package to Modified, NeedsRemediation. Windows Repair and Reset both fail. Full removal and reinstall restores Ok, and the next launch breaks it again — an unbounded loop.

The transition leaves no trace in any Windows log: not the Application log, not AppXDeploymentServer/Operational, not Get-AppxLog. No claude.exe Application Error, no WER report, no crash dump.

Cowork is the reason I need the desktop app, so Claude web is not a workaround.

Environment

Machine-specific anomaly

C:\ProgramData\Microsoft\Windows\AppRepository retains stale manifests:

Claude_1.24012.1.0_x64__pzs8sxrjxfjjc.xml   2026-07-23 23:14
Claude_1.24012.9.0_x64__pzs8sxrjxfjjc.xml   2026-07-24 20:56
Claude_1.32885.1.0_x64__pzs8sxrjxfjjc.xml   2026-08-19 17:23

The two 1.24012.* entries date to the interrupted-update window and have survived every Remove-AppxPackage -AllUsers and Remove-AppxProvisionedPackage. Since MSIX staging hardlinks against content it believes is already present, stale repository state may cause staging to skip content it thinks exists — which would explain why reinstalling never helps.

This was tested and ruled out. See below.

Windows in-place repair upgrade — performed, did not fix

To eliminate machine-side servicing corruption, I ran a full in-place repair upgrade using the official Windows 11 25H2 en-US ISO (SHA-256 verified against Microsoft's published hash), with "Keep personal files and apps".

Before the upgrade, Claude was fully removed: Remove-AppxPackage -AllUsers, Remove-AppxProvisionedPackage, and deletion of C:\ProgramData\Claude and %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc. Only the two stale 1.24012.* manifests remained in the AppRepository at that point.

After the upgrade:

Get-ChildItem 'C:\ProgramData\Microsoft\Windows\AppRepository' -Filter '*Claude*' -Force
# → empty. Both stale manifests cleared. AppRepository rebuilt.

Then a clean install via Claude Setup.exe as Administrator:

Get-AppxPackage -Name Claude   →  Status: Ok                        (before launch)
[launch once]
Get-AppxPackage -Name Claude   →  Status: Modified, NeedsRemediation (after launch)

Identical failure on a rebuilt servicing stack and a clean AppRepository. The stale-manifest hypothesis is disproven, and with it every machine-side explanation available: antivirus, GPU driver, HVCI, Smart App Control, ACLs and ownership, Windows servicing updates, disk space, code-integrity catalogs, and repository corruption have all now been eliminated by direct test on this machine.

Remediation attempted (all unsuccessful)

Settings → Repair · Settings → Reset · Remove-AppxPackage -AllUsers + reinstall · Remove-AppxProvisionedPackage · Add-AppxPackage -Register AppxManifest.xml · Add-AppxProvisionedPackage -Online -SkipLicense -Regions all · install via Claude Setup.exe as admin · install via raw .msix · reboots between every attempt · GPU driver update (31.0.101.1999 → 31.0.101.2141) · deletion of C:\ProgramData\Claude and per-package LocalCache · Windows in-place repair upgrade (25H2 en-US ISO, keep files and apps) · verified VirtualMachinePlatform enabled, vmcompute / hns / CoworkVMService running

Expected behaviour

1. Launching the app should not invalidate its own package.
2. If Windows marks the package Modified, something should say why — currently nothing does.
3. The installer should detect post-install Modified, NeedsRemediation rather than treating deployment 0x0 as success.
4. AppxMetadata\CodeIntegrity.cat is referenced by Code Integrity at every launch but ships absent. Either include it or confirm it is intentional.
5. The packaged service should be able to configure its own SCM recovery actions.

Related

• [BUG] Claude Desktop (Windows MSIX) silently becomes Modified, NeedsRemediation mid-session with no deployment operation in the AppXDeploymentServer log #84333 — silent Modified, NeedsRemediation with no deployment operation logged (closest match)
• Claude Desktop MSIX crash on Intel integrated GPU during browser pane use — reproducible, no workaround available #83028 — same package state on Intel integrated graphics
• [BUG] Claude Desktop Windows installer fails with AddPackage HRESULT 0x80073CF6 — package stuck in NeedsRemediation after "successful" install #81747 — install "succeeds", package stuck in NeedsRemediation, Repair and Reset both fail
• [BUG] Windows auto-update deploys into running claude.exe + CoworkVMService (0x80073CF9/0x80073D02), app left unlaunchable (NeedsRemediation); recovery churn incl. dev-only PreserveApplicationData (0x80073CFA) — twice in one day #83932 — auto-update deploying into running claude.exe / cowork-svc.exe
• [BUG] Windows Server 2025: cumulative update KB5094125 (OS build 26100.32995) breaks MSIX registration — package lands "Modified, NeedsRemediation" despite deployment reporting success; removing the LCU fixes it #70700 — same end state traced to a Windows LCU (not applicable here; timeline rules it out)

Additional

Full logs available on request: AppXDeploymentServer/Operational, AppModel-Runtime/Admin, CodeIntegrity/Operational, cowork-service.log, and the coworkd per-user log covering the last working session.

Disk note: C: had 16.9 GB free of 269 GB during the failing attempts (now 32.4 GB). Recorded in case staging headroom is relevant, though the failure occurs after staging completes successfully.