[Windows 10][26.903.8094.0] Stable ChatGPT/Codex does not launch at all, while Beta works

[Hajmer777]

What version of the Codex App are you using (From “About Codex” dialog)?

26.903.8094.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows 10 22H2 (10.0.19045) x64

What issue are you seeing?

The current stable ChatGPT/Codex Windows application does not launch at all.

Environment:

• Windows 10 22H2, build 19045, x64
• Stable Codex/ChatGPT version: 26.903.8094.0
• ChatGPT Beta version: 26.727.4816.0

Steps to reproduce:

1. Launch the stable ChatGPT/Codex application.
2. No window appears.
3. No persistent ChatGPT process is created.

I verified this with PowerShell:

Get-Process ChatGPT -ErrorAction SilentlyContinue | Select Id,CPU,MainWindowHandle,Path

The command returns no output after attempting to launch the stable version.

I then installed ChatGPT Beta from Microsoft Store on exactly the same PC, Windows installation, Windows account, and OpenAI account.

ChatGPT Beta launches successfully and Codex works normally.

Installed versions:

ChatGPT
26.903.8094.0
OpenAI.Codex

ChatGPT (Beta)
26.727.4816.0

ChatGPT Classic
1.2026.190.0

Expected behavior:
The stable ChatGPT/Codex application should launch normally.

Actual behavior:
The stable application silently fails to launch, while the Beta version works correctly on the same system.

This appears to be a regression specific to the current stable Windows build.

Screenshots are attached showing the installed versions and the working Beta application.

What steps can reproduce the bug?

1. Have Stable OpenAI.Codex 26.903.8094.0 installed on Windows 10 22H2 x64, build 19045.

2. Microsoft Store / AppX stages update 26.915.4065.0.

3. Launch Stable Codex from the Start menu or with:

shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App

4. No window appears and ChatGPT.exe is never created.

5. AppXDeploymentServer logs show that Windows attempts to update:

OpenAI.Codex_26.903.8094.0_x64__2p2nqsd0c76g0

to:

OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0

6. Package registration fails immediately with:

Event ID: 9621
Provider: Microsoft-Windows-AppXDeployment-Server
HRESULT: 0x80073D28

Error:

The package cannot be registered because administrator privileges are required to install the servicing package.

7. Follow-up AppX Events 401 and 404 report the same HRESULT.

8. There is no AppModel Runtime Event 201 (LaunchProcess) for Stable, no persistent ChatGPT.exe process, no WER crash report and no crash dump.

9. ChatGPT Beta 26.727.4816.0 installed on the exact same Windows system launches successfully and produces AppModel Runtime Event 201.

What is the expected behavior?

Launching the Stable Codex/ChatGPT application should start ChatGPT.exe and display the application normally.

A staged Microsoft Store update should not prevent the currently registered version from launching if the update cannot be registered.

If administrator privileges are genuinely required for the update, the application or Microsoft Store should request elevation or report the deployment error instead of silently preventing Codex from launching.

Additional information

The failure occurs before the application executable starts.

Registered Stable package:

OpenAI.Codex_26.903.8094.0_x64__2p2nqsd0c76g0

Staged update:

OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0

At every Stable launch, AppX attempts to register the staged update and fails:

2026-09-19 11:37:00.806 +03:00

Microsoft-Windows-AppXDeployment-Server
Event ID 9621
HRESULT 0x80073D28

Windows reports that administrator privileges are required to install the servicing package.

No ChatGPT.exe process is subsequently created.

ChatGPT Beta 26.727.4816.0 launches successfully on the same machine.

[github-actions]

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

• [Windows][26.915.3509.0] In-app updater stages package but leaves old version registered after LocalSystem sandbox service was added #46370

Powered by Codex Action

[Hajmer777]

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

• [Windows][26.915.3509.0] In-app updater stages package but leaves old version registered after LocalSystem sandbox service was added #46370

Powered by Codex Action

I reviewed #46370 and agree that the underlying AppX/MSIX registration failure appears to be the same.

Both cases are on Windows 10 22H2 build 19045 and involve a staged 26.915.x update failing registration with HRESULT 0x80073D28 because administrator privileges are required for the packaged servicing component.

However, there is an additional user-visible failure in my case:

In #46370, the update remains incomplete and the previously registered version remains available.

In my case, the staged update intercepts every subsequent Stable launch. AppX attempts registration again, fails with 0x80073D28, and the currently registered Stable application is not launched at all.

There is no AppModel Runtime Event 201 and ChatGPT.exe is never created.

So this appears to be the same underlying updater/elevation issue, but with a more severe launch-blocking manifestation in the later staged build 26.915.4065.0.

If maintainers prefer to track both manifestations under #46370, I am happy for this issue to be closed as a duplicate, provided the launch-blocking behavior is captured there.

[tolga-guldutuna]

The staged-update behavior here is exactly the kind of failure I am trying to avoid operationally by preventing unattended Codex/Store updates.

On the affected machine I now use:

• CODEX_SPARKLE_ENABLED=false for the Codex in-app updater;
• HKLM\SOFTWARE\Policies\Microsoft\WindowsStore\AutoDownload=2 for Store auto-updates.

Before a planned update I back up those settings and the currently registered Codex package, temporarily unblock, update manually, then verify:

Get-AppxPackage OpenAI.Codex |
  Select Name,Version,Status,PackageFullName,InstallLocation

and re-block only after the intended version is registered with Status: Ok.

Full workflow:
#25770 (comment)

This will not repair an already-staged 0x80073D28 servicing-package registration failure. It is a preventive maintenance policy so a staged automatic update does not unexpectedly replace/block a working build during normal use.