›_ Codex Issues
Codex Issues / #37694

[Windows][26.803.5235.0] Image-heavy chat history grows codex.exe above 16 GB and crashes code-mode host

Open 💬 2 comments Opened Aug 9, 2026 by a16036868481
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

  1. Generate hundreds or thousands of images in one or more Codex chats.
  2. Restart the Windows desktop app.
  3. Open the image-heavy chats from the sidebar.
  4. Wait several minutes while the histories are restored.
  5. 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.exe private 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_64 for codex-code-mode-host.exe.
  • codex-code-mode-host.exe later crashed with exception code 0x80000003.

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

  • #37541 — Windows 26.803.5235.0 renderer OOM and image-heavy histories
  • #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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 18 days ago

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

  • #37541

Powered by Codex Action

a16036868481 · 18 days ago

Feature suggestion: configurable memory/resource budget for large-memory machines

I have 46 GiB of physical RAM, but this workload crashed after codex.exe reached 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 target
  • memory_limit_gib: hard per-process or app-wide safety limit
  • system_reserve_gib: memory that Codex must leave available for Windows and other applications
  • image_cache_limit_gib: decoded/generated-image cache budget
  • max_loaded_threads: number of full histories allowed to remain resident
  • Optional cpu and gpu utilization preferences for image-heavy workflows

For 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:

  1. Track memory separately for the desktop renderer, codex.exe/app-server, and codex-code-mode-host.exe; a single aggregate number is not enough.
  2. At 70–80% of the configured budget, start evicting decoded image bitmaps and inactive-thread state.
  3. At 90% of the budget, stop eagerly restoring more image payloads and show a clear warning.
  4. Preserve compact metadata/thumbnails and reload full images on demand.
  5. If a process reaches a hard limit, degrade gracefully or restart only the affected worker; do not crash the whole desktop app.
  6. Show live memory usage, configured budget, system reserve, and the thread/image cache contributing most to the usage.

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.