[BUG] Desktop 1.24012.9–1.25927.0 (Windows MSIX): package enters NeedsRemediation (0x3CFC) after opening the in-app browser pane — 3 reinstalls in one day

Got same problem, so annoying, here is what claude says:

Confirming this on a second machine, and adding evidence that narrows the cause, plus a
recovery path that does not require a full reinstall and does not lose app data.

Confirmation

Same failure, different hardware and locale:

| | |
|---|---|
| OS | Windows 11 Pro, 10.0.26200.8655 |
| Package | Claude_1.24012.9.0_x64__pzs8sxrjxfjjc |
| Claude Code | 2.1.219 bundled |
| SignatureKind | Developer (sideloaded MSIX) |
| Package Status | Ok before and after every incident |

Identical signature: 5× Microsoft-Windows-AppModel-Runtime/Admin Event ID 6,
0x3CFC (= 15612, ERROR_NEEDS_REMEDIATION), package field <NULL>, then Event ID 217
destroying the AppX container. Same 0x80070002 on Claude-<random>.msix, same
0x80073CFA on PreserveApplicationData.

One difference worth noting: no localhost and no dev server involved. Plain use of the
in-app browser pane is enough. So the trigger is the pane itself, not a local dev server or
anything the app spawns for it.

10 occurrences over two days, frequency increasing:

2026-07-29 18:54:47
2026-07-29 19:04:53
2026-07-30 14:19:19
2026-07-30 14:37:19
2026-07-30 14:41:58
2026-07-30 14:43:12
2026-07-30 14:51:32
2026-07-30 14:56:45
2026-07-30 15:25:31
2026-07-30 16:03:37

Recovery without a full reinstall (keeps your data)

This is the most useful part for anyone hitting this. Repair from Settings fails, but
Add-AppxPackage -Register succeeds — provided the packaged service is stopped too.

Claude ships a packaged Windows service, CoworkVMService, displayed in services.msc as
"Claude", running from app\resources\cowork-svc.exe. It does not stop when you
close the app window. While it runs, Repair fails with:

0x80073D02: Unable to install because the following apps need to be closed

That is what makes Repair look permanently broken. Stop the service as well and
re-registration succeeds:

Stop-Service CoworkVMService -Force
Get-Process claude -ErrorAction SilentlyContinue | Stop-Process -Force
Start-Sleep 3
Add-AppxPackage -Register "C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc\AppxManifest.xml" -DisableDevelopmentMode

Verified working: Deployment Register operation ... (AppxManifest.xml) finished successfully.
No reinstall, no data wipe.

Evidence that narrows the cause

1. Blocking auto-updates does not prevent it.
Set disableAutoUpdates = 1 (DWORD) in both HKCU\SOFTWARE\Policies\Claude and
HKLM\SOFTWARE\Policies\Claude. The app confirms it took effect:

[updater] Auto-updates disabled by enterprise policy
Managed MDM config detected { keys_set: [ 'disableAutoUpdates' ] }

The failure recurred 4 minutes later. So the dangling-staging-session theory needs
refining: no update or staging operation was running at the time of the failure.

2. The redeploy is the recovery, not the trigger. Millisecond ordering:

15:25:31.395  Event ID 6
15:25:31.396  Event ID 6
15:25:31.397  Event ID 6
15:25:31.399  Event ID 6
15:25:31.400  Event ID 6
15:25:31.637  Event ID 217: Destroyed Desktop AppX container
15:25:40+     RepairPackageOperation / Add / Register / Remove ...

Five process-creation failures within 5 ms, container destroyed 240 ms later, and the
deployment activity only starts ~9 seconds afterwards.

3. A full clean removal does not fix it.
Remove-AppxPackage -AllUsers, leftover %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc
deleted, stale %TEMP%\Claude-*.msix deleted, fresh package installed. The failure
recurred 4 minutes after the fresh install. Whatever state is bad either survives a
full removal or is recreated immediately.

4. Component store corruption exists but is not the cause.
sfc /scannow → [SR] Repairing 0 components.
DISM /Online /Cleanup-Image /RestoreHealth → repaired 2044 CSI FileFlags
corruptions (Total Repaired Corruption: 2044, All WCP store corruptions were fixed,
HRESULT = 0x00000000 - S_OK). Followed by reboot and successful re-registration.
Failure recurred anyway. Possibly related, since FileFlags corruption is file
attribute/security metadata — but not sufficient on its own.

5. Every Register has to repair the package ACLs (Event ID 649):

Trying to repair ACLs for \\?\C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc
ACLs repaired successfully. Register next time should succeed.

6. Integrity validation is being attempted on a package it does not apply to
(Microsoft-Windows-AppXDeploymentServer/Operational, Event ID 8107):

Illegal non-AppStore or non-AppInstaller package integrity validation attempted
for package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc. Flags: 0x0

7. Not graphics, not security software, not licensing services.
Ruled out independently, each with the failure still reproducing:
isHardwareAccelerationDisabled: true; per-app GPU preference pinned to the discrete GPU;
virtual display adapter disabled; GPU overlay disabled; no third-party AV
(root\SecurityCenter2 empty); fltmc filters shows Microsoft filters only; no
third-party Winsock LSPs; Get-ProcessMitigation -System all NOTSET; Smart App Control
off; ClipSVC, LicenseManager, AppXSvc, StateRepository all Running.

Note the app log line GPU process gone: { reason: 'crashed', exitCode: 101457950 } is
byte-identical across all 10 incidents including runs with hardware acceleration
disabled — it is the container teardown, not a graphics fault. Worth stating because it
sends people down the GPU path.

Data loss is narrower than reported — you can save most of it

Only the desktop app's Claude Code chat store is destroyed:

• ...\LocalCache\Roaming\Claude\claude-code-sessions — wiped
• ...\LocalCache\Roaming\Claude\local-agent-mode-sessions — survives (233 files retained here)
• %USERPROFILE%\.claude (CLI sessions, projects, settings, plugins) — never affected

(302 session files retained, going back six weeks)

So the CLI is a fully usable workaround with no data at risk, and everything except
claude-code-sessions can be backed up and restored around a reinstall.

Why nobody gets a crash dump

The app never faults — the OS declines process creation. That path produces no exception,
no WER report and no Crashpad minidump. Crashpad\reports stays empty; sentry\session.json
only marks the previous session abnormal with value: 'No message'. Anyone trying to debug
this by looking for a dump will find nothing, regardless of WER configuration.

Two requests

1. Where can 1.24012.1 be obtained? This report identifies it as the last good version, and

with disableAutoUpdates policy set a downgrade would actually stick. No older installer
is cached on disk once %TEMP%\Claude-*.msix is cleaned up.

1. Is there a setting or policy to disable the in-app browser pane entirely? The app is

completely stable as long as the pane is never opened — an explicit switch would be a
usable workaround while this is investigated.

@quetzaone — much better report than mine, thank you. Reading it alongside #82381 (and its comments from @my270yuto0413-cmyk and @jmverse4), I want to correct two things I got wrong in the original post, and add one measurement that I think is useful.

The recovery path is the headline — with one caveat

Stop-Service CoworkVMService -Force before Add-AppxPackage -Register is the piece I never found. I stopped at the wrong conclusion: Repair failed in a loop, so I assumed the package was unrecoverable, reinstalled three times in one day, then stopped using the browser pane — which ended the problem for me and ended my investigation with it. The packaged service holding file locks is exactly why Repair looks permanently broken, and it explains the 0x80073D02 the Settings UI never surfaces.

Caveat for anyone trying it: in #82381 CoworkVMService does not exist at all (sc.exe query → 1060) and Add-AppxPackage -DisableDevelopmentMode -Register does not clear the flag there. So it is worth trying first, but it is not universal. The MSIX-as-ZIP extraction workaround in #82381 is the fallback when re-registration won't take.

Correcting my own report: the dangling-staging theory doesn't hold

Your point 1 already refutes it, and I can add a data point. My second machine (32 GB desktop, same package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc, SignatureKind: Developer, Windows 11 Pro 10.0.26200.8875 vs your 8655) has:

• Event ID 658 from the 24 July update — "package is marked for deferred registration because {Claude_1.22209.3.0_x64__pzs8sxrjxfjjc} is still running"
• no %TEMP%\Claude-*.msix left on disk, no EndOfLife registry entries
• CoworkVMService ("Claude") running, Automatic — same as yours

So the exact dangling-staging state I blamed is present here, and this machine has zero Event ID 6 / 0x3CFC in the whole log (which goes back to 26 July). Dangling staging is not sufficient.

Correcting my own report again: the pane is not the trigger

I claimed the browser pane on localhost was the trigger. On my laptop it correlated 3/3, including a passive url-only attach with the dev server running externally — so nothing the app spawned for it. Your machine narrows that further: no localhost, no dev server, plain pane use is enough.

But #82381 flips the package with no pane involved at all — two Claude Code sessions in the Code tab, ~35 minutes after a verified-clean install. Same 0x3CFC, same untouched files on disk. So the honest statement is that the pane is one path into the machine-level package-status check that fails, not the only one, and the underlying trigger is still unconfirmed. Not opening the pane has been sufficient on both of my machines so far, but #82381 shows that is not a general guarantee.

Worth noting the two Status readings in this thread are not actually in conflict. Your millisecond timeline has RepairPackageOperation starting ~9 s after the Event 6 burst, which puts the package back to Ok; #82381 (Windows 10 19045) is left sitting in Modified, NeedsRemediation. Same ERROR_NEEDS_REMEDIATION condition, different auto-remediation outcome by OS generation.

chrome-native-host.exe runs from LocalCache, not from the package

This matters for both the uninstall defect and the workaround. On my machine the running native host is:

C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe

not the copy in ...\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\chrome-native-host.exe. Both are byte-identical (SHA256 D896135FBD253BC1BF5FEE7359A52E8FDA87C947F4A246ABED8C78BDF54C577C), and the Chrome native-messaging manifest under HKCU\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension points at the LocalCache copy.

That explains the uninstall defect @my270yuto0413-cmyk and @jmverse4 hit (Event 5224 / 0x5 → 0x80073D05 → 0x80073CF6): the process is not package-owned at runtime, so nothing in the package teardown stops it, and it holds the very LocalCache directory that removal has to delete. Kill chrome-native-host.exe and close Chrome before any uninstall or re-register attempt.

The same fact is why the Chrome route is usable as a substitute for the pane — it is not a process activation inside the package container, so it does not go through the package-status check that fails here.

Workaround for anyone else landing here

1. Use Claude in Chrome instead of the in-app browser pane. The extension drives your existing Chrome; in Claude Code it is the claude-in-chrome toolset (navigate, read_page, computer, read_console_messages, read_network_requests, …), which covers what I used the preview pane for, console and network inspection included. It is connected and in use on the machine described above, which has zero Event 6 — though given #82381, treat that as "one less trigger", not immunity.
2. Run dev servers in an external terminal, not through the preview pane.
3. curl for headless checks where you only need a status code or a response body.
4. The CLI is unaffected. %USERPROFILE%\.claude is never touched — claude --resume in a terminal gets you back into a session the desktop app has forgotten. @n3tman's script in #82381 restores the wiped sidebar index if you want the sessions listed in the app again.

Seconding the requests

An explicit setting to disable the in-app browser pane would remove one reproducible path into this while the root cause is open. And a downloadable 1.24012.1 would be the other half, since disableAutoUpdates makes a downgrade actually stick.

For @jmverse4's cross-issue table: this issue (#81947) is Windows 11 Pro, package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc, SignatureKind: Developer. The three destructions were on a 16 GB laptop; the 10.0.26200.8875 desktop above is a second machine that has stayed clean.

Still reproduces on 1.25927.0.0 (the new release that rolled out around Aug 4) — and this datapoint is cleaner than any of my previous ones, because it killed the machine I have been citing as the healthy control.

What happened

This is the second machine from my Jul 31 comment: Windows 11 Pro 10.0.26200.8875, zero Event ID 6 in the entire AppModel-Runtime log, no dangling staging, clean deferred registrations — the machine I used to argue the dangling-staging theory was wrong. Today, the first time the in-app browser pane was ever opened on it (an agent session opened the pane and navigated to a public domain — no localhost, no dev server), the app died instantly:

Aug 4  23:48:38  1.25927.0.0 staged to WindowsApps by the auto-updater
Aug 5  10:53:42  Register: "Claude_1.24012.11.0 ... is updating to Claude_1.25927.0.0" — app runs 1.25927.0.0 from here
Aug 5  11:58:00  6× AppModel-Runtime Event 6, 0x3CFC (<NULL> package), container destroyed

Three consequences:

1. Not fixed in 1.25927.0.0. Same signature as 1.24012.9 (this thread, #82381, #81275): Event 6 burst with <NULL> package field at the moment the pane spawns its process.
2. No accumulated bad state required. This package had a forensically clean history — first pane-open was sufficient. Combined with @quetzaone's no-localhost reproduction and #82381's no-pane reproduction, the machine-level package-status check failing under Developer-signed MSIX looks like the common core, with the pane's process spawn being the most reliable way to hit it.
3. Confirms no-localhost on my hardware too. The navigation target was a public website.

Recovery is much better on current versions — worth knowing if you hit this today

The July incidents on my laptop were unrepairable because the Repair flow looped on a deleted %TEMP%\Claude-<id>.msix (0x80070002 → 0x80073CF0). Today's Repair flow instead downloaded the package from the release CDN:

11:58:59  RepairPackageOperation + Add of Claude-003700ef....msix
          source: https://downloads.claude.ai/releases/win32/x64/1.25927.0/Claude-<hash>.msix
11:59:39  Add succeeded (39 s)
11:59:39–12:00:07  3× Register failed with 0x80073D02 ("apps need to be closed")
12:00:38  new container created — app running, Status: Ok

The 0x80073D02 retries are the known process-lock issue from this thread — package-family processes (CoworkVMService, claude.exe, chrome-native-host.exe) have to be gone before Register can succeed. Once they were, the app came back with state intact. Total outage: ~3 minutes, no reinstall, no data loss.

So the current practical guidance for anyone landing here:

• The crash itself is alive and well in 1.25927.0.0 — do not open the browser pane.
• If it hits you: kill CoworkVMService, claude, and chrome-native-host, then let Windows Repair run (or Add-AppxPackage -Register per the comment above). On current versions Repair can actually pull the MSIX from downloads.claude.ai, so the July-era "unrepairable, reinstall only" outcome no longer necessarily applies.