[Windows] Codex Desktop crashes on launch in chrome.dll with 0xC0000005

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

• #25358

Powered by Codex Action

You can check whether your system has this environment variable set:
NODE_OPTIONS=--openssl-legacy-provider
If it exists, try deleting it and then see if Codex launches normally.

Well, I'll be damned - it worked. How? What?

That variable was probably set for some dev project, but it ends up affecting everything else on the machine — including Codex, which is an Electron app (Electron runs on Node). Electron doesn't allow --openssl-legacy-provider in NODE_OPTIONS, so when it sees that flag it exits immediately, before showing any window. That's the silent "won't launch."

Kudos, really.

I am seeing the same immediate launch crash on the Microsoft Store Windows app.

Environment

• OS: Microsoft Windows 11 Home Single Language 10.0.26200 build 26200, 64-bit
• Codex package: OpenAI.Codex_26.609.3341.0_x64__2p2nqsd0c76g0
• Codex app version/package version: 26.609.3341.0
• Package status: Ok
• AppID: OpenAI.Codex_2p2nqsd0c76g0!App

Behavior

• Launching Codex from the Start Menu / shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App creates the app process briefly.
• No visible window appears.
• The process exits immediately.
• A new Crashpad .dmp is created on every launch under:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex\Crashpad\reports

Crash metadata from latest minidump

• Exception code: 0xc0000005
• Exception address: 0x7ffb3c5509ab
• Exception parameters: 0x0, 0x1f0
• Faulting module: chrome.dll
• Module path: ...\OpenAI.Codex_26.609.3341.0_x64__2p2nqsd0c76g0\app\chrome.dll

Troubleshooting already tried

• Checked Microsoft Store/winget update: no newer package available.
• Re-registered the AppX package with Add-AppxPackage -DisableDevelopmentMode -Register AppxManifest.xml.
• Retested launch: still created a new dump immediately.
• Renamed the UI cache folder so Codex recreated a fresh cache.
• Retested launch: still created a new dump immediately.
• Ran Reset-AppxPackage for OpenAI.Codex.
• Retested launch: still created a new dump immediately.
• Uninstalled and reinstalled Codex from Microsoft Store via winget.
• Retested launch: still created a new dump immediately.

Latest post-reinstall dump was generated at 2026-06-12 20:13:26 Asia/Jakarta. I am not attaching the dump publicly by default, but it is available if maintainers need it through a safer channel.

Follow-up: on the same machine, launching through the Start Menu / shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App still crashes immediately and creates a Crashpad dump.

However, directly launching the installed package executable works and does not create a new dump:

$pkg = Get-AppxPackage -Name OpenAI.Codex
$exe = Join-Path $pkg.InstallLocation 'app\Codex.exe'
Start-Process -FilePath $exe

After direct launch, multiple Codex.exe child processes remain alive, plus the bundled app\resources\codex.exe, and no new Crashpad dump is generated. This suggests the issue on this system is tied to the AppX/Start Menu activation path rather than the bundled app binary being completely unusable.

I can reproduce the same native Windows crash on a newer Codex Desktop build, with a stable fault offset across two independently captured dumps.

Environment and update

• Codex Desktop/AppX: 26.707.9981.0
• Updated from 26.707.9564.0 at 2026-07-14 08:44:46 local time
• Get-AppxPackage reports Status: Ok; AppX deployment completed successfully

Crash evidence

| Run | Local crash time | Desktop PID | Dump size | Dump status / SHA-256 |
| --- | --- | ---: | ---: | --- |
| 1 | 09:09:30 | 2764 | approximately 40 MB | rotated by Crashpad; hash unavailable |
| 2 | 09:33:04 | 25920 | 40,700,704 bytes | rotated by Crashpad; recorded SHA-256 ec0eaf1a11d0129c325e71ba25ba61bdbb40ec85ab5e33c1c3d2e50831a88c65 |
| 3 | 09:57:19 | 10276 | 40,753,232 bytes | available; SHA-256 9b240ec369f3c1e769c04a40255a8494ec0c91dcf1e98e5d0245c5f0f4bea1a2 |

Crashes 2 and 3 have the exact same minidump signature: 0xC0000005 at chrome.dll+0x2E08F46. In run 3, the Desktop process stayed up for about 10 minutes, then the final log event was Browser Use's embedded webview reaching dom-ready on about:blank; the Crashpad dump followed about 1.3 seconds later. The log ends abruptly, with no normal shutdown sequence.

Sanitized log references for run 3:

• lines 124-167: bundled Browser plugin reconciliation; the final config write preserves enabled=false
• lines 948-977: embedded IAB/Browser Use lifecycle
• lines 955-977: hidden Browser Use webview creation, attachment, and the final dom-ready event

Additional isolation performed:

• chat_processes.json contained NUL bytes before run 1. It was quarantined; the associated parsing error disappeared and the file was not regenerated, but crashes 2 and 3 still occurred.
• browser@openai-bundled remained enabled=false throughout run 3. Codex reconciled the plugin while preserving that state, but the separate embedded IAB subsystem still created its Browser Use webview and the crash persisted.
• No OOM, GPU-process failure, render-process-gone, app-server exit/disconnect, or normal shutdown event appears immediately before the crash.
• I did not reinstall because the AppX package is healthy, reinstalling would deploy the same build, and this issue already reports that reinstall did not change the failure.

This appears to rule out the corrupted chat-process state and the Browser plugin enable flag as sufficient explanations. It does not rule out the embedded Browser Use/Electron/Chromium path; the repeated chrome.dll offset immediately after webview readiness makes that path the strongest current correlation.

Would the maintainers like the latest dump, sanitized logs, and the parsed metadata retained from the rotated dumps through a private channel? Also, is 26.707.9981.0 known to contain either a fix or a regression related to this Chromium/IAB crash signature?