Claude Desktop repeatedly enters "Modified, NeedsRemediation" state and fails to launch — persists even after full OS reinstall (Windows MSIX)

Same issue here on Windows 11 x64, also with package version 1.24012.x.

The app crashed on its own while Claude Code sessions were running, then refused to relaunch with the same repair dialog (Spanish UI: "No se puede abrir esta página. Deberás volver a opciones avanzadas para Claude y seleccionar Reparar").

Repair in Windows Settings fails. Standard uninstall + reinstall from claude.ai/download does NOT fix it — the app installs but still shows the same dialog on launch.

What worked for me:

1. Get-Process claude | Stop-Process -Force (and close Chrome/Brave first — the Claude for Chrome native host holds a lock on LocalCache\Roaming\Claude\ChromeNativeHost that blocks folder removal)
2. Get-AppxPackage -Name Claude | Remove-AppxPackage
3. Move %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc out of the way
4. Reinstall as administrator from https://claude.ai/api/desktop/win32/x64/msix/latest/redirect

Without step 3 the reinstall fails with:
"App installation failed with error message: An internal error occurred with error 0x80073D05."

It then broke again the same day, requiring the full sequence a second time.

Notes matching your report: sfc /scannow shows no integrity violations, and my username path is ASCII-only, so this isn't the non-ASCII path issue from #35366.

Additional impact worth flagging: the Claude Code window/tab layout is lost on every recovery, since it lives inside the MSIX package data folder that has to be removed. Sessions themselves survive in ~/.claude and can be recovered with claude --resume, but the workspace arrangement has to be rebuilt by hand each time.

I'm experiencing the exact same issue. Confirmed reproducible on two
different PCs using the same Microsoft account, which further rules
out local machine/profile corruption. Also observed:

• Get-AppxPackage status: Modified, NeedsRemediation
• Test-Path "HKCU:\Software\Classes\ActivatableClasses\Package\Claude_pzs8sxrjxfjjc"

returns False even after manually clearing the StateChange registry key

• AddPackage failed with HRESULT 0x80073D19 on one install attempt

Disclosure: the investigation and this write-up were done by Claude, working on my machine under my direction. The failures, the system, and the calls about what to test are mine.

Environment: Windows 11 build 26200 x64, personal (non-Intune), same package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc, 7 forced reinstalls over four days. Like yours: installs clean, verifies Ok, runs fine for tens of minutes, then degrades in place with no user action. Only Remove-AppxPackage plus a clean reinstall recovers it; re-registration never holds.

The payload is provably unchanged when the package is declared Modified

• SHA256 of all 2182 files captured while Status: Ok.
• Re-hashed later, still Ok: byte-identical, 2182 of 2182.
• After a failure: file count identical, and no file with a LastWriteTime later than the install timestamp.

Nothing on disk changed. Whatever sets the Modified bit is setting a flag, not reacting to a modified payload.

The transition is never logged, and no deployment operation was running

AppModel-Runtime/Admin Id 68 records status transitions. Relative to the install:

| time | Id 68 status |
|---|---|
| T+0 | 0x0 → 0x80000 (install) |
| T+1s | 0x80000 → 0x0 (healthy) |
| (never logged) | 0x0 → 0x2 |
| T+45m | 0x2 → 0x80002 (removal begins) |

At removal the log reports previous status = 0x2, but no event ever recorded the package entering it. (Get-AppxPackage said Modified at that point, which is how I'm reading 0x2 — that mapping is inferred.) For the same window: no transition event in AppModel-Runtime/Admin, zero Claude events at all in AppXDeploymentServer/Operational between install and removal, and nothing in AppXDeployment/Operational.

This is the key difference from the update-collision reports in this cluster (#63722, #81180, #49655, #73694, #76357). Those all show a deployment operation colliding with the service holding handles — 0x80073D02, events 404/638/9641/9648/9650. Here no deployment operation was running at all and the package still went Modified. So the service holding handles into WindowsApps isn't only an update blocker; something flags the package outside deployment entirely.

Not a crash

The AppX container created at T+4m was destroyed only at T+45m, by the uninstall — no Id 217 in between. Zero Crashpad dumps, zero WER reports in 14 days, zero Application Error events across 45 days.

A reproducible trigger, and a control

%LOCALAPPDATA%\npm-cache\_logs\ records one log per npm invocation with exact argv (logs-max defaults to 10, so it evicts fast — snapshot it). Three consecutive app sessions:

| session | child processes | outcome |
|---|---|---|
| A | npm script starting 6 concurrent Vite dev servers | app dies ~100s later, 0x3CFC |
| B | none | orderly beforeQuit, package stayed Ok |
| C | same 6-server script | package Modified ~13 min later |

Both corruption events follow long-running child processes spawned from inside the app (via its Bash tool). The session in between, with no child processes, quit normally and did not corrupt.

Control: the identical workload started from a separate external PowerShell window, app running normally — 6 Vite servers, 14 node processes, 848 MB total RSS — ran clean for 14.4 minutes, past both failure points. Package stayed Ok, free RAM flat at 3.1–3.3 GB. Same load, different launcher, no failure. That rules out resource exhaustion and points at the spawning path rather than the workload.

This is a trigger, not the cause — #63722 is ~1,000 Intune devices failing at boot with no such processes. But it's a reproducible one, which I don't think anyone else in this cluster has, so it may be the cheapest path to a repro.

Unproven mechanism, offered only because it's the one candidate that fits "no file changed": processes spawned by the app become children inside its AppX container and hold handles into WindowsApps for their lifetime, so tearing the container down with children still live may leave the package flagged with no disk change. If that's right, detaching long-running Bash-tool children from the container would be the fix.

Ruled out here, with evidence

| Hypothesis | Evidence against |
|---|---|
| Payload modified, files added or removed | 2182 SHA256 identical; file count identical; no post-install LastWriteTime |
| Antivirus | Defender active (productState 397568), zero detections, zero relevant events |
| Auto-update collision | No deployment events in the failure window at all |
| The bundled VM / VHDX | VM disks live in LocalCache\...\claudevm.bundle\; the in-package smol-bin.x64.vhdx is only a template. VHDMP-Operational shows the VM wasn't running during the window |
| Resource exhaustion | Control test above |
| System file corruption | DISM /RestoreHealth repaired 1501 items, sfc /scannow clean; broke again anyway |
| Re-registration as a fix | Auto-remediation ran 4× (Id 400, Remove/StageUserData/Register all "finished successfully"); Status stayed Modified |
| Reboot, or Settings → Repair | Neither has ever helped |

One open lead

AppXDeploymentServer/Operational Id 1230 fires on every install reporting hardlinks with no package in the repository. fsutil hardlink list on the named files returns six paths each, spanning Microsoft.M365Companions and four orphaned Claude version directories still sitting unregistered in WindowsApps. All four predate my first failure by 3–10 days, so they aren't debris from the reinstall cycle — they look like ordinary per-version auto-update residue. Whether an integrity check can be tripped via a sibling package's hardlinked path isn't something I could test.

Note for anyone else gathering data on this

Every reinstall wipes LocalCache, including the app's own main.log and the user's MCP configuration. The recovery destroys the evidence for the incident that caused it, which is likely part of why this cluster has so many reports and so little forensic detail. Preserving main.log outside the package before recovering is worth doing.

---

Net of all of it: the package can reach Modified with no deployment operation in flight and not one byte changed on disk. Whatever sets that bit does so without logging it anywhere I could find, and at least one reproducible trigger is long-running child processes spawned inside the app's own container.

Independent corroboration of @Katinkabeat's child-process trigger, from a different workload.

Environment: Windows 11 x64, same package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc, ASCII-only user path, ~8 forced reinstalls over four days. Same signature: installs clean, verifies Ok, runs fine, then degrades in place with no user action; only Remove-AppxPackage plus clean reinstall recovers it.

Timeline that matches the trigger:
My workflow runs 6 concurrent Claude Code sessions, and had done so for weeks with zero problems. The failures began within a day of adding a pipeline step that spawns long-running Python child processes from inside the app via the Bash tool (image processing, ~30s of CPU per invocation, run in batches). Nothing else about the workload changed. Same 6 sessions, same volume, same machine — the only new variable was long-running children spawned inside the container.

Consistent with the control test:
I moved session launching out of Claude Desktop entirely and now run Claude Code from VS Code's integrated terminal. Identical workload, identical 6 concurrent sessions, identical Python child processes. No failures since. That's the same "same load, different launcher" result reported above, from a different workload and a different launcher.

Ruled out on my side, with evidence:

• Memory pressure: main.log's own [process-memory] telemetry showed 16.7 GB free of 32 GB one minute before a failure, no decline.
• GPU driver: a failure occurred immediately after a clean NVIDIA 610.88 install (RTX 5060 Ti, "perform clean installation" checked).
• The workload itself: I disabled the image-processing step entirely; the package still went Modified afterward while launching from Desktop.
• Antivirus: Defender only, zero detections in the relevant window.
• Repair / re-registration: Settings > Repair fails outright; Add-AppxPackage -Register -ForceUpdateFromAnyVersion reports success while Get-AppxPackage still returns "Modified, NeedsRemediation".
• Deployment collision: AppXDeploymentServer/Operational shows no Claude deployment events in my failure windows either.

One difference from the report above worth noting:
My main.log ends every failure with an explicit GPU process crash, same exit code each time:
"GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }"
In two of three captured failures this is preceded within seconds by "[Preview] Created browser preview" / "[Preview] Created session preview context", and by a jump in Electron process count (10 → 26 in one case) as sessions start. @Katinkabeat reports zero crash artifacts, so this may be a second path to the same end state, or the GPU process death may be a symptom of container teardown rather than a cause. I can't distinguish those with what I have.

Seconding the note about evidence destruction: every reinstall wipes LocalCache including main.log. I only captured these because I started copying main.log out of the package before each recovery. Anyone else hitting this — copy %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\main.log somewhere safe BEFORE recovering.

Happy to provide the three full main.log captures if useful.