›_ Codex Issues
Codex Issues / #37164

# [Windows] Desktop app crashes ~10s after UI loads, reproducible with a completely empty CODEX_HOME (0xc0000409, utility process)

Open 💬 14 comments Opened Aug 5, 2026 by Magnum91-jen
💡 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.730.8199.0 (x64, Microsoft Store package OpenAI.Codex). Version taken from Get-AppxPackage — the About dialog is not reachable because the app dies before it can be opened.

What subscription do you have?

ChatGPT Pro (Max 20x)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 11)

What issue are you seeing?

Summary

The Codex desktop app starts, renders the full UI, and then terminates silently after roughly 10 seconds. This is fully reproducible, including on a completely fresh state: with %USERPROFILE%\.codex moved aside, the app behaved like a new installation, sign-in succeeded, and it crashed while still on the welcome screen — no projects, no sessions, no config.

The Codex CLI (codex-cli 0.147.0-alpha.1.2) works flawlessly on the same machine, same user profile, same .codex directory. The problem is confined to the desktop package.

What steps can reproduce the bug?

Steps to reproduce

  1. Launch the Codex app from the Start menu.
  2. The window opens and the UI finishes mounting (logs report app routes mounted after ~18000ms).
  3. Roughly 10 seconds later the process exits without any error dialog.
  4. A new Crashpad dump appears under

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

Every launch attempt reproduces this.

Expected behavior

The app stays open and usable.

Crash signature

From the Windows Application event log (entries recorded on earlier launches under package 26.727.6591.0):

Faulting application name: codex.exe, version: 0.0.0.0
Faulting module name:      codex.exe, version: 0.0.0.0
Exception code:            0xc0000409
Fault offset:              0x000000000d71d4a1
Faulting package:          OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0

The fault offset is identical across separate incidents on different days, which suggests a single deterministic code path rather than random memory corruption.

0xc0000409 is a fast-fail abort, not an access violation — the process is terminating itself on a failed internal check, not dereferencing bad memory.

Dump analysis

  • Dump size: ~39–41 MB, a new one on every launch.
  • String scan for loaded modules outside System32/SysWOW64/WinSxS returns only chrome.dll and chrome_elf.dll from the Codex package itself. No antivirus, VPN, DRM, or other injected third-party modules are present.
  • Process-type strings in the dump: utility (6 occurrences), renderer (1). The crashing process appears to be a utility process, not the browser main process or the GPU process.
  • No Out of memory, CHECK failed, or DCHECK failed strings were recoverable from the dump via a plain ASCII/UTF-16 scan.
  • Notably, the most recent crashes produce a Crashpad dump but no Windows Application error event, consistent with a child-process abort handled entirely by Crashpad.

What was ruled out

Each of the following was tested and did not resolve the crash:

| Hypothesis | Test | Result |
|---|---|---|
| Non-ASCII characters in the user profile path | Profile path is pure ASCII | Not applicable |
| Third-party module injection | Dump module scan | Only Codex's own Chromium DLLs |
| Missing workspace root | Recreated the deleted directory | Still crashes |
| Corrupt session file (auto-resume) | Moved the resumed session's .jsonl aside | Still crashes |
| Oversized session files | Moved all .jsonl > 50 MB aside (29.3 GB total) | Still crashes |
| Any user state at all | Moved %USERPROFILE%\.codex aside entirely | Still crashes, on the welcome screen after a fresh sign-in |
| Corrupt package state | Settings → Repair | Still crashes |
| Corrupt package state | Settings → Reset | Still crashes |

Package re-registration via Add-AppxPackage -Register was also attempted.

Since the crash reproduces with an empty CODEX_HOME and a freshly reset package, both user data and local environment can be excluded as causes.

Additional observations

These may or may not be related, but were visible in the startup logs preceding each crash.

1. git-init-watcher retry loop on a missing workspace root.
A workspace whose root directory no longer exists produces a tight retry loop, four failures within four seconds, each logging a full stack trace:

warning [git-init-watcher] Failed to watch workspace root for git init
  cwd="F:\\<removed>" errorCode=ENOENT

A missing workspace root should be handled once and marked unavailable, not retried in a loop.

2. Cloudflare challenge on a backend call blocks startup for 15 seconds.
app/read against chatgpt.com/backend-api/ps/apps/batch returned HTTP 403 with a managed-challenge page after a 15-second wait, logged as failed to read app metadata. The UI took ~18 seconds to mount and main_thread_jank_snapshot counted several jank events during this window.

3. Session rollout files grow without bound.
On this installation the largest single session .jsonl had reached 26.7 GB, with several others between 150 MB and 940 MB — about 29 GB in total. Sessions involving the computer-use and browser plugins appear to write base64-encoded screenshots into the rollout on every step. This did not turn out to be the cause of the crash, but a session log that can reach tens of gigabytes seems worth a size cap or rotation policy independently.

Impact

Complete blocker for the desktop app. The CLI remains usable as a workaround.

I can provide the Crashpad dumps and full startup logs privately if that helps — I am not attaching them here because they contain local paths and project data.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

14 Comments

github-actions[bot] contributor · 22 days ago

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

  • #36619

Powered by Codex Action

nawabjan1 · 22 days ago

Same issue here. Windows 11, OpenAI.Codex 26.730.8199.0 (Microsoft Store, x64).

  • App auto-updated from 26.727 on Aug 5 (updater log shows sparkle ... download_completed at 19:15 UTC); every launch since crash-loops ~10 seconds after the UI loads.
  • New Crashpad dump under LocalCache\Roaming\Codex\web\Codex\Crashpad\reports on every launch.
  • Reproduces with a completely fresh browser profile (moved ...\web\Codex aside) — still crashes on clean state, so user data ruled out here too.
  • Clearing Chromium caches and launching with --disable-gpu made no difference.
  • In my dumps the crash is in the browser (main) process: exception 0x80000003 at chrome.dll+0x39E0B4D, identical address on every crash (slightly different signature from OP's utility-process 0xc0000409, but same user-visible behavior).
  • Codex CLI 0.145.0 works fine on the same machine and account.

Can share dumps and startup logs if helpful.

Magnum91-jen · 22 days ago

Update (2026-08-06):
Still reproducible on 26.730.8199.0. Additional data points:

codex doctor (CLI 0.147.0-alpha.1.2) reports 17 ok, 0 warnings, 0 failures: all SQLite databases pass integrity checks, rollout inventory matches the state DB (0 scan errors, 0 duplicates, 0 stale rows), auth configured, WebSocket handshake succeeds (HTTP 101), config.toml parses cleanly.
The app does not crash while signed out — it sits stable on the start screen indefinitely. It crashes only after signing in, roughly 10 seconds after the UI renders, immediately following thread/start.
Startup logs show every app-server call responding with 5–7 s latency; modelProvider/capabilities/read times out at 1000 ms and then answers after 5.8 s, followed by No promise for request ID.
Archiving the pinned/most-recent thread did not help. Installing ripgrep (the only item doctor had flagged) did not help.

Magnum91-jen · 22 days ago
Potential duplicates detected. Please review them and close your issue if it is a duplicate. * [[Windows Desktop 26.727.6591.0] app-server crashes under commit-memory exhaustion and does not auto-recover #36619](https://github.com/openai/codex/issues/36619) _Powered by Codex Action_

Thanks — related, but not a duplicate of #36619.

Shared: identical fault offset 0x0d71d4a1, identical app timestamp 0x6a6a8fcf, same package 26.727.6591.0, same OS build 26200. So very likely the same fast-fail path in the same binary.

Different trigger and different symptom:

#36619 is triggered by external commit-memory exhaustion (a Node process at 40–50 GB, System event 2004). My machine shows no memory pressure and no event 2004.
In #36619 the UI survives and only the app-server dies. In my case the entire app terminates, on every launch, ~10 s after the UI renders.
Mine reproduces with a completely empty CODEX_HOME and a fresh sign-in, on the welcome screen — no workspaces, no sessions, no config. It does not crash while signed out.
Still reproducible on the newer build 26.730.8199.0.
codex doctor reports 17 ok / 0 warnings / 0 failures.

Since #36619 is closed as not planned with its root cause attributed to an external Node memory leak, closing this as a duplicate would lose a case that has no external trigger. Happy to cross-link instead.

Magnum91-jen · 22 days ago

Update (2026-08-06) — still reproducible, and further local causes ruled out

Still crashing on package 26.730.8199.0 (updated from 26.727.6591.0; the crash predates and survives that update).

Key new finding: the crash is tied to the signed-in state.

  • Signed out, the app sits on the start screen indefinitely and stays completely stable.
  • After signing in, the full UI renders, then the process terminates roughly 10 seconds later.
  • The last thing in the startup log before termination is thread/start, immediately after the plugin marketplace is written and skills/list completes.

Additional things tried since the original report, none of which helped:

  • Archived the pinned / most recently used thread via codex archive <id>.
  • Moved all 36 local rollout files out of ~/.codex/sessions (empty sessions directory), then signed out and back in via the CLI. UI came up, projects reappeared from the account, still crashed.
  • Installed ripgrep — the only item codex doctor had flagged.
  • Settings → Repair and Settings → Reset on the MSIX package.

codex doctor (CLI 0.147.0-alpha.1.2) on the same machine: 17 ok / 0 warnings / 0 failures.

  • All four SQLite databases pass integrity checks.
  • Rollout inventory agrees with the state DB: 0 scan errors, 0 malformed names, 0 stale rows, 0 duplicates, 0 archive mismatches.
  • config.toml parses cleanly, auth configured, WebSocket handshake succeeds (HTTP 101).
  • The CLI itself works flawlessly on the same profile and the same CODEX_HOME.

Observation that may be relevant: after signing back in with an empty local sessions directory, the sidebar immediately repopulated with projects and pinned threads from the account. Whatever state the app chokes on appears to be server-side rather than local, which would explain why no amount of local cleanup, reset, or reinstall changes the outcome.

Startup latency pattern preceding every crash: all app-server calls respond with 5–7 s latency; modelProvider/capabilities/read times out at its 1000 ms budget and then answers after 5.8 s, followed by No promise for request ID. app/read against chatgpt.com/backend-api/ps/apps/batch returned HTTP 403 with a Cloudflare managed-challenge page after a 15 s wait. codex doctor also reports the ChatGPT base URL as reachable with HTTP 403.

Magnum91-jen · 22 days ago

Update 3: Signed in with a different ChatGPT account on the same machine — the app still crashes identically. This rules out anything account-specific; the defect is in the build.

Separately, and possibly more serious: after switching accounts, the sidebar still displayed the projects and thread titles from the previous account (the header showed the new account's "Get Plus" upsell, so the session had switched). Either stale cached data survives an account switch, or the switch leaves the app in a mixed state. Screenshot available on request.

Magnum91-jen · 22 days ago

Update 5 — instrumented reproduction, memory growth confirmed

Recorded eight launches across two sessions with a process monitor running alongside. Every launch follows the same curve:

Starts at ~700–1100 MB across ~9–10 processes
Brief plateau, then steep climb
Terminates consistently at 4.7–5.4 GB total working set
Time to crash varies 25–79 s, shortening across consecutive launches within a session

Throughout, a ChatGPT helper process spawns at ~7–21 MB and exits after ~1 s, repeatedly, every 2–3 seconds — an apparent restart loop that runs until termination.

Two crash shapes observed: the memory-growth one above, and a second where a lone codex process starts and dies after 0.8 s with no ChatGPT processes at all (13:10:56 and 13:29:27).

Notably, the Crashpad dumps from the later runs are 0 bytes while earlier ones were 39 MB — Crashpad appears unable to write the dump under the memory pressure that kills the process.

Full timestamped monitor output and a screen recording are available.

Magnum91-jen · 20 days ago

Still reproducing on a newer build (26.803.41515) + process-level memory data

A few data points to help isolate the deterministic code path.

Persists across app versions. First seen on 26.730.8199.0 (Store); the same
crash still occurs on 26.803.41515 (Store), Windows 11 26200 x64. The bug
survived at least one app update.

Memory curve (external process monitor, 8 consecutive launches):

  • Starts at ~700–1100 MB across 9–10 processes.
  • Brief plateau, then a steep climb to a consistent **4.7–5.4 GB total working

set**, then termination.

  • Time-to-crash 25–79 s, and it shortens with each consecutive launch in a

session.

  • During the climb a ChatGPT helper process spawns (~7–21 MB) and exits after

~1 s, restarting every 2–3 s — an apparent restart loop that runs until the
app dies.

This is consistent with a memory leak hitting the commit limit, which fits
the 0xc0000409 fast-fail and the constant fault offset reported earlier.

Crashpad can't capture the worst crashes. Early dumps are ~39–41 MB; later
dumps in the same session are 0 bytes — Crashpad can't write under the
memory pressure that kills the process. Dump availability degrades exactly when
the leak is worst.

Two distinct crash shapes:

  1. The slow climb above (utility/browser process, fast-fail at the commit limit).
  2. A lone codex process that starts with no ChatGPT helpers and dies after

~0.8 s. Local WER also shows separate small codex.exe dumps (~3.5 MB).

Independent of user data. Reproduces with an empty CODEX_HOME after fresh
sign-in — not session/workspace corruption. (An oversized rollout log — 26.7 GB
here — exists but is a separate issue; moving it aside does not stop the crash.)

Secondary startup noise (relevance unclear):

  • git config --get remote.origin.url retry loop against a workspace .git

with no origin remote (repeats dozens of times).

  • Post-login Statsig bootstrap times out; ~20 s from launch to "app routes

mounted".

The CLI stays stable throughout. Happy to share the process-monitor log with
millisecond start/exit timestamps if useful.

Magnum91-jen · 19 days ago

Update (2026-08-08): the crash stopped on its own — with no client update

Codex Desktop is stable again here, and notably without any app update:

  • Runs normally, stable for 25+ min across ~10 processes at ~1.25 GB total

working set — the normal baseline, with no climb toward the 4.7–5.4 GB
commit-limit blow-up that previously killed it in 25–79 s.

  • No new Crashpad dumps today (2026-08-08).
  • The earlier startup failure signatures are gone from the logs: no post-login

Statsig bootstrap timeout, and none of the 403 responses that accompanied
the ChatGPT helper restart loop.

  • No client update: still version 26.803.5235.0 (unchanged). Repair / Reset /

package re-registration had already been ruled out.

Interpretation: with the binary unchanged, the fix can't be in the app. Sudden
onset ~2026-08-05 with no local change + sudden resolution ~2026-08-08 with no update
points strongly to a server-side trigger — most likely a remote feature-flag /
config change (the client uses Statsig, and a post-login Statsig timeout was
present in every crash). That fits the deterministic constant fault offset: the same
bad code path was hit whenever a server-pushed condition was present.

Caveat / ask:

  • This implies a regression risk — if the same flag/config is rolled out again,

the crash likely returns. Probably worth keeping this open until root cause is
confirmed.

  • Anyone else affected: did your crashes also **stop around 2026-08-07/08 without

updating the app**? Please post your app version + dates — it would help confirm
the server-side correlation.

CLI remained stable throughout.

Magnum91-jen · 16 days ago

Codex Desktop (Windows): deterministic main-process memory runaway during authenticated startup → V8 fatal crash ~35 s after launch

Package: OpenAI.Codex 26.803.10989.0 (MSIX / Microsoft Store) · Engine: Chromium 151.0.7922.76 · OS: Windows 11 10.0.26200.8875 x64 · Plan: ChatGPT Pro
Related: #27574 · #30543 · #16169 · community thread

---

🇬🇧 English

TL;DR

The desktop app builds its full UI, then the Electron main process leaks memory at ~150 MB/s during the authenticated startup sequence and self-aborts when V8 hits its heap limit (FatalProcessOutOfMemory → int3). Crash is 100 % reproducible ~32–41 s after launch, only when signed in (signed-out is stable, CLI works). Proven independent of plugins, cache, profile, transcripts, heap flags, account, CODEX_HOME, and network/IPv6. This is an app-side bug, not an environment problem.

Crash signature (WinDbg !analyze -v)

ExceptionCode : 0x80000003 (STATUS_BREAKPOINT / int3)   [v26.803]
Faulting IP   : chrome.dll + 0x39e985d
Bucket        : BREAKPOINT_80000003_chrome.dll!Unknown
Failure hash  : {be0d4058-7058-b7fb-5291-62cb1f25d882}
Process       : ChatGPT.exe (main), uptime 48 s
Engine        : chrome.dll 151.0.7922.76 (product "Codex", OpenAI)

Earlier build 26.730.8199.0 crashed as 0xc0000409 (fast-fail) at a constant offset 0x...d71d4a1 — same disease, different failure point (see below).

Call stack (nearest-export symbols; pattern is unambiguous)

ChatGPT.exe → ChromeMain
  → uv_run                                   (libuv event loop — Node in the MAIN process)
  → node::CallbackScope / node::Buffer::New
  → v8::ScriptCompiler::ScriptStreamingTask::Run     (V8 compiling script)
  → v8::internal::compiler::CompilationDependencies… (TurboFan JIT)
  → int3  →  CrashForExceptionInNonABICompliantCodeRange  →  Crashpad

Memory curve (per-process sampling, deterministic across every run)

| t (s) | main proc (ChatGPT) | total commit | procs |
|------:|--------------------:|-------------:|------:|
| 10 | 2 459 MB | 0.6–2.6 GB | 8–11 |
| 20 | ~2 800 MB | 3.3–4.4 GB | 10–12 |
| 30 | 2 929 MB (rising) | 4.6–5.7 GB | 10–12 |
| 32–41 | — | crash @ 5.6–5.9 GB peak | — |

Only the main process balloons; renderer/GPU/utility/backend stay small. The old 26.730 build let it run to ~100–107 GB virtual and tripped Windows Resource-Exhaustion-Detector Event 2004 (codex.exe … 115 095 109 632 B), taking down unrelated apps as collateral. 26.803 has a V8 heap cap that self-aborts earlier (~5.6 GB) → the int3 above.

What was ruled out (each row = app relaunched, curve measured; all identical)

| # | Variable changed | Result |
|--:|------------------|--------|
| 1 | All plugins enabled=false (config) | crash ~39 s |
| 2 | Plugin files physically removed (primary + bundled runtime) | crash ~35 s (spinner stops instantly — plugins provably off) |
| 3 | Ambient suggestions off | crash |
| 4 | Chromium caches cleared (auth kept) | crash ~32 s |
| 5 | External-agent transcripts (286 MB) removed | crash ~41 s |
| 6 | Factory-fresh Chromium profile | crash ~34 s |
| 7 | NODE_OPTIONS=--max-old-space-size=16384 | crash ~36 s (ignored; Electron fuse) |
| 8 | OS prefer-IPv4 (prefixpolicy) | crash ~32 s |
| 9 | IPv6 fully disabled (chatgpt.com → 85 ms) | crash ~34 s |
| — | empty CODEX_HOME / 2nd account / package Reset·Repair·Register | crash |

Notable secondary observation

Just before the OOM, backend RPCs are pathologically slow: plugin/list = 14 030 ms, model/list = 11 548 ms (normally milliseconds). Good place to look for the leak.

Network side-finding (real, but NOT the crash cause)

On this line, IPv6 to Cloudflare is dead (tracert -6 dies at hop 2, past the ISP router). Because chatgpt.com has AAAA records and the host had a global IPv6, apps tried IPv6 first → ~21 s timeout × 2 addresses ≈ 43 s connect; api.openai.com (no/working IPv6) stayed fast — which is why the CLI works and the desktop net stack was sluggish. Forcing IPv4 cut chatgpt.com from 43 s → 85 ms but did not fix the crash (row 9). So: separate issue, worth fixing at the router, but not the root cause.

Ask

The runaway is in main-process JS during the signed-in startup path and reproduces on a pristine install. Please investigate with an internal heap-profiling build; the plugin/list/model/list stalls right before the OOM are a likely lead. Happy to provide the 41 MB Crashpad dump and full !analyze -v output.

---

🇩🇪 Deutsch

Kurzfassung

Die Desktop-App baut die Oberfläche vollständig auf, dann läuft der Speicher des Electron-Hauptprozesses während der angemeldeten Startsequenz mit ~150 MB/s weg und die App bricht selbst ab, sobald V8 sein Heap-Limit erreicht (FatalProcessOutOfMemory → int3). Absturz zu 100 % reproduzierbar ~32–41 s nach Start, nur angemeldet (abgemeldet stabil, CLI läuft). Nachweislich unabhängig von Plugins, Cache, Profil, Transkripten, Heap-Flags, Konto, CODEX_HOME und Netzwerk/IPv6. Ein App-Bug, kein Umgebungsproblem.

Absturzsignatur (WinDbg !analyze -v)

Ausnahmecode : 0x80000003 (STATUS_BREAKPOINT / int3)   [v26.803]
Fehler-IP    : chrome.dll + 0x39e985d
Bucket       : BREAKPOINT_80000003_chrome.dll!Unknown
Failure-Hash : {be0d4058-7058-b7fb-5291-62cb1f25d882}
Prozess      : ChatGPT.exe (main), Laufzeit 48 s
Engine       : chrome.dll 151.0.7922.76 (Produkt „Codex", OpenAI)

Ältere Version 26.730.8199.0 stürzte als 0xc0000409 (Fast-Fail) an konstantem Offset 0x...d71d4a1 ab — gleiche Ursache, anderer Sterbepunkt (siehe unten).

Call-Stack (Symbole = nächster Export; Muster eindeutig)

ChatGPT.exe → ChromeMain
  → uv_run                                   (libuv-Eventloop — Node im HAUPTprozess)
  → node::CallbackScope / node::Buffer::New
  → v8::ScriptCompiler::ScriptStreamingTask::Run     (V8 kompiliert Script)
  → v8::internal::compiler::CompilationDependencies… (TurboFan-JIT)
  → int3  →  CrashForExceptionInNonABICompliantCodeRange  →  Crashpad

Speicherkurve (Pro-Prozess-Messung, über alle Läufe deterministisch)

| t (s) | Hauptprozess (ChatGPT) | Commit gesamt | Prozesse |
|------:|-----------------------:|--------------:|---------:|
| 10 | 2 459 MB | 0,6–2,6 GB | 8–11 |
| 20 | ~2 800 MB | 3,3–4,4 GB | 10–12 |
| 30 | 2 929 MB (steigend) | 4,6–5,7 GB | 10–12 |
| 32–41 | — | Absturz bei Peak 5,6–5,9 GB | — |

Nur der Hauptprozess bläht auf; Renderer/GPU/Utility/Backend bleiben klein. Die alte 26.730 lief bis ~100–107 GB virtuell und löste Windows Resource-Exhaustion-Detector Event 2004 aus (codex.exe … 115 095 109 632 B) — riss dabei fremde Programme als Kollateralschaden mit. 26.803 hat ein V8-Heap-Limit, das früher (~5,6 GB) selbst abbricht → obiges int3.

Ausgeschlossen (jede Zeile = App neu gestartet, Kurve gemessen; alle identisch)

| # | Geänderte Variable | Ergebnis |
|--:|--------------------|----------|
| 1 | Alle Plugins enabled=false (Config) | Absturz ~39 s |
| 2 | Plugin-Dateien physisch entfernt (primary + bundled Runtime) | Absturz ~35 s (Spinner sofort weg — Plugins nachweislich aus) |
| 3 | Ambient-Suggestions aus | Absturz |
| 4 | Chromium-Caches geleert (Auth erhalten) | Absturz ~32 s |
| 5 | Externe Agent-Transkripte (286 MB) entfernt | Absturz ~41 s |
| 6 | Fabrikfrisches Chromium-Profil | Absturz ~34 s |
| 7 | NODE_OPTIONS=--max-old-space-size=16384 | Absturz ~36 s (ignoriert; Electron-Fuse) |
| 8 | OS bevorzugt IPv4 (prefixpolicy) | Absturz ~32 s |
| 9 | IPv6 hart aus (chatgpt.com → 85 ms) | Absturz ~34 s |
| — | leeres CODEX_HOME / Zweitkonto / Paket Reset·Repair·Register | Absturz |

Auffälliger Nebenbefund

Kurz vor dem OOM sind Backend-RPCs abnormal langsam: plugin/list = 14 030 ms, model/list = 11 548 ms (normal: Millisekunden). Guter Ansatzpunkt für die Leck-Suche.

Netzwerk-Nebenbefund (echt, aber NICHT die Absturzursache)

Auf dieser Leitung ist IPv6 zu Cloudflare tot (tracert -6 stirbt an Hop 2 hinter dem Router). Da chatgpt.com AAAA-Records hat und der Host eine globale IPv6 besaß, probierten Apps zuerst IPv6 → ~21 s Timeout × 2 Adressen ≈ 43 s Verbindungsaufbau; api.openai.com (kein/funktionierendes IPv6) blieb schnell — deshalb läuft die CLI und der Desktop-Netzstack war zäh. IPv4-Erzwingen senkte chatgpt.com 43 s → 85 ms, behob den Absturz aber nicht (Zeile 9). Also separates Problem, am Router lösbar, nicht die Wurzel.

Bitte an OpenAI

Der Weglauf sitzt im Hauptprozess-JS des angemeldeten Startpfads und reproduziert auf einer frischen Installation. Bitte mit einem internen Heap-Profiling-Build untersuchen; die plugin/list/model/list-Hänger direkt vor dem OOM sind eine heiße Spur. Der 41-MB-Crashpad-Dump und die vollständige !analyze -v-Ausgabe stehen bereit.

phisanjits-tech · 13 days ago

Reproduces on 26.810.6296.0 — and while signed out, which narrows the trigger

Windows 11 10.0.26200 x64 · Package OpenAI.Codex 26.810.6296.0 (MSIX / Microsoft Store) · 31 GB RAM · AMD Radeon iGPU + RTX 4060 Laptop

Still present on the newest Store build. One data point here contradicts the "crashes only after signing in" narrowing above.

The crash does not require signing in

This machine has never been signed in on this install — every backend call in the startup log returns 401 (desktop_fetch_auth_401 hadToken=false, sa_server_request_failed {"detail":"Unauthorized"}), and the app still terminates 8–9 s after launch, on every one of 12+ launches. Whatever runs away is not gated behind the authenticated startup sequence.

Crash signature — Chromium OOM abort in the browser process

Parsed straight from the Crashpad dump (38.9 MB, sidecar {"capture_kind":"crash","ptype":"browser"}):

Exception code : 0xE0000008        (Chromium OOM abort, raised via KERNELBASE!RaiseException)
Address        : 0x00007FFD4920187A  (KERNELBASE.dll +0xC187A)
Parameters     : 0x80200004, 0x893EDD000, 0x40D882000

0x893EDD000 = 34.31 GB = this machine's commit limit. 0x40D882000 = 16.21 GB = commit in use at that moment. Chromium is reporting system commit state on a failed allocation — the machine was not out of memory, ~18 GB of commit headroom was free.

Memory at death is only ~1.8 GB here, not a 4.7–5.4 GB runaway

Sampled every 500 ms across a full launch:

| t (s) | procs | total private | main proc | system commit |
|------:|------:|--------------:|----------:|--------------:|
| 0.5 | 3 | 0.11 GB | 0.10 GB | 16.38 GB |
| 2.0 | 8 | 1.15 GB | 1.04 GB | 17.51 GB |
| 4.5 | 10 | 1.66 GB | 1.23 GB | 18.30 GB |
| 6.0 | 10 | 1.79 GB | 1.35 GB | 18.25 GB |
| 6.5 | — | terminated | | |

The abort fires long before any heap ceiling is reached, which looks more like a single oversized allocation failing than a gradual leak hitting a limit. Possibly the same defect at a different point on the curve.

The last log lines are byte-for-byte identical before every crash
browser_use_availability_resolved available=true browserPane=true platform=Windows release=26.810.50856
[computer-use-native-pipe] computer-use notify config ensure finished platform=win32 status=installed
[computer-use-native-pipe] computer-use native pipe startup ready pipePath=\\.\pipe\codex-computer-use-<uuid>

Termination follows ~2 s later with nothing further logged.

Flag matrix (each launch timed to termination)

| Flags | Result |
|---|---|
| (none) | dies 8–9 s |
| --disable-gpu | dies 9 s |
| --disable-software-rasterizer | dies 9 s |
| --disable-gpu-compositing | dies 9 s |
| --disable-direct-composition | dies 9 s |
| --in-process-gpu | dies 9 s |
| --use-angle=d3d11 / --use-angle=gl | dies 9 s |
| --disable-features=CalculateNativeWinOcclusion | dies 9 s |
| --disable-gpu --disable-software-rasterizer | survives — but no window is ever painted |

Only disabling both rasterization paths avoids the abort, and the app is then headless and unusable. Per-app GPU preference (UserGpuPreferences = 1 iGPU / 2 dGPU) makes no difference either. Confirms @nawabjan1's note that --disable-gpu alone does nothing.

Ruled out locally
  • Clean slate. Fully uninstalled, then removed %LOCALAPPDATA%\OpenAI, ~\.codex, both Packages\OpenAI.Codex* folders, the leftover codex_sandbox_offline_block_* firewall rules, and the orphaned CodexSandboxOffline / CodexSandboxOnline local accounts — reinstalled from the Store, identical crash.
  • No injected modules. Dump module list outside System32/WinSxS contains only ChatGPT.exe, chrome.dll, chrome_elf.dll, better_sqlite3.node, windows-account.node.
  • Not Code Integrity (cf. the vk_swiftshader.dll community report): HVCI / Memory Integrity is on, but Microsoft-Windows-CodeIntegrity/Operational logs zero events across the crash window, and vk_swiftshader.dll in this build is properly Authenticode-signed by CN="OpenAI OpCo, LLC".
  • Not the machine. ChatGPT Classic (OpenAI.ChatGPT-Desktop 1.2026.190.0) runs indefinitely on the same box, as do other Electron/Chromium apps (50+ min uptime, hardware acceleration on).
  • Not the GPU. No Microsoft-Windows-CodeIntegrity or display-driver TDR events accompany the crash; adapter selection is irrelevant (see matrix).

Happy to upload the dump or the full startup log if useful.

Magnum91-jen · 13 days ago

Confirming @phisanjits-tech's analysis from a second, independent machine — different
GPU, different point on the same curve:

Env: Windows 11 10.0.26200.8875 x64 · OpenAI.Codex 26.810.4967.0 (also repro'd on
26.803.10989.0) · 32 GB RAM · NVIDIA GTX 1660 SUPER (no AMD iGPU).

Same defect, later on the curve. Where their browser process aborts at ~1.8 GB / 6.5 s,
mine runs the main/browser process up to ~5.6–6.0 GB over ~32–47 s before dying — but the
last log lines before every one of ~15 crashes are the same family:
browser_use_availability_resolved … browserPane=true → computer-use native pipe startup ready
→ termination. WinDbg on my dump: int3 in chrome.dll via
v8::ScriptCompiler::ScriptStreamingTask::Run (bucket BREAKPOINT_80000003_chrome.dll!Unknown).

The browser pane cannot be disabled locally. Setting BROWSER_USE_AVAILABLE_BACKENDS=""
flips the first resolve to browserPane=false reason=browser-pane-disabled, but the app
immediately re-resolves to browserPane=true reason=available and starts the computer-use
pipe anyway. Removing the Chrome extension (the chrome backend) changes nothing — it's the
in-app pane (iab) that triggers it.

Ruled out here (each = clean relaunch, memory sampled, identical crash): all plugins off +
plugin runtime files physically removed; ambient off; Chromium caches cleared; external-agent
transcripts removed; factory-fresh Chromium profile; NODE_OPTIONS=--max-old-space-size=16384
(ignored, Electron fuse); IPv4-preferred and IPv6 fully disabled; empty CODEX_HOME; 2nd
account; Store Reset/Repair/Register; manual install of the newest build. None help.

Two machines, two GPUs, one defect in the force-enabled browser-pane / computer-use startup.
Happy to share my 41 MB Crashpad dump and full !analyze -v.

Magnum91-jen · 8 days ago

Update 2026-08-19 — recovered after MSIX/runtime update; consolidated local evidence

Transparency: This update was analyzed and written by OpenAI Codex, running inside the recovered Codex Windows desktop app, at the issue author's request. The facts below come from the local Windows event logs, AppX deployment log, Codex desktop logs, Crashpad metadata, WinDbg analysis, and process-level memory measurements. Interpretations are explicitly labeled as such.

Recovery correlates with today's update

  • The last launch of the old package, 26.814.5167.0, started at 14:01:48 CEST. A Crashpad sidecar was written at 14:02:26 with ptype: "browser".
  • The AppX deployment log shows that Windows began staging 26.814.5517.0 at 14:02:14. Registration replacing 26.814.5167.0 with 26.814.5517.0 completed successfully at 14:45:01.
  • Because that last browser-process crash overlaps package staging/removal, this individual 14:02 crash may have been caused by the update operation rather than being a clean reproduction of the original defect.
  • The first launch under 26.814.5517.0 started at 14:49:40 and is currently stable beyond the previous 6.5–47 second crash window. At the measurement point it had run for more than 15 minutes with 10 ChatGPT processes at approximately 1.67 GB total working set / 1.71 GB private memory, with no runaway curve.
  • The embedded in-app-browser release also changed from 26.814.41407 in the final old-build crash log to 26.814.41957 in the stable session.

This is a strong update correlation, but it does not identify whether the effective change was in the MSIX application, the embedded browser component, or both.

Consolidated diagnosis from the earlier failures

  1. On 26.727, Windows Resource-Exhaustion-Detector event 2004 recorded codex.exe consuming 115,095,109,632 bytes on Aug 1 and 108,312,694,784 bytes on Aug 2. Both incidents produced the same 0xc0000409 failure at the same binary offset.
  2. On 26.803/26.810, the failure shape changed: the Electron/Chromium main/browser process grew rapidly to approximately 5.6–6.0 GB and V8 aborted earlier with FatalProcessOutOfMemory / int3.
  3. WinDbg placed the failure in main-process Node/V8 execution (ChromeMain → uv_run → node::CallbackScope / Buffer::New → v8::ScriptCompiler::ScriptStreamingTask::Run → TurboFan → int3). Renderer, GPU, utility, and Codex backend processes remained comparatively small.
  4. An independent machine reported a Chromium OOM abort much earlier, at approximately 1.8 GB total private memory. This may represent a single oversized allocation or the same defective path failing at a different point.
  5. Across the independent reproductions, the last startup sequence consistently included browser_use_availability_resolved ... browserPane=true followed by computer-use native pipe startup ready before termination.
  6. The Codex CLI remained stable on the same machines and accounts. The outage was therefore in the Windows desktop shell, not the Codex service or account.

The defect was reproduced after ruling out plugins (including physically removing their runtime files), ambient suggestions, Chromium caches, a fresh Chromium profile, external-agent transcripts, CODEX_HOME, account state, IPv4/IPv6, GPU selection, package Reset/Repair/Register, and local data corruption.

Most strongly supported interpretation

The evidence supports a Windows desktop application defect in Electron/Chromium main-process startup, most closely associated with initialization of the force-enabled in-app browser/computer-use path. Depending on the build and machine, it caused either runaway allocation until system commit exhaustion, a V8 heap-limit abort, or an earlier failed oversized allocation.

This is still an inference, not a maintainer-confirmed source-level root cause. The now-stable build also initializes the browser pane and computer-use pipe successfully, so those features are not inherently broken; a specific build/runtime/configuration interaction or race is more likely. The earlier period of recovery without a client update also means a remote feature/config rollout may have influenced whether the defective path was reached.

Request to maintainers

Could you please confirm:

  • whether 26.814.5517.0 or in-app-browser release 26.814.41957 contains an intended fix for this crash;
  • which component caused the main-process allocation failure; and
  • whether a regression test now covers this startup path?

I recommend leaving the issue open until the fix or root cause is confirmed and the new build remains stable for a longer observation period. Crash dump and full WinDbg output remain available privately.

---

Update 19.08.2026 — nach MSIX-/Runtime-Update wieder funktionsfähig; konsolidierte lokale Belege

Transparenzhinweis: Dieses Update wurde auf Wunsch des Issue-Erstellers von OpenAI Codex analysiert und verfasst – direkt in der wieder funktionierenden Codex-Windows-Desktop-App. Die folgenden Fakten stammen aus den lokalen Windows-Ereignisprotokollen, dem AppX-Bereitstellungsprotokoll, den Codex-Desktop-Logs, Crashpad-Metadaten, der WinDbg-Auswertung und Prozess-Speichermessungen. Schlussfolgerungen sind als solche gekennzeichnet.

Die Wiederherstellung korreliert mit dem heutigen Update

  • Der letzte Start des alten Pakets 26.814.5167.0 erfolgte um 14:01:48 Uhr MESZ. Um 14:02:26 Uhr wurde ein Crashpad-Sidecar mit ptype: "browser" geschrieben.
  • Laut AppX-Bereitstellungsprotokoll begann Windows um 14:02:14 Uhr, 26.814.5517.0 bereitzustellen. Die Registrierung, bei der 26.814.5167.0 durch 26.814.5517.0 ersetzt wurde, war um 14:45:01 Uhr erfolgreich abgeschlossen.
  • Da sich dieser letzte Browser-Prozess-Absturz zeitlich mit Bereitstellung und Entfernung des alten Pakets überschneidet, könnte gerade der Absturz um 14:02 Uhr durch den Updatevorgang verursacht worden sein und keine saubere Reproduktion des ursprünglichen Fehlers darstellen.
  • Der erste Start unter 26.814.5517.0 erfolgte um 14:49:40 Uhr und blieb deutlich länger stabil als das frühere Absturzfenster von 6,5–47 Sekunden. Zum Messzeitpunkt lief die App seit mehr als 15 Minuten mit 10 ChatGPT-Prozessen und ungefähr 1,67 GB Working Set / 1,71 GB Private Memory, ohne ansteigende Weglaufkurve.
  • Die eingebettete In-App-Browser-Version wechselte ebenfalls: vom Release 26.814.41407 im letzten Crash-Log des alten Builds auf 26.814.41957 in der stabilen Sitzung.

Die Wiederherstellung korreliert damit stark mit dem Update. Daraus lässt sich jedoch nicht ableiten, ob die wirksame Änderung in der MSIX-App, der eingebetteten Browser-Komponente oder in beiden lag.

Konsolidierte Diagnose der früheren Abstürze

  1. Unter 26.727 protokollierte der Windows Resource-Exhaustion-Detector (Ereignis 2004), dass codex.exe am 1. August 115.095.109.632 Bytes und am 2. August 108.312.694.784 Bytes belegte. Beide Vorfälle endeten mit demselben 0xc0000409 am identischen Binary-Offset.
  2. Unter 26.803/26.810 änderte sich die Absturzform: Der Electron-/Chromium-Haupt- beziehungsweise Browser-Prozess wuchs schnell auf ungefähr 5,6–6,0 GB und V8 brach früher mit FatalProcessOutOfMemory / int3 ab.
  3. WinDbg verortete den Fehler im Node-/V8-Teil des Hauptprozesses (ChromeMain → uv_run → node::CallbackScope / Buffer::New → v8::ScriptCompiler::ScriptStreamingTask::Run → TurboFan → int3). Renderer, GPU, Utility und Codex-Backend blieben dagegen vergleichsweise klein.
  4. Auf einem unabhängigen Rechner trat der Chromium-OOM-Abbruch bereits bei ungefähr 1,8 GB gesamtem Private Memory auf. Das kann auf eine einzelne übergroße Allokation oder denselben fehlerhaften Pfad mit einem anderen Abbruchpunkt hindeuten.
  5. Bei den unabhängigen Reproduktionen enthielt die letzte Startsequenz regelmäßig browser_use_availability_resolved ... browserPane=true, gefolgt von computer-use native pipe startup ready, bevor der Prozess endete.
  6. Die Codex-CLI blieb auf denselben Rechnern und Konten stabil. Betroffen war somit die Windows-Desktop-Hülle, nicht der Codex-Dienst oder das Konto.

Der Fehler ließ sich weiterhin reproduzieren, nachdem Plugins – einschließlich physisch entfernter Runtime-Dateien –, Ambient Suggestions, Chromium-Caches, ein frisches Chromium-Profil, externe Agent-Transkripte, CODEX_HOME, Kontozustand, IPv4/IPv6, GPU-Auswahl, Paket-Reset/-Reparatur/-Registrierung und lokale Datenkorruption ausgeschlossen worden waren.

Am stärksten gestützte Einordnung

Die Belege sprechen für einen Fehler der Windows-Desktop-App beim Start des Electron-/Chromium-Hauptprozesses, am engsten verbunden mit der Initialisierung des erzwungen aktivierten In-App-Browser-/Computer-Use-Pfads. Je nach Build und Rechner führte er zu einem Speicher-Weglauf bis zur System-Commit-Erschöpfung, einem V8-Heap-Limit-Abbruch oder einer früher scheiternden übergroßen Allokation.

Das ist weiterhin eine Schlussfolgerung und keine von einem Maintainer bestätigte Quellcode-Ursache. Der nun stabile Build initialisiert Browser Pane und Computer-Use-Pipe ebenfalls erfolgreich; die Funktionen an sich sind daher nicht grundsätzlich defekt. Wahrscheinlicher ist eine bestimmte Kombination oder Race Condition aus Build, Runtime und Konfiguration. Da es zwischenzeitlich auch ohne Client-Update eine stabile Phase gab, könnte zusätzlich ein serverseitiges Feature-/Konfigurations-Rollout beeinflusst haben, ob der fehlerhafte Pfad erreicht wurde.

Bitte an die Maintainer

Könnt ihr bitte bestätigen:

  • ob 26.814.5517.0 oder das In-App-Browser-Release 26.814.41957 eine beabsichtigte Behebung dieses Absturzes enthält;
  • welche Komponente die fehlerhafte Allokation im Hauptprozess ausgelöst hat; und
  • ob der Startpfad inzwischen durch einen Regressionstest abgedeckt wird?

Ich empfehle, das Issue geöffnet zu lassen, bis Fix oder Ursache bestätigt sind und der neue Build über einen längeren Beobachtungszeitraum stabil bleibt. Crash-Dump und vollständige WinDbg-Ausgabe können weiterhin vertraulich bereitgestellt werden.

phisanjits-tech · 5 days ago

26.818.5229.0 — newer than the recovered build — still crashes identically (signed out). The recovery was likely the rollout, not the client.

Same machine as my earlier comment (Windows 11 10.0.26200 x64, never signed in). This bears directly on @Magnum91-jen's open question to maintainers — whether 26.814.5517.0 contains an intended fix.

Both components here are newer than the recovered combo, and the crash is unchanged
  • Client 26.818.5229.0 (Store, installed 2026-08-22) vs. their recovered 26.814.5517.0
  • Embedded in-app browser 26.818.41509 vs. their stable 26.814.41957
  • 3/3 launches died: 9.2 s / 8.2 s / 8.2 s after the window appeared
  • Identical signature: 0xE0000008 at the same KERNELBASE offset (+0xC187A), first exception parameter unchanged (0x80200004), commit-limit parameter unchanged (0x893EDD000 = this machine's 34.31 GB); only the commit-in-use parameter differs with system state
  • Identical trailing log lines: browser_use_availability_resolved … browserPane=true → computer-use native pipe startup ready → termination ~2 s later
Interpretation

If the effective change were in the 26.814.x client or embedded browser, a strictly newer combination should not reproduce the crash byte-for-byte. It does. That points to the recovery being the remote feature/config rollout you hypothesized — presumably account-scoped, which a signed-out install can never receive. The defective startup path appears to still be present in the newest client, merely gated off for some accounts.

Worth noting the gate behaves inversely on our two machines: yours was stable signed-out and crashed signed-in; this one crashes signed-out. Consistent with a config-dependent path rather than a straight-line code defect.

Earlier findings from this machine, for completeness
  • On 26.810.7004.0 (auto-updated from .6296): still crashing on 2026-08-22, died 21.6 s; observed time-to-crash spread here is now 8–22 s across ~18 launches with unchanged configuration — a single surviving launch proves nothing.
  • BROWSER_USE_AVAILABLE_BACKENDS="" on 26.810.6296.0: no observable effect at all — not even the transient browserPane=false reason=browser-pane-disabled you saw before the re-resolve. Verified the empty-but-present variable reached the child (Win32 SetEnvironmentVariableW + a cmd /c set probe through the identical launch path; note PowerShell's $env:X='' and .NET's SetEnvironmentVariable(x,'') both delete the variable). Output byte-identical to control on both direct-exe and Store-activation paths — no reachable local opt-out.

Fresh Crashpad dump from 26.818.5229.0 available on request.