[Windows] MSIX update leaves Codex unregistered

[Maxwell389]

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.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• [Windows] Codex desktop app fails to launch, AppX package status shows "Modified, NeedsRemediation" #35347
• Windows app: package repeatedly enters NeedsRemediation state - crash 0xc06d007f when using sidebar browser (Chrome) #34311
• Windows Store Codex enters "Modified, NeedsRemediation" after opening any webpage and becomes unlaunchable #35290

Powered by Codex Action

[Maxwell389]

Correction: after reconstructing the complete AppX deployment timeline, I found that my original description overstated the recovery as a confirmed register-only, non-destructive fix.

The updater failure itself is still confirmed: its local-cache Stage for 26.721.4979.0 succeeded, but no Register event followed. However, before the successful manual Register, I had run Remove-AppxPackage and then winget install --source msstore, which reacquired/staged a new copy of the package. Manual registration of that later copy restored Status: Ok.

I updated the issue body to separate verified facts from inference and to document the actual recovery sequence. In particular, this incident does not prove that registration alone would have fixed the original untouched state.

[Maxwell389]

Final correction after a three-way evidence review and an independent re-query of the local AppX and winget logs:

• The original updater failure is now supported by positive engine evidence: the 20:35 Id 613 Stage summary reports Registration cost: 0 ms.
• The 23:37 Remove operation explicitly listed the already-staged 4979.0 under destagePackageList (Id 855). Reacquisition became necessary only after that removal.
• The winget/MSStore pipeline did download and Stage a fresh copy even though the winget frontend stopped producing output; no output must not be treated as proof that the download failed.
• Stage duration and SYSTEM SID are supporting clues only, not general provenance rules.
• Registering the highest complete staged version before any removal is now documented as the lowest-risk first attempt. It remains a recommended counterfactual, not something proven to have been tried successfully before removal in this incident.

I updated the issue body with the final verified timeline, diagnostic caveats, and safer first-response guidance.

[Yuntenr]

Thanks for the detailed investigation and solution.

After reading this thread and further testing, I found that the Add-AppxPackage -Register step itself was not the problem. In my case, the issue was likely that I was trying to register an outdated InstallLocation, or the WindowsApps directory did not contain the complete staged MSIX package at that time.

Appreciate the detailed explanation and recovery guidance!

[z4djjskk]

Additional corroborating evidence from a sanitized Windows 11 x64 reproduction:

• Codex AppX update: 26.721.4979.0 -> 26.721.11231.0.
• 2026-07-30 12:20:58: AppX Stage completed (event 613: 112,813 ms), but Register failed.
• The same deployment recorded event 638: the affected OpenAI.Codex app was still running.
• Events 419/401/404 reported 0x80073D02 and explicitly required closing the old package. The first Register request did not include ForceTargetApplicationShutdownOption.
• 2026-07-31 10:07:56: the retry included ForceTargetApplicationShutdownOption; the old package folder was moved to WindowsApps\Deleted and Register completed successfully.
• 2026-07-31 10:07:57: WindowsUpdateClient recorded installation success.
• The bundled marketplace/cache was rematerialized immediately afterward and the installed/enabled plugin list then exited 0.

User-visible impact: the update appeared to remain in an updating/pending state for many hours even though the payload had already been staged. The failure was not an active download; it was a deferred/failed registration caused by the running app.

Expected behavior:

1. Coordinate app shutdown before AppX registration, or retry with a clear actionable state.
2. Preserve the last usable registration if registration is blocked.
3. Expose a distinct staged/deferred/registration-failed state instead of an indefinite updating indicator.
4. Emit the blocking package/process and recovery action in the UI/log.

This is related to the plugin-cache/host lifecycle symptoms in #32706. No account, project, credential, or private-path data is included.