Windows: memory usage spikes and Codex freezes after repeated context compactions

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

Summary

On Windows, Codex can become unresponsive after a long-running thread has gone through multiple automatic context compactions. Memory usage then climbs quickly and can exhaust available RAM.

Environment

  • Platform: Windows
  • App: Codex Desktop
  • Version: not captured yet

Steps to reproduce

  1. Start a long-running thread in Codex Desktop on Windows.
  2. Continue working until automatic context compaction runs several times.
  3. Keep using the same thread after each compaction.
  4. Watch Codex memory usage in Task Manager.

Actual behavior

  • After several compactions, the UI can freeze or stop responding.
  • Codex memory usage rises rapidly.
  • The machine can get close to running out of memory.
  • Recovery usually requires killing or restarting Codex, and the same thread may remain difficult to use.

Expected behavior

Codex should stay responsive after repeated context compactions. Memory used by old thread state should be released or bounded instead of growing until the app or system becomes unusable.

Notes

This looks related to #14472 and #19381, but the trigger here is repeated context compaction in the same long-running Windows session, followed by rapid memory exhaustion.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

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

  • #23257
  • #22991

Powered by Codex Action

Herrtian · 3 months ago

I reviewed the duplicate suggestions and related reports.

  • #22991 is still open and seems focused on large rollout/history JSONL files making long sessions freeze, especially when continuing a session or sending a new prompt.
  • #23257 is still open and is more specific to compaction retaining inline image base64 inside compacted checkpoints / replacement_history.
  • #22004 and #22603 overlap through oversized image-heavy rollouts and full-history hydration.
  • #22956 and #22961 look like the May 16 Windows renderer/directive regression; those had a hotfix, so I do not think this issue should be closed as that same case yet.

The remaining useful distinction seems to be the exact lag/freeze shape:

  1. opening/selecting an existing large thread freezes,
  2. sending a new prompt in an already-open thread freezes,
  3. memory spikes right after or during context compaction,
  4. Electron main process crashes with RangeError: Invalid string length,
  5. renderer crashes on Markdown/directive parsing.

This report is meant to track case 3 on Windows: repeated compactions in one long-running session, followed by rapid memory growth and UI freeze. I will leave it open for now and try to capture the app version plus whether the spike starts before or after the compacted checkpoint is written.