I don't have a bug report to analyze. The input "ssdf" doesn't contain any meaningful issue information. Please provide a detailed bug report or feature request describing: - What happened - What you expected to happen - Error messages or logs - Steps to

Bug Description
ssdf

Environment Info

• Platform: win32
• Terminal: null
• Version: 2.1.220
• Feedback ID: b573e568-e1a1-4c41-a693-76fcf564a859

Errors

[]

Claude Desktop (MSIX) self-corrupts on auto-update: failed rollback uses PreserveApplicationData on a production-signed package

Summary

Claude Desktop on Windows repeatedly bricks itself during auto-update. The update fails because the app is still running, and the subsequent rollback attempt uses the PreserveApplicationData removal flag — which Windows only accepts for packages deployed in developer mode. The rollback therefore also fails, leaving the MSIX package in a half-old/half-new state (Modified, NeedsRemediation).

The user-visible result is the Windows dialog "This app can't open" / "Repair". Repairing does not fix it, and reinstalling only works until the next update attempt — the failure recurs roughly daily.

Environment

• OS: Windows 11 Pro 10.0.26200
• Package: Claude_1.24012.11.0_x64__pzs8sxrjxfjjc (previous: 1.24012.9.0)
• Signature: valid — CN="Anthropic, PBC" via DigiCert Trusted G4, not expired
• Install type: MSIX, sideloaded (SignatureKind: Developer)

Symptom

PS> Get-AppxPackage Claude | Select Name, Version, Status

Name    : Claude
Version : 1.24012.11.0
Status  : Modified, NeedsRemediation

Launching the app produces the Windows "can't open this app → Repair" dialog.

Root cause — event log timeline

From Microsoft-Windows-AppXDeploymentServer/Operational:

| Time | Event | Detail |
|---|---|---|
| Day 1, 10:38:30 | 486 | Auto-update starts: 1.24012.9.0 → 1.24012.11.0 |
| Day 1, 10:38:46 | 404 | 0x80073D02 — "cannot install because the following apps need to be closed: Claude_1.24012.9.0" |
| Day 1, 10:38:46 | 8104 | Failed to set the trust label on the package |
| Day 1, 10:39:53 | 717 | 0x80073CFA — "cannot remove Claude_1.24012.9.0 because the PreserveApplicationData flag can only be used on a package deployed in developer mode" |
| Day 1, 10:40:39 | 717 | Same 0x80073CFA failure, retried |
| Day 1, 10:55:04 | 1230 | "These hardlinks had no packages in the repository: \Program Files\WindowsApps\Claude_1..." — orphaned files left on disk |
| Day 1, 13:17:58 | 658 | "Marking package 1.24012.11.0 for deferred registration because 1.24012.9.0 is still running" |
| Day 2, 09:17:58 | 717 | Manual reinstall — 0x80073CFA again, old package still cannot be removed |

The two failures compound:

1. 0x80073D02 — the updater tries to replace files of a running package. Windows refuses.
2. 0x80073CFA — the rollback path calls package removal with PreserveApplicationData. That flag is only valid for developer-mode deployments, so it is rejected on this production-signed package. The corrupted package is never cleaned up.

Because step 2 never succeeds, every subsequent reinstall layers on top of the orphaned hardlinks from the broken package, so the fix lasts only until the next update check.

Contributing factor: orphaned helper process

chrome-native-host.exe (from LocalCache\Roaming\Claude\ChromeNativeHost\) survives closing the app and keeps package files locked. It was found still running long after Claude Desktop had been exited, and had to be killed manually before package cleanup would succeed:

Id     Name
--     ----
22208  chrome-native-host

This is very likely why the updater hits 0x80073D02 even when the user believes the app is fully closed. Deployment also logged repeated warnings (event 5224) failing to delete this exact file.

Why "Repair" doesn't help

The Settings → Repair action issues RegisterByPackageFullName with RepairAppRegistration, which only re-registers the manifest. It does not replace modified files or resolve the split package state. Confirmed in the log: a repair ran and Status remained Modified, NeedsRemediation.

Suggested fixes

1. Do not use PreserveApplicationData in the rollback/removal path for production-signed packages — it is guaranteed to fail outside developer mode. Fall back to a plain RemovePackageAsync.
2. Fully terminate all helper processes before updating, in particular chrome-native-host.exe, so the update does not hit 0x80073D02.
3. Defer the update to next launch rather than attempting an in-place update of a running package.
4. Detect and recover from Modified, NeedsRemediation at startup instead of surfacing the generic Windows "can't open this app" dialog, which gives the user no actionable information.

Workaround for affected users

1. Kill any leftover processes:

``powershell
Get-Process | Where-Object { $_.Name -match 'claude|chrome-native-host' } | Stop-Process -Force
``

1. Remove the package without PreserveApplicationData:

``powershell
Get-AppxPackage Claude | Remove-AppxPackage
``

1. Delete leftovers at %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc
2. Reinstall from https://claude.com/download

Note: this does not affect Claude Code CLI history in ~/.claude/ — that is a separate installation.