[Windows 26.820.9563.0] Desktop remains headless after external Codex CLI workaround

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

• #41056
• #40843
• #40791
• #40700

Powered by Codex Action

Important update: the app eventually opened after waiting for about 14 minutes.

I checked the desktop logs and found that the process was not permanently crashed. It was stuck during startup for an extremely long time.

Timeline:

05:57:23.546 - Launching app
06:10:58.061 - Failed to load shell env
detail="Timed out after 5000ms."
durationMs=814512

The shell environment loading step therefore took about 13 minutes 34 seconds.

After that, startup immediately continued:

06:11:07.061 - stdio_transport_spawned
executablePath=C:\Users\<USER>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

06:11:08.057 - window main frame finished load

06:11:08.169 - Host startup critical-path phases completed
startupElapsedMs=825272

06:11:08.633 - window ready-to-show

So the total desktop startup took about 13 minutes 45 seconds.

This suggests that the "multiple ChatGPT.exe processes with MainWindowHandle=0" state was actually an extremely long startup hang, apparently around shell environment loading, rather than a permanent renderer crash.

Also, the external Codex CLI workaround is working: after the hang completes, the app successfully spawns:

C:\Users\<USER>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

One more useful detail: WSL detection happens later, after the GUI is already ready, so WSL does not appear to be the cause of this startup delay.

I encountered the same problem on the corresponding version as well.

I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

There are two separate failure layers in this report, and only the first one is in WinBridge Recovery's current scope.

The original Unable to locate the Codex CLI binary symptom, together with app\resources\codex.exe being marked Encrypted and Copy-Item failing with The specified file could not be encrypted, matches the Windows Application Protected / EFS -> user-side runtime relocation/materialization failure class. WinBridge can help diagnose that local layer by checking the packaged source attributes, the expected %LOCALAPPDATA%\OpenAI\Codex\bin materialization, partial/stale .staging-* state, version/hash consistency, and target-path/Junction problems. It does not modify WindowsApps or bypass package protection.

However, your follow-up narrows the remaining ~14 minute startup delay to a different layer: once CODEX_CLI_PATH points to the standalone CLI, Codex eventually spawns that external codex.exe successfully, and the long delay is concentrated in shell-environment loading (durationMs=814512). That shell-env startup stall is not something WinBridge currently repairs, and local runtime recovery should not be expected to fix it.

So WinBridge may be useful for recovering/confirming the initial protected-binary relocation failure, but it would not explain or guarantee a fix for the later shell-env hang. If the packaged executable in this build is consistently Application Protected in a way the desktop relocation code cannot copy, the durable fix still needs to be made upstream in Codex's Windows materialization/startup path.

Update: after keeping CODEX_CLI_PATH pointed to the standalone native codex.exe, the desktop app is now launching successfully again.

I tested a full exit and relaunch, and the GUI appeared in about 6 seconds.

So the current status on my machine is:

• bundled app\resources\codex.exe is still Archive, Encrypted
• the external CLI workaround via CODEX_CLI_PATH is active
• the app can now launch successfully
• I previously also observed one abnormally long startup hang (~14 minutes) before the GUI appeared

I can reproduce this on a second Windows machine with Codex Desktop 26.820.9563.0.

Additional reproduction details from my machine:

• Microsoft Store / MSIX package: OpenAI.Codex 26.820.9563.0
• Install location: C:\Program Files\WindowsApps\OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0
• Bundled CLI exists at app\resources\codex.exe
• Its file attributes include Encrypted
• A standalone Codex CLI workaround had previously allowed the older startup error to be bypassed
• After updating to 26.820.9563.0, multiple ChatGPT.exe processes start but no GUI window is created
• All observed ChatGPT.exe processes have MainWindowHandle = 0
• One process reaches ~497 MB working set / 59 threads and remains active, so the app is not simply failing to launch the process tree
• No codex.exe child process is present
• Clean uninstall + reinstall from Microsoft Store does not fix the issue
• Removed the standalone CLI and custom CODEX_CLI_PATH before reinstalling; same behavior
• --disable-direct-composition does not help
• --disable-gpu --disable-gpu-compositing --disable-software-rasterizer does not help
• No Crashpad report is generated

The desktop log stops after exactly these two lines:

2026-08-27T06:22:39.365Z 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:22:39.491Z info Appshot hotkey inactive configured=true enabled=false platform=win32

This started immediately after the update. The previous build was able to run after using the external CLI workaround, while 26.820.9563.0 remains headless even after a clean reinstall.

Additional evidence from the same affected machine after waiting for the window to eventually appear:

The app does recover, but only after a very long startup stall. The most suspicious log entry is the shell-environment load timeout:

2026-08-27T07:00:01.605Z warning Failed to load shell env caller=startup detail="Timed out after 5000ms." durationMs=267794 ... status=timed_out timeoutMs=5000

Key point: the configured timeout is 5 seconds, but the measured operation duration is 267794 ms (~4m28s).

Immediately after that delayed shell-env step returns, the rest of startup completes quickly:

2026-08-27T07:00:02.307Z info [StdioConnection] stdio_transport_spawned ... executablePath=C:\Users\wangf\AppData\Local\OpenAI\Codex\bin\d5f4c71927a04589\codex.exe
2026-08-27T07:00:02.308Z info [AppServerConnection] Transport start success connectionId=1 hostId=local transport=stdio
2026-08-27T07:00:02.833Z info [window-manager] window main frame finished load ... startupElapsedMs=1369 ...
2026-08-27T07:00:02.856Z info [AppServerConnection] initialize_handshake_result durationMs=548 ... outcome=success
2026-08-27T07:00:02.856Z info [AppServerConnection] Codex CLI initialized

So on this machine the CLI/app-server handshake and window load are healthy once the shell-environment step finally returns. The main delay appears to be before that, in startup shell-environment discovery/cancellation.

Observed behavior now:

• click Codex -> no visible window
• multiple ChatGPT.exe processes remain alive with MainWindowHandle = 0
• after roughly 8-10 minutes, the main window eventually appears and Codex works
• no Crashpad dump is generated

This looks very similar to the startup-recovery pattern described in #38766, where Failed to load shell env reports a duration far beyond its configured timeout and the window appears shortly afterward.

One additional PATH oddity visible in the log is a malformed entry: C:\Pro;ram Files\NVIDIA Corporation\NVIDIA App\NvDLISR (plus several duplicated Windows PATH entries). That may be local environmental noise, but regardless, a timeoutMs=5000 operation should not block the main startup path for ~268 seconds.

Independent reproduction on another Windows machine with Codex Desktop 26.820.9563.0. I’m adding the diagnostics because they provide additional evidence around the cua_node runtime staging path.

Observed behavior

• After the update, Codex Desktop launches background ChatGPT.exe processes but no window appears.
• Main process sample: Responding=True, MainWindowHandle=0, ~55 threads, ~490.8 MB working set, substantial CPU time.
• Desktop log for the affected launch contains only:

``text
info Launching app ... packaged=true platform=win32
info Appshot hotkey inactive configured=true enabled=false platform=win32
``
No app-server / BrowserWindow / renderer startup messages follow.

• No new Crashpad .dmp was produced and Windows Application log showed no standard Application Error / WER entry.
• AppModel-Runtime shows the MSIX activation itself succeeds (process/container creation events).
• Launching with --disable-gpu --disable-gpu-compositing --disable-software-rasterizer does not fix it. The GPU child process shows --use-gl=disabled, but no --type=renderer process is created.
• Repair/Reset did not fix it. A complete uninstall/reinstall also did not fix it.

Additional cua_node evidence

The packaged runtime is marked encrypted/protected:

$cua = "$((Get-AppxPackage OpenAI.Codex).InstallLocation)\app\resources\cua_node"
Get-ChildItem $cua -Force | Select Name,Mode,Length,Attributes

Observed:

bin           Directory, Archive, Encrypted
manifest.json Archive, Encrypted

And:

cmd /c cipher /c "$cua\manifest.json"

returns:

E manifest.json
Compatibility Level:
  Application Protected

More importantly, every failed desktop launch created a new staging directory under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node

There were 21 directories named like:

.staging-57937f104cca4dc5-XXXXXX

Most were ~152–153 MB; later attempts reached ~165 MB, ~220 MB, and ~232 MB, but none finalized into a normal 57937f104cca4dc5 runtime directory. The only completed runtime present was an older one:

f8d2abcb7481383b   ~274 MB   2026-07-24

The staging timestamps closely matched repeated failed launch attempts. Removing only the .staging-* directories reclaimed roughly 3 GB; a subsequent launch would be expected to recreate staging again.

CLI status

The separately installed CLI works normally:

codex --version
codex-cli 0.149.1

A cached per-user desktop CLI also existed and could execute, so this reproduction is not simply “no Codex CLI on disk”.

Interpretation

This independently reproduces the same 26.820.9563.0 headless-startup signature and adds strong evidence that the desktop startup is repeatedly attempting, but failing to finalize, the new cua_node runtime from Application Protected / Encrypted MSIX resources.

I would not claim this proves cua_node relocation is the only blocker: #41073 reports the same-version two-line/headless startup can be bypassed by disabling updater initialization (CODEX_SPARKLE_ENABLED=false), and #41059 also contains evidence of a very long shell-environment startup stall. It may be multiple interacting startup-path regressions. However, the repeated large .staging-* directories and Application Protected source files are deterministic on this affected machine and seem worth instrumenting/logging explicitly.

Additional confirmation from another affected Windows x64 machine on 26.820.9563.0.

I performed a clean-state reinstall test and the headless startup still reproduces.

Clean-state test

Before reinstalling, I backed up the useful Codex data and then removed the old Codex runtime/state so the new install would start without the previous custom environment:

• cleared the user CODEX_HOME and CODEX_CLI_PATH variables
• removed the old custom CodexHome / CodexRuntime
• removed/reset %APPDATA%\Codex
• removed/reset the AppX local profile under %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0
• uninstalled the Store package
• rebooted Windows
• reinstalled from Microsoft Store

The Store reinstall again installed:

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

The same failure remains: no window appears.

Process evidence

The app creates multiple responsive ChatGPT.exe processes. On a representative failed launch, all processes had:

Responding         : True
MainWindowHandle   : 0
MainWindowTitle    : <empty>

The main process was actively consuming CPU and had dozens of threads, so this was not the one-thread Wait/Suspended failure mode reported in some other Windows startup issues.

The observed process tree contained:

ChatGPT.exe                              (main process)
ChatGPT.exe --type=crashpad-handler
ChatGPT.exe --type=gpu-process
ChatGPT.exe --type=utility --utility-sub-type=network.mojom.NetworkService
ChatGPT.exe --type=utility --utility-sub-type=storage.mojom.StorageService

Notably, there was no --type=renderer process in the failed launches.

Additional checks

Windows NUL / Null kernel driver is healthy:

NUL_OK
SERVICE_NAME: Null
TYPE  : 1 KERNEL_DRIVER
STATE : 4 RUNNING

I also launched the packaged executable with:

--disable-direct-composition

The flag propagated to the main/GPU process, but the app still created no window and all MainWindowHandle values remained 0.

The desktop log again stopped immediately after the initial startup lines:

Launching app ...
Appshot hotkey inactive ...

No useful standard Application Error entry for ChatGPT.exe was produced in Event Viewer during these attempts.

This makes the failure look independent of the previous Codex profile, custom CODEX_HOME, custom CLI path, DirectComposition, and the Windows Null device. The strongest additional signal here is that the Chromium GPU/network/storage services start, but a renderer process is never created, while the main process remains alive and responsive.

I have not measured the maximum possible wait time for an unmodified launch, so I cannot rule out the very-long startup recovery behavior reported elsewhere, but during the troubleshooting runs the UI did not appear.

Additional reproduction from another affected Windows machine after a clean reinstall and restoration of only an external native runtime:

• E:\CodexRuntime\codex.exe restored successfully and runs as codex-cli 0.150.0-alpha.8.
• CODEX_CLI_PATH=E:\CodexRuntime\codex.exe is set and verified.
• CODEX_SPARKLE_ENABLED=false is also set.
• Launching the packaged app via Invoke-CommandInDesktopPackage still produces only ChatGPT.exe main/crashpad/GPU/network/storage processes.
• No codex.exe child process is spawned at all.
• No renderer process is present.
• All ChatGPT processes report Responding=True, but every MainWindowHandle remains 0.
• Main process accumulated substantial CPU (~61.75s) while remaining headless.

This narrows this machine's failure to a point before app-server/CLI spawn and before renderer creation. It also means the CODEX_SPARKLE_ENABLED=false workaround reported in #41073 does not resolve the issue on this machine.

The restored runtime files are ordinary Archive files (not Encrypted), while the Store package's ChatGPT.exe and bundled app\resources\codex.exe are both Archive, Encrypted.

Additional confirmed reproduction from my Windows machine:

• App version: 26.820.9563.0
• External runtime workaround active: CODEX_CLI_PATH=E:\CodexRuntime\codex.exe (codex-cli 0.150.0-alpha.8)
• CODEX_SPARKLE_ENABLED=false
• Fresh reinstall / clean profile state
• During the headless phase, all ChatGPT.exe processes reported Responding=True and MainWindowHandle=0; no codex.exe child process was present yet.
• I left the process running instead of killing/relaunching it.

The UI eventually appeared. In the monitoring window, the app was definitely still headless at 17:10:11 with Window=0, then at 17:10:21 the main process suddenly had a non-zero window handle (264270) and the login UI appeared.

During the observed headless period, the main process CPU time kept increasing steadily (roughly from 313.7s at 17:06:01 to 566.9s at 17:10:21), so this was not a suspended/idle process. It was actively consuming CPU while no renderer/main window was visible.

This further supports the interpretation that the app is stuck for several minutes on a pre-window startup path, then eventually continues and creates the UI. The behavior is consistent with the long startup delays reported in #41056 / #38766, but on this machine the process remains responsive and CPU-active throughout the observed stall.

Additional confirmed reproduction and a successful workaround from another Windows x64 machine.

Environment / signature

• Package: OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0
• Windows user profile path was ASCII-only: C:\Users\<ascii-user>
• Package status was Ok; Microsoft Store reported the latest version installed.
• The initial launch first showed: Unable to locate the Codex CLI binary.
• After reinstall/reset, normal activation succeeded at the AppModel layer, but no window appeared and the Codex/ChatGPT processes exited.
• The desktop log stopped after exactly:
• Launching app ... packaged=true platform=win32
• Appshot hotkey inactive ...
• No matching Application Error, Code Integrity event, or Crashpad .dmp was generated.

Every launch created a new incomplete runtime directory under:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\.staging-57937f104cca4dc5-<random>

No completed 57937f104cca4dc5 runtime directory existed. Three separate launch attempts left three staging directories.

Directly copying the installed resources reproduced an encryption/materialization failure:

• Copy-Item ...\app\resources\codex.exe failed with The specified file could not be encrypted.
• robocopy ...\app\resources\cua_node <user-writable-target> /E failed immediately with Windows error 6000 (0x00001770), also reporting The specified file could not be encrypted.

Workaround that restored the GUI

The original official ChatGPT-x64.msix used for installation was still available in Downloads (788,381,543 bytes). Instead of copying from the Application Protected / Encrypted files under WindowsApps, I opened that original MSIX as a ZIP archive using System.IO.Compression.ZipFile and extracted only entries below:

app/resources/cua_node/

The extraction produced 4,680 files. I placed those unencrypted files at:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\57937f104cca4dc5

The hash was taken from the observed staging-directory prefix; it should not be hardcoded across app/runtime versions.

After this directory was populated, launching the packaged app immediately created the GUI and the app became usable. No external CODEX_CLI_PATH workaround was required for this final recovery.

This result strongly points to the cua_node materialization/finalization path from installed Application Protected resources as the blocker on this machine. It also shows the failure is not limited to non-ASCII Windows profile paths. The updater should either materialize these resources through a package-aware API, avoid preserving an unusable encryption attribute, or surface a clear recoverable error instead of stopping after the two initial log lines.

Related staging/runtime reports: #28017, #28245.

I encountered a similar problem in version 26.820.9563.0. After clicking on the ChatGPT software, it failed to start. In the Task Manager, there were processes running, but no error messages were displayed and no window appeared. But I found a solution.

My setup had the standalone Codex CLI installed, and I had previously set the user-level CODEX_CLI_PATH to:

C:\Users\<USER>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

With CODEX_CLI_PATH set, ChatGPT Desktop launched only background processes. The main process, crashpad, GPU process and utility processes were present, but no --type=renderer process was created and all MainWindowHandle values remained 0.

I removed the user-level environment variable:

[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", $null, "User")

After relaunching ChatGPT, the application started normally and the GUI appeared.

So on my machine, the standalone Codex CLI itself does not appear to be the problem. The issue is specifically caused by CODEX_CLI_PATH pointing to the standalone native codex.exe.

This may be a regression in 26.820.9563.0, because that environment-variable workaround had previously been used to bypass the bundled CLI / Access Denied issue.

Working workaround: unset CODEX_CLI_PATH and allow the desktop app to use its bundled/default CLI resolution.

my codex's version is 26.820.71523,.Today my codex GUI cannot open with its processes hanging in the background. I removed the user-level environment variable CODEX_CLI_PATH. Then the GUI reappeared immediately as usual.What happened？