Repository navigation
[Windows][26.803.5235.0] Image-heavy chat history grows codex.exe above 16 GB and crashes code-mode host #37694
Description
Summary
Opening several Codex Desktop chats containing very large numbers of generated images causes unbounded memory growth during chat restoration. codex.exe grew from approximately 14.9 GB to 16.2 GB private memory, and codex-code-mode-host.exe later crashed.
This is reproducible after restarting the app and reopening image-heavy local chat history.
Environment
- Product: Codex Desktop for Windows
- App/package version:
26.803.5235.0 - Package:
OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0 - OS: Windows 11 x64, build
26100.8973 - Physical RAM: approximately 47.91 GiB
Reproduction
- Generate hundreds or thousands of images in one or more Codex chats.
- Restart the Windows desktop app.
- Open the image-heavy chats from the sidebar.
- Wait several minutes while the histories are restored.
- Observe that memory usage continues increasing and the app eventually becomes unstable or crashes.
Observed data
Four affected session transcripts totaled approximately 4.74 GiB:
- 1.53 GB
- 417 MB
- 341 MB
- 2.56 GB
The transcripts contained approximately 2,797 image_generation_end records. The largest transcript contained approximately 1,547 such records.
During the same diagnostic session:
codex.exeprivate memory increased from approximately 14.9 GB to 16.2 GB.- ChatGPT/Electron processes used approximately another 2.1 GB private memory.
- Windows Error Reporting recorded
RADAR_PRE_LEAK_64forcodex-code-mode-host.exe. codex-code-mode-host.exelater crashed with exception code0x80000003.
WER details:
- Crash time: 2026-08-08 22:43:33 Asia/Tokyo
- Faulting module:
codex-code-mode-host.exe - Exception code:
0x80000003 - Fault offset:
0x0000000000437892 - WER bucket:
0cacb1e52a308c1a69a9633b7409b3b2
The desktop log excerpts also show thread/resume calls taking approximately 49–62 seconds, followed by Conversation state not found for affected conversations.
Expected behavior
Historical image results should be loaded lazily, virtualized, externalized, or represented by compact references. Opening a chat should not materialize all historical image payloads into memory, and memory should remain bounded.
Actual behavior
Restoring image-heavy chat history materializes enough state to push Codex above 16 GB private memory. The app becomes unstable, records a Windows leak warning, and the code-mode host crashes.
Privacy
No full session transcripts, generated images, logs_2.sqlite, or full desktop logs are included in this report. A locally prepared, privacy-reviewed 11 KB archive is available for private upload if maintainers provide a secure channel. It contains only a diagnostic summary, selected log excerpts, and the WER record.
Related issues
- [Windows 11][26.803.5235.0] Renderer OOM auto-reload leaves Codex stuck on loading screen while app-server tasks continue #37541 — Windows 26.803.5235.0 renderer OOM and image-heavy histories
- [Windows] Desktop app 26.803.41515: memory leak → silent crashes, UI desyncs from backend, project threads never load #37584 — Windows 26.803.5235.0 memory leak and silent desktop exits
This report is narrower and provides a separate failure signature: codex-code-mode-host.exe WER crash after RADAR_PRE_LEAK_64, with codex.exe exceeding 16 GB while restoring image-generation-heavy transcripts.
Activity
github-actions commentedon Aug 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
a16036868481 commentedon Aug 9, 2026
Feature suggestion: configurable memory/resource budget for large-memory machines
I have 46 GiB of physical RAM, but this workload crashed after
codex.exereached only about 16 GB private memory. I would like Codex Desktop to expose an advanced resource policy in the custom config file and/or Settings.The goal should not be to force the app to allocate memory unnecessarily. The goal is to let users with large-memory workstations choose how much memory Codex may use for large session histories, image decoding, caching, and parallel tasks.
Suggested configuration model:
memory_mode = "auto" | "balanced" | "high"memory_target_gib: preferred working-set targetmemory_limit_gib: hard per-process or app-wide safety limitsystem_reserve_gib: memory that Codex must leave available for Windows and other applicationsimage_cache_limit_gib: decoded/generated-image cache budgetmax_loaded_threads: number of full histories allowed to remain residentcpuandgpuutilization preferences for image-heavy workflowsFor example, a 48 GiB machine might allow a user-selected target of 24–32 GiB while reserving 8–12 GiB for Windows and other applications. The exact defaults should remain conservative and automatic.
Important implementation details:
codex.exe/app-server, andcodex-code-mode-host.exe; a single aggregate number is not enough.A “minimum memory” setting by itself would not solve the problem because it could encourage Codex to reserve memory without reducing the unbounded history materialization. A target/limit/reserve model would provide the desired control while keeping the application stable.