Codex desktop app-server crashes repeatedly with 0xC0000005

What version of the Codex App are you using (From “About Codex” dialog)?

26.903.61454

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex desktop app-server crashes repeatedly with 0xC0000005

Summary

The codex.exe app-server child process crashes with an access violation
(0xC0000005 / exit code 3221225477) shortly after every spawn, and is
restarted by the supervisor in a loop. The UI shows this as a flash /
reload, or as a permanently black window when the crash happens before
the renderer finishes loading.

The crash reproduces on a completely fresh profile.

Not a duplicate of the suggested issues

• #42029 (closed): exit code 3221225501 = 0xC000001D
  (illegal instruction), crashes immediately on every launch,
  app 26.825.6671.0. This report: 3221225477 = 0xC0000005
  (access violation), crashes at a consistent ~62 s after each spawn,
  app 26.903.8094.0, and the app is functional between crashes.
• #40119: a Windows kernel crash on an Insider build. This is a
  user-mode access violation in a child process; the OS is unaffected.
• #35560: ChatGPT.exe exits silently with no crash event and the
  AppX container is destroyed. Here the host survives and respawns the
  child, and every crash produces a WER report with a constant faulting
  offset.

Closest open issue is #40062 (desktop crashes repeatedly while the
CLI stays stable), which this report may share a root cause with but
documents in far more detail.

Note that #42029 was also on Windows build 26200 (25H2), as is this
report — the OS version may be a common factor even though the
exception and timing differ.

Environment

App	ChatGPT desktop for Windows (MSIX OpenAI.Codex_2p2nqsd0c76g0)
Package version	26.903.8094.0
App version string	26.903.61454
Binary	%LOCALAPPDATA%\OpenAI\Codex\bin\87ac0b36cd15de28\codex.exe
Binary build timestamp	0x6a9b503b = 1788563515 → 2026-09-04 23:11:55 UTC
OS	Windows (Spanish locale)
WebView2 runtime	152.0.4191.66
GPU	NVIDIA RTX 4060 Ti (AMD Ryzen iGPU disabled in BIOS — see below)
Network	WireGuard tunnels configured (split tunnel — allowed IPs are RFC1918 only, so chatgpt.com never traversed them); all deactivated for Run D with no change

Crash signature — identical every time

Faulting application: codex.exe, version 0.0.0.0, timestamp 0x6a9b503b
Faulting module:      codex.exe, version 0.0.0.0, timestamp 0x6a9b503b
Exception code:       0xc0000005
Fault offset:         0x000000000c3aaac8
WER hash bucket:      252d2d142ae028df6bcc7a93ddbdca00

Same offset and same WER bucket across every crash observed over ~90
minutes and several different profiles — a single code path.

Timing

While the app is idle, the crash occurs at a strikingly fixed interval
after each spawn:

SPAWN 19:01:31.535 → CRASH 19:02:33.847   62.31 s
SPAWN 19:02:33.861 → CRASH 19:03:36.015   62.15 s
SPAWN 19:03:36.031 → CRASH 19:04:38.672   62.64 s
SPAWN 19:04:38.688 → CRASH 19:05:41.234   62.55 s
SPAWN 19:05:41.250 → CRASH 19:06:43.841   62.59 s

Under load the interval becomes variable (29.6 s – 62.0 s).

In the idle case the process logs nothing at all for the last 30–48
seconds before dying. The Most recent error field carried in
fatal_error_broadcasted is stale and differs between crashes (a
PowerShell shell-snapshot warning, a 403 on a websocket, an MCP
Method not found, a plugin manifest warning) — it is the last buffered
message, not the cause.

What steps can reproduce the bug?

1. Launch the ChatGPT desktop app on Windows (26.903.8094.0).
2. Sign in and leave the app completely idle — no conversation, no input.
3. Watch %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\.

The codex.exe app-server child dies ~62 s after each spawn and the
supervisor restarts it, indefinitely:

SPAWN 19:01:31.535 → CRASH 19:02:33.847 62.31 s
SPAWN 19:02:33.861 → CRASH 19:03:36.015 62.15 s
SPAWN 19:03:36.031 → CRASH 19:04:38.672 62.64 s
SPAWN 19:04:38.688 → CRASH 19:05:41.234 62.55 s
SPAWN 19:05:41.250 → CRASH 19:06:43.841 62.59 s

Counting crashes in the current session log:

$log = Get-ChildItem "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs" `
       -Recurse -Filter "*t0*.log" | Sort-Object LastWriteTime -Descending | Select-Object -First 1
(Select-String -Path $log.FullName -Pattern 'process exited').Count

Contrast — the same binary launched manually and left idle does NOT crash
(survived 4+ minutes):

& "$env:LOCALAPPDATA\OpenAI\Codex\bin\87ac0b36cd15de28\codex.exe" app-server

No session id available: the crash happens before any conversation is used.

What is the expected behavior?

The app-server should not terminate with an access violation, and should
not enter an unbounded restart loop.

More broadly: none of the three underlying problems found while
diagnosing this (an invalid config.toml the app wrote itself, a gap in
the persisted thread-store sequence, a stale account binding) should
surface as 0xC0000005. Each is recoverable and should produce a
readable error. As shipped, the only observable symptom is a hard crash
with no diagnostic, which makes the app effectively undiagnosable from
the user side.

Additional information

Four independent reproductions

Run A — existing profile, everything disabled.
All plugins set to enabled = false, no MCP servers started
(mcp_server_startup_status_updated: zero occurrences in the whole
session), no conversation open, config.toml validated with a TOML
parser. Crashed on a fixed ~62.4 s cadence (five consecutive cycles,
spread 0.5 s).

Run B — freshly created profile, stock configuration.
~/.codex renamed aside; the app recreated it from scratch
(.desktop-created, 4 KB SQLite files, no thread history, no archived
sessions). Default plugins and MCP servers therefore active again
(codex_app, codex_apps, cua_repl, node_repl,
openai_artifact_template_picker, each restarted 13 times). Still
crashes with the same signature.

Run C — after a full reboot, single GPU.
Clean reboot of the machine, then the AMD Ryzen iGPU disabled in BIOS so
only the NVIDIA RTX 4060 Ti drives display. Crash unchanged:

SPAWN 20:15:52.452 → CRASH 20:16:54.733   62.28 s   code=3221225477

Ruling out display-compositing / multi-adapter causes, and any stale
process or file lock left by earlier troubleshooting.

Run D — no VPN tunnel.
All WireGuard tunnels deactivated (they were split-tunnel — allowed IPs
10.10.10.0/24, 10.88.88.0/24, 10.55.55.0/24 — so chatgpt.com never
traversed them). Crash unchanged:

SPAWN 20:21:12.914 → CRASH 20:22:15.171   62.26 s
SPAWN 20:22:15.184 → CRASH 20:23:17.696   62.51 s

Notably this session logged zero 403/409 websocket errors: with a
clean account and no tunnel those are gone entirely, while the crash
continues unchanged. The websocket failures reported above were therefore
incidental, not causal.

Also tried, without effect: signing out and signing back in; deleting the
corrupt thread store; cleaning the config; disabling every plugin;
checking for an app update (26.903.8094.0 is newer than any build
referenced in the related issues below).

Graphics and chipset drivers ruled out

• WER names codex.exe as both the faulting application and the
  faulting module; the fault address lies inside its own image, not in
  a driver DLL.
• codex.exe is the headless app-server (JSON-RPC over stdio). It renders
  nothing; a graphics fault would surface in ChatGPT.exe or
  msedgewebview2.exe.
• The Windows System event log contains no Display, nvlddmkm,
  WHEA-Logger or TDR (4101) events at any of the crash timestamps
  (20:15:52, 20:21:12, 20:22:15, 20:23:17 UTC).
• GPU driver: NVIDIA 32.0.15.9186 (2026-01-20). AMD chipset components
  (GPIO/I2C/PCI/SMBus) dated 2025-09 to 2026-07; nothing recent
  correlating with onset.

Key discriminator

Launching the same binary manually and leaving it idle does not crash:

& "$env:LOCALAPPDATA\OpenAI\Codex\bin\87ac0b36cd15de28\codex.exe" app-server

Survived 4+ minutes with no crash. The process only dies on the path the
desktop app drives, i.e. after initialize and authentication. Note that
every fatal_error_broadcasted reports initialized=false.

Other defects found while diagnosing

These are separate from the crash above but were each independently able
to break the app, and each surfaced only as the same opaque
access violation:

1 — The app writes an invalid config.toml and then dies on it.
~/.codex/config.toml was written with a duplicate top-level key:

notify = []
notify = [ "…\@oai\sky\bin\windows\codex-computer-use.exe", "turn-ended" ]

TOML forbids duplicate keys, so the whole file became unparseable:
failed to read configuration layers: config.toml:6:1: duplicate key.
The backend then crashed with 0xC0000005 in a ~62 s loop rather than
reporting a configuration error. Two older config.toml.corrupt-* files
in the same directory show this has happened before.

2 — Corrupt thread-store projection crashes the process.

failed to project durable rollout for <thread-id>:
thread-store internal error: thread history projection for <thread-id>
expected ordinal 106, got 105

A gap in the persisted sequence causes an access violation instead of a
recoverable error. Because the affected thread was bound as the active
conversation, the app reloaded it on every restart — an unbreakable loop
from the user's side.

3 — Account switching on one OS user leaves inconsistent local state.
Two different ChatGPT accounts were used under the same Windows user.
Symptoms: Thread catalog sync failed: "App server account changed",
HTTP 409 on wss://chatgpt.com/backend-api/wham/remote/control/server,
HTTP 403 on wss://chatgpt.com/backend-api/codex/responses, and
chatgpt-account-lookup completing with accountInfoHttpStatus=undefined.
Local thread history and state remain mixed between accounts.

4 — Disabled plugin leaves live wiring in config.
With [plugins."computer-use@openai-bundled"] enabled = false, the
config still contained a notify hook pointing at
codex-computer-use.exe, plus SKY_CUA_NATIVE_PIPE = "1" and a
SKY_CUA_NATIVE_PIPE_DIRECTORY named pipe. The pipe GUID was
regenerated on every restart despite the plugin being disabled.

Main request

A crash in the app-server should not surface as an access violation with
no diagnostic. In every case above the underlying problem was mundane and
recoverable — a malformed config file, a gap in a sequence, a stale
account binding — but the only observable symptom was a hard crash,
making it effectively undiagnosable from the user side.

Artifacts available on request

• Desktop logs: %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\
• WER reports: C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_codex.exe_*

Related public reports

This appears to belong to a family of Windows desktop crashes that has
been open for several weeks:

• openai/codex#40062 — "Codex Desktop 26.818.5229.0 repeatedly crashes
  on Windows while Codex CLI remains stable". Open since 2026-08-22,
  unassigned, spanning builds 26.818.3698.0 / 26.818.4152.0 /
  26.818.5229.0. Same discriminator as this report: the CLI is stable on
  the same machine, account, network and projects while the desktop app
  crashes repeatedly.
• openai/codex#43347 — closing the last in-app Browser Use tab crashes
  the desktop app (26.901.5280.0 / 26.901.6511.0). Open.
• openai/codex#41482 — desktop starts background processes but no GUI
  window appears.
• Community reports of the app hanging indefinitely on the OpenAI logo
  splash screen — the same visible symptom described here when the
  app-server dies before the renderer finishes loading.

This report is filed against 26.903.8094.0, newer than any build
referenced in the above, and the failure persists.

What this report adds over #40062

• Exact exception code, fault offset and WER hash bucket, identical
  across every crash observed (single code path).
• Crash cadence measured to the millisecond: ~62.3 s after each spawn
  while idle; 29.6–62.0 s under load.
• A clean discriminator: the same binary launched manually
  (codex.exe app-server) and left idle survives 4+ minutes, so the
  fault is on the authenticated / post-initialize path driven by the
  desktop app, not in the binary at rest.
• Four independent reproductions that jointly exclude the plugin/MCP
  layer, the accumulated local state, the display/GPU configuration and
  the VPN: every plugin disabled with zero MCP servers started; a profile
  the app recreated from scratch; a full reboot with the integrated GPU
  disabled in BIOS; and all VPN tunnels down. The 403/409 websocket
  errors disappear in the last run while the crash does not.

Start with the codex.exe app-server path after initialize and authentication, using the desktop logs and Windows Error Reporting artifacts described in the issue. Reproduce the restart loop from the desktop app rather than launching app-server manually, then trace the malformed config, thread-store projection, and account-state errors. Done means these recoverable failures produce readable diagnostics instead of an access violation and unbounded restart loop.