Skip to content

Windows: Codex Chrome native host can consume unbounded memory and trigger system-wide memory exhaustion / TDR BSOD #22591

@SimpleZion

Description

@SimpleZion

What version of the Codex App are you using?

Codex Desktop on Windows:

  • Package: OpenAI.Codex_26.506.3741.0_x64
  • App/process metadata observed: 26.506.31421
  • Bundled browser plugin: openai-bundled/chrome/0.1.7
  • Native Messaging host: com.openai.codexextension
  • Native host binary: extension-host.exe
  • Browser extension origin: chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/

What platform is your computer?

Windows x64.

What issue are you seeing?

The Codex bundled Chrome native host (extension-host.exe) appears able to consume unbounded committed memory when used on a Windows machine with a large .codex/sessions history. In my crash dump, multiple Codex extension-host.exe instances dominated commit and the machine reached near-zero available physical memory. The final BSOD was VIDEO_TDR_FAILURE (116) in nvlddmkm.sys, but the TDR failure status was C000009A (insufficient resources), and the memory dump points to Codex native host memory exhaustion as the preceding cause.

This may be related to #19381, but this report has dump-backed attribution to the Codex Chrome native host rather than only Task Manager observations.

Evidence

From Windows minidump / full memory dump analysis:

  • Bugcheck: VIDEO_TDR_FAILURE (116)
  • Bucket: 0x116_IMAGE_nvlddmkm.sys
  • TDR status: C000009A (insufficient resources)
  • Available pages in full memory dump: 411 (about 1.6 MB available)

The full dump process commit table showed:

extension-host.exe count: 7
aggregate commit: about 77 GB

five individual extension-host.exe processes were each about 16.16 GB committed

The extension-host.exe image path was the Codex bundled Chrome plugin host:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

The binary appears to be Rust and contains strings related to:

rollout watcher
ReadDirectoryChangesW
.codex/sessions
\\.\pipe\codex-browser-use

The local Codex session store was also unusually large:

.codex/sessions file count: 874
total size: about 26.5 GB
files above 100 MB: 38
large-file total: about 24.8 GB
largest JSONL session file: about 5.2 GB

Several very large session JSONL files contained repeated session_meta records and forked history. This may matter if the browser native host watches or parses rollout/session files for browser integration.

Why this looks like an upstream Codex issue

The display driver was where the system finally crashed, but the dump shows the system was already under extreme memory pressure. The dominant commit was from Codex Chrome native host processes, not from the GPU driver or a foreground browser tab.

Observed chain:

Codex Chrome native host memory growth
  -> system-wide memory exhaustion
  -> NVIDIA TDR reset cannot allocate needed resources
  -> VIDEO_TDR_FAILURE (116)

Expected behavior

  • The Codex Chrome native host should have bounded memory use per native messaging connection.
  • Large .codex/sessions / rollout JSONL histories should be streamed, capped, indexed, skipped, or handled incrementally rather than loaded or retained unboundedly.
  • Native host failure should degrade the Chrome bridge, not exhaust system memory.
  • If the host watches session files, it should avoid repeatedly parsing huge historical files across multiple host instances.

Local mitigation

I published a small local mitigation here:

https://github.com/SimpleZion/codex-extension-host-guard

It does not disable the Codex browser extension. It changes the Native Messaging manifest to start a small guard process, which then launches the original extension-host.exe under a Windows Job Object memory limit. On the affected machine, the guard was configured with:

memory_limit_mb=2048
isolate_home=false

After applying it:

  • Chrome/Edge launch codex-extension-host-guard.exe.
  • The guard launches the original Codex extension-host.exe.
  • The original host process is confirmed to be inside a Windows Job Object.
  • The extension remains enabled.
  • No Codex session history is deleted.

This is only containment. The upstream host should still bound memory use and handle very large session stores safely.

Additional notes

I intentionally omitted crash dumps, full private paths, tokens, and full session filenames. I can provide additional redacted WinDbg snippets if maintainers need specific commands/output.

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't working

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions