[BUG] Windows MSIX: auto-update leaves app unlaunchable — 0x80070002 'error converting the job' (Events 208/215); chrome-native-host.exe inside package profile survives update and pins the app data store

Summary

MSIX auto-update to 1.26832.0.0 left Claude Desktop permanently unlaunchable with AppModel-Runtime Events 215/208 HRESULT 0x80070002 ("error converting the job") — a distinct, rarer variant of the known 0x80070020 family (#53247, #48003, #57221). Unlike the 0x80070020 cases, reboot does NOT recover, and neither does Add-AppxPackage -Register.

Root cause found empirically: **chrome-native-host.exe (the Claude-in-Chrome native messaging host) runs from inside the package's application data store** (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\). Its lifecycle is owned by Chrome, not by Claude Desktop, so it survives the app quitting for update — and keeps holding the app data store while the MSIX update commits. After that, Desktop AppX container creation fails with E_FILENOTFOUND on every launch.

Environment

• Claude Desktop 1.26832.0.0 (MSIX, Claude_pzs8sxrjxfjjc), arrived via auto-update
• Windows 11 Education 25H2, build 10.0.26200
• Claude in Chrome extension active (Chrome running throughout)
• Only Windows Defender; Smart App Control on (enforce) but CodeIntegrity/AppLocker logs clean; IFEO clean; no AV detections

Timeline

1. 06:51 — update package staged (new app\claude.exe written)
2. 12:38 — app logs beforeQuitForUpdate handler fired, going down for update and exits. Never launches again
3. Every subsequent launch: TWinUI event 1621 reports activation "completed successfully", but no process is created; Explorer shows "Windows cannot find …\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\Claude.exe" although the file exists (Test-Path = True, correct size)
4. AppModel-Runtime/Admin per attempt:

• Event 208: 0x80070002: Cannot create the process … error encountered while configuring runtime [LaunchProcess]
• Event 215: 0x80070002: Cannot create the Desktop AppX container … error was encountered converting the job
• (An Event 211 shows one process briefly added to a container; sibling containers then fail)

1. CoworkVMService stayed healthy the whole time (reaches "Service ready", waits for configure)

What did not help

• Full reboot (twice) — unlike the 0x80070020 orphaned-job cases
• Add-AppxPackage -DisableDevelopmentMode -Register AppxManifest.xml
• Stopping CoworkVMService before launch
• Official bootstrapper from claude.ai/download: per %TEMP%\ClaudeSetup.log it hit the known 0x80073CFA ("Windows rejected data-preserving removal … requires developer mode"), fell back to "relying on in-place update", AddPackage over the same version "succeeded" in ~1 s (effective no-op), reported === Claude Setup completed successfully ===, launched the app — which failed with the same dialog. The installer reports success while leaving the app broken.

Recovery that worked (data preserved)

1. Backed up LocalCache\Roaming\Claude (excluding vm_bundles/caches)
2. Remove-AppxPackage — clean (package was Status: Ok)
3. Fresh Add-AppxPackage of the downloaded MSIX then failed 0x80073CF6 with inner 0x80073D05 ("error deleting the package's previously existing application data store") — which exposed the holder:
4. chrome-native-host.exe was still running from inside the (by then renamed) package profile — it had survived the app's death at 12:38, the reboot happened to restart Chrome which respawned it, and it survived package removal
5. Killed it → renamed the old profile aside → Add-AppxPackage -ForceApplicationShutdown -ForceUpdateFromAnyVersion (must run in the interactive session; over SSH it fails 0x80070005 "Failed to initialize PLM") → restored backed-up data into the fresh profile → app fully recovered, logged in, MCP servers reconnected

Suggested fixes

1. The updater/quit-for-update path should stop chrome-native-host.exe (it ships with the product, but its lifetime is controlled by Chrome, so beforeQuitForUpdate never terminates it)
2. Consider hosting the native messaging host binary outside the MSIX app data store, so a Chrome-owned process can never pin the package profile across updates
3. The bootstrapper should not report success when removal failed with 0x80073CFA and the same-version AddPackage was a no-op; verify the app actually launches, or surface the failure

Related

#57221 (CoworkVMService/job family), #48003 (0x80070020 after update), #53247 (orphaned Silo/Job, reboot recovers — this case does not), #53504 (0x80070002 metadata profile), #25162 / #82494 (0x80073CFA data-preserving removal), #79307 (bootstrapper behavior)