›_ Codex Issues
Codex Issues / #41073

[Windows][26.820.9563.0] ChatGPT launches headless with MainWindowHandle=0; disabling updater fixes startup

Open 💬 5 comments Opened Aug 27, 2026 by sdf123098
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

26.820.9563.0

What platform is your computer?

Windows x64, Microsoft Store / MSIX package OpenAI.Codex

What issue are you seeing?

After updating to 26.820.9563.0, the ChatGPT/Codex Windows desktop app no longer opens a visible window.

Multiple ChatGPT.exe processes are created and remain running, and they report Responding=True, but every process has:

MainWindowHandle : 0
MainWindowTitle  :

The application remains headless indefinitely.

The MSIX package itself appears healthy:

Name         Version       Status
----         -------       ------
OpenAI.Codex 26.820.9563.0 Ok

The install location is:

C:\Program Files\WindowsApps\OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0

What steps can reproduce the bug?

  1. Update/install ChatGPT/Codex Desktop 26.820.9563.0 from the Microsoft Store.
  2. Launch the app normally.
  3. No window appears.
  4. Check the processes with:
Get-Process ChatGPT -ErrorAction SilentlyContinue |
Select-Object Id,ProcessName,Responding,MainWindowHandle,MainWindowTitle,Path
  1. Observe multiple live ChatGPT.exe processes with Responding=True and MainWindowHandle=0.

Passing an arbitrary Chromium argument did not fix the issue.

Startup log without workaround

The startup log stops almost immediately:

2026-08-27T06:54:38.033Z info Launching app agentRunId=null allowDebugMenu=false allowDevtools=false allowInspectElement=false buildFlavor=prod enableSparkle=false enableUpdater=true nodeEnv=undefined packaged=true platform=win32
2026-08-27T06:54:38.110Z info Appshot hotkey inactive configured=true enabled=false platform=win32

No main window is created afterward.

Workaround

If I terminate all ChatGPT processes, set:

$env:CODEX_SPARKLE_ENABLED = "false"

and launch the packaged app again, the window opens normally.

Example launch command used:

Get-Process ChatGPT -ErrorAction SilentlyContinue | Stop-Process -Force

$env:CODEX_SPARKLE_ENABLED = "false"

$pkg = Get-AppxPackage -Name OpenAI.Codex
$exe = Join-Path $pkg.InstallLocation "app\ChatGPT.exe"

Invoke-CommandInDesktopPackage `
    -PackageFamilyName $pkg.PackageFamilyName `
    -AppId "App" `
    -Command $exe

With the updater disabled, the app continues normal initialization and the UI appears.

Expected behavior / suggestion

The updater should be treated as a non-critical subsystem.

If updater initialization fails, the Microsoft Store update check fails, the update manifest is unavailable, or an update cannot be installed, that failure should not prevent the main application from starting or creating its window.

The app should instead:

  • log the updater failure,
  • continue launching the main UI normally,
  • optionally surface a non-blocking update warning after startup,
  • retry the update check later.

In other words, updater failure should degrade update functionality only, not take down the primary application startup path.

Additional notes

  • Re-launching normally reproduces the issue.
  • Package status is Ok.
  • Passing an arbitrary Chromium command-line argument did not fix the issue.
  • CODEX_SPARKLE_ENABLED=false does fix the issue.
  • This appears related to #33320, but the symptom on 26.820.9563.0 is different: the app remains running headless instead of visibly crashing after ready-to-show.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 day ago

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

  • #41056
  • #41064
  • #41059

Powered by Codex Action

rainhotel · 10 hours ago

me too

nefilbata · 9 hours ago

I can reproduce the same issue on Windows x64 with Microsoft Store package OpenAI.Codex 26.820.9563.0.

Additional details from my case:

  • The app was working normally the previous night.
  • I did not manually update it. Microsoft Store later showed that ChatGPT had been updated automatically only a few minutes earlier.
  • After the update/reboot, clicking ChatGPT/Codex creates multiple background processes but no visible window.
  • Get-Process ChatGPT showed 6 processes, all Responding=True and all with MainWindowHandle=0. One main process used roughly 390–534 MB RAM and active CPU.
  • Get-AppxPackage OpenAI.Codex reports Status: Ok and install location under C:\Program Files\WindowsApps\OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0.
  • Microsoft-Windows-AppModel-Runtime/Admin reports process/container creation successfully (Event IDs 201/210/211).
  • Microsoft-Windows-TWinUI/Operational reports Event ID 1621 with activation result 0 / operation completed successfully.
  • Re-registering the package with Add-AppxPackage -DisableDevelopmentMode -Register ...\AppxManifest.xml -ForceApplicationShutdown completed successfully but did not restore the UI.
  • Rebooting also did not help.
  • There is no cua_node.staging-* directory under %LOCALAPPDATA%\OpenAI\Codex\runtimes, so this does not appear to be the long first-launch runtime extraction case.

One potentially confusing environmental change: the day before, I moved the Windows pagefile from C: to D:. However, D:\pagefile.sys is active and working (AllocatedBaseSize=12288 MB, current usage > 0), and Windows AppX activation itself succeeds, so at this point it looks much more like the same 26.820.9563.0 headless-start regression than a pagefile issue.

I have not reset or uninstalled the app because I want to preserve local Codex history/project state.

This report is mainly to confirm another reproduction of the same failure signature after an automatic Microsoft Store update.

nefilbata · 9 hours ago

Update from my reproduction: I found an active/partial cua_node staging directory after all:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-57937f104cca4dc5-HLWiKu\...

Many files under that staging tree were modified during the failed/headless launch. My earlier check looked one directory level too high (runtimes\cua_node.staging-* instead of runtimes\cua_node\.staging-*), so that earlier conclusion was incorrect.

This makes my case potentially closer to #41170 (first-launch/update runtime extraction) than I initially thought. I am now checking whether file count/size in the staging directory is still increasing or has stalled.

nefilbata · 9 hours ago

Update: the app eventually recovered, and the root cause on my machine now appears to be the first-launch/update extraction of the bundled cua_node runtime rather than a permanent headless failure.

What I found:

  • Under %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node, the app was creating many .staging-* directories for the new runtime version.
  • The active staging directory was still being populated while the GUI was absent.
  • In one 60-second sample, the staging tree grew from:
  • 3810 files / 254.8 MB
  • to 4449 files / 268.2 MB
  • Shortly afterward, the ChatGPT/Codex window finally appeared without any further intervention.

So the apparent launch failure was actually an extremely slow silent runtime materialization step after the Microsoft Store auto-update. During this period:

  • multiple ChatGPT.exe processes were alive and responsive,
  • all had MainWindowHandle=0,
  • no visible progress UI was shown,
  • CPU usage remained active,
  • the app looked completely broken from the user's perspective.

The CODEX_SPARKLE_ENABLED=false workaround did not change the behavior on this machine; waiting for the cua_node staging extraction to progress is what ultimately led to recovery.

This now looks much closer to #41170 than to a permanently stuck renderer/window regression.

One UX suggestion: if bundled runtime extraction/materialization is required after an update, the app should show a visible initialization/progress state instead of remaining headless for many minutes.