[Windows] Codex/ChatGPT desktop MSIX auto-updater loops forever — new build downloads but never deploys; app also launches into a permanently-suspended process

Summary

On Windows 11, the Codex/ChatGPT desktop app (MSIX, OpenAI.Codex) is stuck in an endless update loop: the in-app updater reports a newer build, downloads it successfully, but the install/deploy never completes — the registered package version never advances. Separately (and compounding it), every launch produces a ChatGPT.exe process that is created suspended and never resumed, so no window ever appears until the process is manually resumed.

Likely related to #27377 and #25770.

Environment

• Windows 11 Pro (build 26200)
• Package: OpenAI.Codex_2p2nqsd0c76g0 (Store-signed, SignatureKind=Store), Store ID 9PLM9XGG6VKS
• Installed build: 26.803.10989.0; updater-advertised build: 26.810.7004.0

Symptom (user-visible)

Sidebar shows a blue Update button. Clicking it → "Installing update — ChatGPT will restart when installation finishes / Preparing…", progress bar reaches ~50%, then the app closes. It never reopens on its own; reopening later still shows the same download/Update prompt. The loop repeats indefinitely.

Evidence 1 — check & download succeed, deploy never happens

Desktop log:

[windows-store-updater] Checking Windows Store for package updates buildVersion=26.803.10989.0 manifestBuildVersion=26.810.7004.0 packageIdentity=OpenAI.Codex
[windows-store-updater] ... completed canSilentlyDownload=true completed=true hasUpdate=true overallState=Completed
[sparkle] ... action=download_completed ... result=succeeded

But Microsoft-Windows-AppXDeploymentServer/Operational over 2 days contains zero deployment operations for 26.810.7004.0. Instead it repeatedly runs, on the old 26.803 build:

RegisterByPackageFullName ... options ForceTargetApplicationShutdownOption,RepairAppRegistrationOption
Register operation: Trying to repair ACLs for ...\OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
Register operation: ACLs repaired successfully ... Register next time
Deployment Register operation ... completed successfully   (still 26.803)

→ the system keeps repairing / re-registering the old build; the new build is never staged or registered.

Evidence 2 — the new build is NOT on the public Store, so it can only come from the app's own updater

winget list  --name OpenAI      -> ChatGPT  9PLM9XGG6VKS  26.803.10989.0  msstore
winget upgrade --id 9PLM9XGG6VKS -> "No available upgrade found. No newer package version available in the configured sources."

A forced Windows Store update scan (MDM_EnterpriseModernAppManagement_AppManagement01 -> UpdateScanMethod, ReturnValue=0) also deploys nothing. So 26.810 is served only through the app's own updater feed (ahead of the public Store's 26.803). This means the broken component is the app's own MSIX self-update path (windows-msix-updater), and end users cannot work around it via a Store / winget reinstall.

Evidence 3 — launches into a permanently-suspended process (compounds the loop)

After launch, exactly one ChatGPT.exe: ~2–4 MB, 1 thread, ThreadState=Wait / WaitReason=Suspended, MainWindowHandle=0, no log lines written, userData untouched — i.e. it never executed any app code. Calling NtResumeProcess on it immediately brings it to life (→ ~380 MB, 64 threads, spawns the full Electron child tree, window appears). So the process is created suspended by activation and the resume step never fires. This happens especially right after an update-triggered restart, which is likely why the post-install relaunch never completes and the update can't finalize.

Evidence 4 — earlier occurrence matching #25770 (locked old package)

A prior update left activation failing with 0x80070020 ERROR_SHARING_VIOLATION at "create Desktop AppX container / configuring runtime" (Microsoft-Windows-AppModel-Runtime/Admin Id 208 / 215). The package's Helium hive ...\OpenAI.Codex_2p2nqsd0c76g0\SystemAppData\Helium\User.dat was locked; Restart Manager reported the holders as System (PID 4) + Registry (PID 472) (RmCritical) — i.e. a stale mounted registry hive inside an orphaned per-package Server Silo. Re-register, AppXSvc restart, and app "Reset" did not clear it; only a reboot / sign-out did.

Impact

The update can never complete; the app is unusable after each attempt until the suspended process is manually resumed; users are ultimately forced to reboot.

Likely root cause (hypothesis)

The self-updater applies the new MSIX while the old instance can't cleanly shut down / relaunch (the suspended-launch bug in Evidence 3), so the deploy aborts and Windows rolls back to repairing the current build. The orphaned per-package container / hive state (Evidence 4) further blocks a clean re-deploy.

Suggested fixes

• Apply the self-update fully offline — defer to the next clean launch after a full shutdown — rather than swapping the package under a live / relaunching instance.
• Detect the "created-but-never-resumed" state (or the 0x80070020 container-activation failure) and surface a clear "please restart Windows to finish updating" message instead of silently looping.
• Add a watchdog for the suspended / never-resumed main process so it can self-recover or report.

Related

• #27377 — update stuck after "Update downloading", version mismatch
• #25770 — old MSIX package locked in use / mounted Helium hives
• #23053 — update prompt should show target versions / component diff