›_ Codex Issues
Codex Issues / #31153

Issue when Codex app on Windows fails to start

Open 💬 2 comments Opened Jul 5, 2026 by ytiq
💡 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.616.6631.0

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

On start for both Codex and Codex (beta) the process ends after a couple of seconds of running, before starting the GUI.

I was able to solve it for myself personally with Codex CLI, but in no way the issue was visible and the app was just failing silently.

Here is the Codex summary:

## Windows Codex launch failures: missing sandbox helpers + Electron crash from NODE_OPTIONS

### Environment

  • OS: Windows
  • App: Codex Beta MSIX / Store package
  • Codex Beta package version observed: 26.616.6631.0
  • Codex CLI version observed: codex-cli 0.142.5
  • CLI path pattern: %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe
  • Standalone release path pattern: %USERPROFILE%\.codex\packages\standalone\releases\0.142.5-x86_64-pc-windows-msvc

### Issue 1: Sandbox helper binaries are not discoverable by installed CLI

Sandboxed command execution failed before the command process started.

Observed log:

```text
setup refresh: spawning codex-windows-sandbox-setup.exe
setup refresh failed to launch helper: helper=codex-windows-sandbox-setup.exe, error=program not found

The helper binary existed in the standalone release:

...\0.142.5-x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe

But it was not discoverable from the active CLI environment. The active PATH included:

...\0.142.5-x86_64-pc-windows-msvc\codex-path
%LOCALAPPDATA%\Programs\OpenAI\Codex\bin

codex-path contained rg.exe, but not codex-windows-sandbox-setup.exe.

After manually copying codex-windows-sandbox-setup.exe into the PATH-visible location, the failure progressed to a second missing helper:

helper copy failed for command-runner: helper not found next to current executable or under codex-resources:
%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe;
falling back to legacy path codex-command-runner.exe

Copying the matching codex-command-runner.exe from the same 0.142.5 release into:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin

allowed sandboxed commands to run successfully again.

### Suspected root cause

The Windows CLI install/update seems to expose only codex.exe under:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin

while required helper executables remain under the standalone release codex-resources directory and are not reliably discoverable.

Codex appears to expect helpers either:

  • next to the current codex.exe, or
  • under a nearby codex-resources path, or
  • available by bare executable name via PATH.

### Suggested fix

  • place codex-windows-sandbox-setup.exe and codex-command-runner.exe next to the installed codex.exe, or
  • add the correct codex-resources directory to helper resolution, or
  • populate codex-path with all executables that are later launched by bare name.

———

The Codex Beta desktop app launched, created an AppX container, then immediately exited and produced Crashpad dumps.

Windows AppModel events showed:

Created process ... for application OpenAI.CodexBeta...!App
Destroyed Desktop AppX container ... for package OpenAI.CodexBeta...

electron: --openssl-legacy-provider is not allowed in NODE_OPTIONS

Removing the user-level environment variable:

NODE_OPTIONS=--openssl-legacy-provider

from HKCU\Environment, then restarting Explorer, allowed the Codex Beta desktop app to launch and stay running.

Electron rejects some Node options inherited through NODE_OPTIONS. If the user has a global NODE_OPTIONS value, Codex Beta can crash before its app bootstrap starts.

This is not unique to Codex, but the current user-facing behavior is a silent crash with only Crashpad evidence.

### Suggested fix

Before Electron/Node initialization, the app launcher should defensively sanitize unsupported NODE_OPTIONS values, or at least detect this condition and show a clear error.

Useful handling could be:

  • ignore/remove NODE_OPTIONS for the packaged app process, or
  • validate it and show a dialog explaining which value prevents startup, or
  • document that global NODE_OPTIONS is unsupported for the desktop app.

### Workaround used

  1. Removed the bad user-level environment variable:

reg delete HKCU\Environment /v NODE_OPTIONS /f

  1. Restarted Explorer so MSIX/Start-menu app launches inherited the clean environment.
  2. Verified that Codex Beta processes stayed running and no new Crashpad dump appeared.

What steps can reproduce the bug?

Launch latest version of Codex and Codex (beta) from Windows store

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #30732
  • #30856
  • #30829
  • #30047

Powered by Codex Action

puppylsy · 1 month ago

I can confirm that this issue still reproduces on the current Windows Store build, and I was able to correlate the rejected NODE_OPTIONS value with a misleading native Crashpad signature in chrome.dll.

Environment

  • Windows 11 Home 25H2, x64
  • OS build: 26200.8894
  • Microsoft Store package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
  • Bundled Chromium/Electron version: 150.0.7871.128
  • Executable: ChatGPT.exe

The same behavior was previously reproduced on:

  • Codex package 26.707.3748.0
  • Bundled Chromium 150.0.7871.101
  • Windows build 26200.8655

Symptoms

Launching the app from the Start menu produced no visible window.

Windows AppModel-Runtime showed the following sequence within the same second:

  1. AppX container created successfully.
  2. ChatGPT.exe process created successfully.
  3. Process added to the AppX container.
  4. AppX container immediately destroyed.

No useful application log or normal Application Error event was produced. A new Crashpad minidump was generated on every launch.

The problem also reproduced in a newly created local Windows account with fresh per-user application data.

Crashpad / WinDbg signature

WinDbg reported:

PROCESS_NAME: ChatGPT.exe
EXCEPTION_CODE: 0xc0000005
AV.Type: Read
Failure.Bucket: INVALID_POINTER_READ_c0000005_chrome.dll!Unknown
Failure.Hash: {5cd13162-58f6-4190-dced-e6b658b0f99b}

chrome!v8::Context::Exit+0x1b
rax = 0000000000000000

movzx r8d, word ptr [rax+1F8h]
Attempt to read from address 00000000000001f8

The top of the stack was:

chrome!v8::Context::Exit+0x1b
chrome!node::AsyncResource::CallbackScope::~CallbackScope
chrome!ChromeMain
ChatGPT.exe

The same failure hash, null-pointer read address, and v8::Context::Exit+0x1b signature occurred on both Chromium 150.0.7871.101 and 150.0.7871.128. Only the module-relative offset changed after the application update.

The loaded-module list contained only Codex/Chromium and normal Windows modules; no obvious third-party DLL injection was present.

Root cause identified

Launching the packaged executable directly from PowerShell exposed the actual earlier startup error:

electron: --openssl-legacy-provider is not allowed in NODE_OPTIONS

The Windows environment contained:

NODE_OPTIONS=--openssl-legacy-provider

After removing NODE_OPTIONS from the launch environment, the same ChatGPT.exe started successfully.

This suggests that the Electron rejection is the primary startup failure, while the subsequent:

chrome!v8::Context::Exit+0x1b

access violation occurs during abnormal shutdown or callback-scope cleanup. The native crash therefore hides the actionable configuration error and makes the problem appear to be an unrelated Chromium crash.

This may also explain some reports such as #25376 and #28883 where the visible evidence consists only of an AppX container being destroyed and a chrome.dll Crashpad dump.

Suggested improvements

  1. Clear or sanitize inherited NODE_OPTIONS before initializing the packaged production Electron runtime.
  2. If the environment variable cannot safely be ignored, use a native launcher/preflight check to display an actionable error dialog before Electron exits.
  3. Write the rejected environment variable name and option to a plain-text startup log.
  4. Detect this known Crashpad signature and direct users to check NODE_OPTIONS.
  5. Document that globally setting --openssl-legacy-provider is incompatible with the Windows desktop app.

Raw memory dumps are not attached publicly because they may contain process memory and private data, but sanitized WinDbg output can be provided if requested.