Windows app launches background Electron processes but never spawns codex.exe or creates a window

Open 💬 4 comments Opened Aug 27, 2026 by CamilleJames
💡 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 (From “About Codex” dialog)?

26.820.9563.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex Windows app launches several ChatGPT.exe background processes but never creates a visible window.

This started after the app updated from 26.820.7780.0 to 26.820.9563.0.

Before the update, 26.820.7780.0 failed with:

"ChatGPT failed to start.
Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex."

After updating to 26.820.9563.0, that dialog disappeared, but clicking the app icon now produces no visible UI. Multiple ChatGPT.exe processes remain running in the background, all with MainWindowHandle = 0.

The app also never spawns a codex.exe child process.

The bundled CLI exists at:

C:\Program Files\WindowsApps\OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

The bundled executable is reported by cipher as:

E codex.exe
Compatibility level:
Application Protected

I copied the executable with xcopy /G to an unencrypted local path. The copied executable works normally:

codex-cli 0.150.0-alpha.8

I also tested the app server directly:

codex.exe app-server --listen ws://127.0.0.1:4500

It starts successfully and remains alive:

codex app-server (WebSockets)
listening on: ws://127.0.0.1:4500
readyz: http://127.0.0.1:4500/readyz
healthz: http://127.0.0.1:4500/healthz

I set CODEX_CLI_PATH to the working unencrypted executable and rebooted Windows. The variable is present after reboot, Test-Path returns True, and running the CLI manually works. However, the desktop app still never spawns codex.exe and never creates a window.

Startup logs consistently stop at:

[AppServerConnection] Initializing app-server transport
[AppServerConnection] Starting app-server connection hostId=local transport=stdio
[AppServerConnection] app_server_connection.state_changed cause=start_process ... next=connecting ... transport=stdio

There is no subsequent codex.exe process or successful app-server connection.

What steps can reproduce the bug?

  1. Install/update the Codex Windows app to version 26.820.9563.0.
  1. Launch the app normally from the Start menu or app icon.
  1. No visible window appears.
  1. Check the process list:

Get-CimInstance Win32_Process |
Where-Object {
$_.Name -eq "ChatGPT.exe" -or $_.Name -eq "codex.exe"
} |
Select-Object ProcessId, ParentProcessId, Name, CommandLine |
Format-List

  1. Multiple ChatGPT.exe processes are running, including the main process, crashpad handler, GPU process, network service, and storage service.
  1. No codex.exe child process is created.
  1. Check window handles:

Get-Process ChatGPT -ErrorAction SilentlyContinue |
Select-Object Id, MainWindowHandle, MainWindowTitle, Responding

All ChatGPT.exe processes have MainWindowHandle = 0.

Additional reproduction / diagnosis:

  • The bundled codex.exe exists in app\resources.
  • cipher /c reports the bundled executable as "Application Protected".
  • Copying it with xcopy /G produces an unencrypted executable that works normally.
  • The manually copied executable successfully runs codex --version.
  • The manually copied executable successfully runs codex app-server.
  • Setting CODEX_CLI_PATH to that executable and rebooting Windows does not fix the desktop app.
  • Manually placing the unencrypted codex.exe in both:

%LOCALAPPDATA%\OpenAI\Codex\bin\codex.exe
and
%LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe
also does not fix the issue.

The desktop app still stops before spawning codex.exe.

What is the expected behavior?

Launching the Codex Windows app should start the local codex.exe app-server process and create a visible desktop window.

If the bundled CLI needs to be relocated from the WindowsApps package, the app should successfully create or use a runnable local copy of codex.exe and connect to it.

The GUI should then open normally instead of leaving only background Electron processes running.

Additional information

Package information:

Name: OpenAI.Codex
Version: 26.820.9563.0
Status: Ok
Install location:
C:\Program Files\WindowsApps\OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0

The default AppX package volume on this machine is:

D:\WindowsApps

while the installed OpenAI.Codex package is currently located on:

C:\Program Files\WindowsApps\...

The bundled CLI is approximately 293.32 MB.

The working manually copied CLI reports:

codex-cli 0.150.0-alpha.8

The app previously logged Chromium disk-cache errors:

Corrupt Index file
Unable to move the cache: The system cannot move the file to a different disk drive. (0x11)
Unable to create cache

I tested launching the app with a new cache directory using:

--disk-cache-dir=%LOCALAPPDATA%\OpenAI\Codex\cache-test

The cache errors disappeared, but the app still failed at exactly the same app-server startup stage and still did not create a window.

Therefore the disk-cache issue appears to be secondary.

The important observation is that the CLI and app-server work independently, but the desktop app never spawns codex.exe.

I have also already tried:

  • Repairing/resetting the Windows app
  • Reinstalling the app
  • Updating from 26.820.7780.0 to 26.820.9563.0
  • Rebuilding the Codex runtime cache
  • Disabling WSL mode in config.toml
  • Setting runCodexInWindowsSubsystemForLinux = false
  • Providing a working CODEX_CLI_PATH
  • Rebooting Windows
  • Manually placing an unencrypted codex.exe in the expected local bin directories

None of these restored the GUI.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 23 hours ago

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

  • #41059
  • #41075
  • #41056
  • #41120
  • #41073

Powered by Codex Action

zemeng5208 · 22 hours ago

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

This issue overlaps with one of the Windows-local failure classes WinBridge is designed to diagnose: bundled CLI/runtime relocation from the MSIX/WindowsApps package into the per-user Codex runtime state, especially when the source is reported as Encrypted / Application Protected and ordinary copy operations fail.

For this case, the useful local checks are narrowly scoped to:

  • whether %LOCALAPPDATA%\OpenAI\Codex\bin contains a complete current-version materialization or only stale/partial hash directories;
  • whether .staging-* relocation directories were left behind after a protected-file copy failure;
  • whether the locally materialized codex.exe/helpers match the currently installed package by size/hash;
  • whether a target path/reparse-point/Junction problem is being confused with an Application Protected/EFS copy failure;
  • whether the current package update left old runtime/helper state that can be safely rebuilt on the user side.

WinBridge does not modify WindowsApps, take ownership of package files, bypass Application Protected/EFS, or replace the Store package. It also cannot guarantee a fix.

There is an important limitation in this report: you already demonstrated that a decrypted standalone/local codex.exe works, and that even with a valid CODEX_CLI_PATH the 26.820.9563.0 desktop process still stops at app-server ... connecting without spawning codex.exe or creating a window. If the per-user relocation/materialization state is already complete and consistent, that remaining headless-startup behavior is likely above WinBridge's repair layer (for example the desktop bootstrap/app-server spawn path in this build) and would still need an upstream Codex fix.

yxymeng · 20 hours ago

Same problem! man!

WayneCan · 20 hours ago

Same problem, but I use CLI to continue working, 20 minutes later, it appeared on its own