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.
What version of the Codex App are you using?
Codex Desktop on Windows:
OpenAI.Codex_26.506.3741.0_x6426.506.31421openai-bundled/chrome/0.1.7com.openai.codexextensionextension-host.exechrome-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/sessionshistory. In my crash dump, multiple Codexextension-host.exeinstances dominated commit and the machine reached near-zero available physical memory. The final BSOD wasVIDEO_TDR_FAILURE (116)innvlddmkm.sys, but the TDR failure status wasC000009A(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:
VIDEO_TDR_FAILURE (116)0x116_IMAGE_nvlddmkm.sysC000009A(insufficient resources)411(about 1.6 MB available)The full dump process commit table showed:
The
extension-host.exeimage path was the Codex bundled Chrome plugin host:The binary appears to be Rust and contains strings related to:
The local Codex session store was also unusually large:
Several very large session JSONL files contained repeated
session_metarecords 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:
Expected behavior
.codex/sessions/ rollout JSONL histories should be streamed, capped, indexed, skipped, or handled incrementally rather than loaded or retained unboundedly.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.exeunder a Windows Job Object memory limit. On the affected machine, the guard was configured with:After applying it:
codex-extension-host-guard.exe.extension-host.exe.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.