Windows app launches background Electron processes but never spawns codex.exe or creates a window
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?
- Install/update the Codex Windows app to version 26.820.9563.0.
- Launch the app normally from the Start menu or app icon.
- No visible window appears.
- 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
- Multiple ChatGPT.exe processes are running, including the main process, crashpad handler, GPU process, network service, and storage service.
- No codex.exe child process is created.
- 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.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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:
%LOCALAPPDATA%\OpenAI\Codex\bincontains a complete current-version materialization or only stale/partial hash directories;.staging-*relocation directories were left behind after a protected-file copy failure;codex.exe/helpers match the currently installed package by size/hash;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.exeworks, and that even with a validCODEX_CLI_PATHthe 26.820.9563.0 desktop process still stops atapp-server ... connectingwithout spawningcodex.exeor 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.Same problem! man!
Same problem, but I use CLI to continue working, 20 minutes later, it appeared on its own