[BUG] [BUG] Windows regression in Desktop 1.24012.9: opening the in-app browser pane on localhost destroys the MSIX package — unrepairable, 3 reinstalls in one day

[RaphaelMindverse]

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?

Since the 2026-07-26 auto-update of Claude Desktop for Windows (1.24012.1 → 1.24012.9), opening the in-app browser pane on a localhost dev server permanently destroys the MSIX package registration. The app then cannot launch (Windows dialog: "reset or repair the app"), Repair/Reset both fail, and only a full reinstall works — losing all app state. This happened three times in one day (2026-07-28). On 1.24012.1 I used the browser pane with localhost daily without any issues.

The third occurrence isolates the trigger: the dev server was running externally in a terminal and the app spawned no processes — merely navigating the browser pane to http://localhost:3000 (attach-only launch.json, url field only) killed the app within a minute. So this is not RAM-related and not caused by spawning a dev server; the browser-pane process spawn / package validation itself triggers it.

Suspected root cause: the installer/auto-updater stages a package in %TEMP%\Claude-.msix with deferred registration. Once that temp file is cleaned up, a dangling staging session remains; the next packaged process spawn (a browser-pane tab) fails machine-level package validation (0x3CFC) and permanently bricks the installation — Repair loops chasing the deleted temp file. Normal chat usage spawns no such process, which is why the app appears stable until the browser pane is used.

What Should Happen?

Opening the in-app browser pane on localhost should render the page. An app crash or a missing staged update file in %TEMP% must never corrupt the installed MSIX package; Repair should be able to recover without a full reinstall, and reinstalls should preserve app data.

Error Messages/Logs

Windows event log, third incident (13:41, dev server external, attach-only):

Microsoft-Windows-AppModel-Runtime/Admin, Event 6 (13:41:09, 5x):
0x3CFC: Der Prozess für das <NULL>-Paket kann nicht erstellt werden, da beim Prüfen des Paketstatus auf Computerebene ein Fehler aufgetreten ist: Die Anwendung konnte nicht gestartet werden. Installieren Sie die Anwendung neu.

Microsoft-Windows-AppXDeploymentServer/Operational (13:41:46, repeating loop; Events 465/497/403/404):
Fehler 0x80070002: Fehler beim Öffnen des Pakets im Speicherort "Claude-494409263.msix".
Fehler 0x80070002: Fehler beim Öffnen des Msixvc-Pakets vom Speicherort Claude-494409263.msix.
Fehler 0x80070002: Fehler beim Abrufen der Stagingsitzung für: file:///C:/Users/<user>/AppData/Local/Temp/Claude-494409263.msix.
Fehler "0x80073CF0" beim AppX Deployment-Vorgang für Paket "".

Event 717 (13:42:56, why app data is lost on reinstall):
"Claude_1.24012.9.0_x64__pzs8sxrjxfjjc" kann nicht entfernt werden, da das PreserveApplicationData-Kennzeichen nur für ein Paket verwendet werden kann, das im Entwicklungsmodus bereitgestellt wurde. (0x80073CFA)

Earlier incidents same day: identical 0x3CFC + repair loop on a *different* random temp file (Claude-3676116916.msix). After the 07-26 update, cleanup of the old version failed on locked icudtl.dat (Event 471, 0x12C) and the package sat on the deletion list across reboots (Event 503). Notably absent: no Resource-Exhaustion events (System 2004) and no node.exe/WER crashes during incidents 2 and 3 — the failure is package-state, not OOM.

Steps to Reproduce

1. Windows 11, Claude Desktop MSIX 1.24012.9 (package Claude_pzs8sxrjxfjjc), machine that took the 1.24012.1 → 1.24012.9 auto-update on 2026-07-26.
2. Run any dev server externally in a terminal (in my case: Next.js 16.2 with Turbopack on port 3000).
3. In a Claude Code session in the desktop app, open the browser pane on http://localhost:3000 (attach-only; the app spawns nothing).
4. Within ~1 minute the app's package registration breaks (Event 0x3CFC). Every subsequent launch shows the Windows "repair the app" dialog; Repair/Reset fail (repair loop on a deleted %TEMP%\Claude-.msix); only full reinstall works, wiping app state.

Reproduced 3/3 times on 2026-07-28 (twice with the dev server started via the in-app preview, once attach-only). Never happened on 1.24012.1.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Claude Desktop for Windows 1.24012.1 (the regression is in the desktop app, not the CLI)

Claude Code Version

2.1.219 (Claude Code, bundled with the Desktop app where the bug occurs; standalone terminal CLI reports 2.1.215)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Related issues (same package family / error class, none covers this trigger): #35366 (MSIX crash-on-restart, reinstall loop), #47877 (MSIX stuck in Staged state after auto-update, same package family pzs8sxrjxfjjc — closed as invalid, but it matches this failure class), #25162 (0x80073CFA on Squirrel→MSIX migration).

Environment: Windows 11 Home 10.0.26200, 16 GB RAM (Samsung Galaxy Book 950QDB). Full event log extracts and exact timestamps for all three incidents available on request. I also filed this via /bug in-app today (with session transcript) — this issue adds the third, attach-only occurrence that isolates the trigger.

[quetzaone]

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.
2. 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.