Skip to content

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

Open

Description

@CamilleJames

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.

  2. Launch the app normally from the Start menu or app icon.

  3. No visible window appears.

  4. 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.

  2. No codex.exe child process is created.

  3. 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.

Activity

  1. added
    appIssues related to the Codex desktop app
    on Aug 27, 2026
  2. added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    app-serverIssues involving app server protocol or interfaces
    on Aug 27, 2026
  3. zemeng5208 commented on Aug 27, 2026

    @zemeng5208

    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.

  4. yxymeng commented on Aug 27, 2026

    @yxymeng

    Same problem! man!

  5. WayneCan commented on Aug 27, 2026

    @WayneCan

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

  6. suizhejiu commented on Sep 13, 2026

    @suizhejiu

    Same phenotype here, and I was able to trace it to the package's AppX volume on my machine — worth checking before applying caching workarounds.

    Diagnostic that identified it (read-only):

    Get-AppxPackage OpenAI.Codex | Select-Object InstallLocation
    Get-Item (Get-AppxPackage OpenAI.Codex).InstallLocation -Force |
      Select-Object FullName, LinkType, Target
    Get-AppxVolume | Select-Object PackageStorePath, IsSystemVolume

    On the affected machine the package directory was a junction to a secondary AppX volume:

    LinkType : Junction
    Target   : D:\WindowsApps\OpenAI.Codex_<version>_x64__2p2nqsd0c76g0
    D:\WindowsApps ... IsSystemVolume = False
    

    With that layout the packaged codex.exe group never relocated into %LOCALAPPDATA%\OpenAI\Codex\bin\<hash> (bundled_executable_relocation_failed), so no codex.exe child process spawned and no window was ever shown — exactly the symptom you describe (MainWindowHandle = 0, no backend). The log also showed EXDEV: cross-device link not permitted on renames that appear to be within a single directory.

    What resolved it on that machine: moving the package to the system volume (Move-AppxPackage -Package <full name> -Volume (Get-AppxVolume | Where-Object IsSystemVolume), or Settings → Apps → Installed apps → ChatGPT → Move → C:), then removing any CODEX_CLI_PATH override and the materialized bin\<hash> caches. After the move the app staged its own runtime and started normally; bundled_executable_relocation_failed went to zero.

    Details, before/after measurements, and the caveat that this does not fix the separate EFS/Application-Protected copy failure are in #40700: #40700 (comment)

    Caveat: this is one machine, verified by measurement. If LinkType is not a junction (single-volume install), your failure has a different cause and the EFS copy path is the more likely explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions