[Windows] MSIX update leaves Codex unregistered

Summary

On Windows 11, the desktop self-updater staged a new MSIX package successfully, but the user registration/finalization step did not follow. The registered package remained in a remediation state and the app stopped launching or redirected to Microsoft Store.

The strongest evidence is the AppX deployment event for the updater attempt: version 26.721.4979.0 completed Stage, while the same Id 613 performance summary recorded Registration cost: 0 ms. No Codex-related Register event followed until later manual recovery work.

This issue reports an updater transition failure. It does not claim that the eventual recovery was a proven register-only fix: the package was removed before the successful manual Register, and that removal also destaged the updater's original payload.

Related reports: #34311, #35347, and #35290.

Environment

• Windows 11, x64
• Package family: OpenAI.Codex_2p2nqsd0c76g0
• Affected/recovered version: 26.721.4979.0
• Previously registered version during the failure: 26.721.3996.0
• Executable in the package: app\ChatGPT.exe
• Updater source observed in Id 854: %LOCALAPPDATA%\Packages\OpenAI.Codex_...\LocalCache\Roaming\Codex\web\Codex\windows-msix-updater\...\ChatGPT-x64.msix

User-visible symptoms

1. The app worked before an automatic update.
2. After the update, launching it did nothing or redirected to Microsoft Store.
3. Get-AppxPackage showed the older registered package in Modified, NeedsRemediation state while a newer version had already been staged on disk.

Verified deployment timeline

| Time | Evidence | Interpretation |
|---|---|---|
| 20:35:06 | Id 854 points to the updater's local ChatGPT-x64.msix; Id 607 begins Stage for 26.721.4979.0 | Original updater attempt |
| 20:35:07 | Id 400 reports Stage success; Id 613 reports Overall time: 2563 ms, Stage required cost: 78 ms, and Registration cost: 0 ms | Payload was staged, but registration did not run |
| 20:35:08–23:21:15 | No Codex-related deployment event appears | No later updater Register/finalization |
| 23:37:12 | Remove-AppxPackage begins for 26.721.3996.0; Id 855 lists removePackageList: 3996.0 and destagePackageList: 4979.0 | Removing the old registration also removed the already-staged new payload |
| 23:37:13–23:37:17 | winget install --id 9PLM9XGG6VKS --source msstore receives manifest HTTP 200, obtains entitlement, and starts MSStore package execution | Store reacquisition was triggered successfully |
| 23:37:27–23:40:34 | SYSTEM-context Stage runs for 4979.0; Id 613 reports Overall time: 196156 ms, Stage required cost: 184125 ms, Registration cost: 0 ms | A new Store payload was staged, but still not registered for the user |
| 23:37:28 | The current OpenAI.Codex_26.721.4979.0_* directory is created | The final on-disk directory is not the original 20:35 directory |
| 23:42:47–23:42:48 | Manual Add-AppxPackage -Register runs; Id 613 reports Registration cost: 453 ms | User registration completes and package status becomes Ok |

What is confirmed

• The updater had a local ChatGPT-x64.msix and successfully completed Stage for 26.721.4979.0.
• That updater deployment did not execute registration (Registration cost: 0 ms).
• The later Remove-AppxPackage operation explicitly destaged the updater's already-staged 4979.0 payload.
• The subsequent winget/MSStore pipeline successfully reacquired and staged a fresh copy.
• winget did not complete user registration. A later manual Register changed the package to Status: Ok and restored launch.
• A winget CLI that stops producing output does not by itself prove that the Store download failed; in this incident the background Stage completed successfully.

What is not confirmed

• Whether registering the original 20:35 staged 4979.0 manifest would definitely have recovered the app. It is the lowest-risk first action and is strongly suggested by the evidence, but it was not actually tried before removal.
• Why the winget frontend remained running without a completion or error line after handing work to the MSStore pipeline.
• Why the older 3996.0 registration repeatedly entered ACL remediation.
• The exact trigger of the automatic RepairAppRegistrationOption operations at 23:21–23:22.

Important diagnostic lessons

1. Get-AppxPackage can show the older registered version while a newer, unregistered version already exists under WindowsApps. Inspect both views before choosing a manifest.
2. Do not use Remove-AppxPackage as the first recovery step. Id 855 demonstrates that it can also destage a newer payload that was already available for registration.
3. Stage duration and SID are supporting clues, not provenance proofs. S-1-5-18 identifies SYSTEM deployment context, not winget uniquely; duration is environment-dependent. Correlate Id 854 URI, winget logs, directory timestamps, and the complete event sequence.
4. No user-specific merged files found / No shared merged files found messages (Id 5507) are not sufficient by themselves to prove package corruption; the same messages appeared during a successful registration of 4979.0.
5. Get-AuthenticodeSignature may report NotSigned for the inner app\ChatGPT.exe. Packaged-app signing is represented by the outer AppxSignature.p7x; the inner result alone does not prove corruption.

Recommended first-response diagnostics

Get-AppxPackage -Name OpenAI.Codex -ErrorAction SilentlyContinue |
  Select-Object Name, Version, Status, InstallLocation |
  Format-List

Get-ChildItem 'C:\Program Files\WindowsApps' -Directory -Force -ErrorAction Stop |
  Where-Object { $_.Name -like 'OpenAI.Codex_*' } |
  Select-Object Name, CreationTime, LastWriteTime |
  Format-Table -AutoSize

Get-WinEvent -LogName 'Microsoft-Windows-AppXDeploymentServer/Operational' -MaxEvents 300 |
  Where-Object { $_.Message -match 'OpenAI\.Codex|ChatGPT-x64\.msix|windows-msix-updater' } |
  Sort-Object TimeCreated |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

If a newer, structurally complete package is already staged, attempt to register its AppxManifest.xml before any removal. This is recommended as the minimal-risk recovery path, not claimed as a historically proven counterfactual for this incident.

If enumerating WindowsApps returns access denied, rerun the read-only inspection from an elevated PowerShell session; do not interpret suppressed access errors as proof that no package exists.

Actual recovery sequence used in this incident

This records what actually happened; it is not the preferred minimal procedure:

# Removal had already destaged the updater payload at this point.
winget install --id 9PLM9XGG6VKS --source msstore

# After the Store payload was staged but still unregistered:
Add-AppxPackage -DisableDevelopmentMode -Register `
  'C:\Program Files\WindowsApps\OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0\AppxManifest.xml'

Observed result: version 26.721.4979.0, Status: Ok, and normal launch.

Expected updater behavior

The updater should either:

1. complete Stage plus user registration/finalization as one recoverable transaction; or
2. roll back to the previously usable registration and present a clear recovery message.

Logging and telemetry around the post-Stage registration/finalization handoff would make this failure substantially easier to diagnose.