Codex Renderer is consuming excessive memory

Open 💬 3 comments Opened Aug 12, 2026 by barisyild

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.803.41515

What subscription do you have?

ChatGPT Pro 20x

What platform is your computer?

arm64

What issue are you seeing?

The Codex Renderer processes are consuming an excessive amount of memory.

This may be related to conversations becoming very large over time. A long conversation contains a significant amount of scrollable content, and it appears that too much of this content may remain loaded or rendered in memory. Implementing more efficient list virtualization, lazy rendering, or pagination could potentially reduce the memory usage of long conversations.

I am also not sure why two separate Codex Renderer processes are running at the same time, or whether both processes are contributing to the excessive memory consumption.

What steps can reproduce the bug?

Open or continue using a conversation that contains a large number of messages.
Scroll through the conversation or continue adding messages.
Check the application's memory usage in the system process monitor.
Observe that the Codex Renderer processes consume an excessive amount of memory.

The exact conditions that trigger the issue are currently unclear.

What is the expected behavior?

Memory usage should remain within reasonable limits, even when a conversation contains a large number of messages. Content that is not currently visible should not remain fully rendered in memory unnecessarily.

Additionally, the application should not run multiple renderer processes unless they are required.

Additional information

The issue appears to become more noticeable as the conversation grows longer.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 15 days ago

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

#36920
#37584

Powered by Codex Action

mrkn · 15 days ago

I'm experiencing the same issue. I've already submitted the feedback report with the session log, and its ID is 019ff37b-5584-7b21-b91c-f482f5a7a9c0. The report content is:

Title: Codex renderer processes grow by approximately 100 MB per hour while idle, causing 12+ GB of compressed memory

Environment:

- Codex desktop app: 26.803.61601 (build 6396)
- Embedded Chromium: 151.0.7922.76
- macOS: 26.5.2 (25F84)
- Architecture: Apple Silicon / ARM64
- Physical memory: 32 GB

Issue:

Multiple `Codex (Renderer)` processes continuously retain more memory over time. The growth occurs even when Codex is completely idle and the renderer process count remains unchanged.

macOS eventually compresses most of this memory and starts using substantial swap. Fully quitting Codex immediately removes all `Codex (Renderer)` processes and causes VM Compression to decrease dramatically. I have reproduced this behavior multiple times.

Reproduction steps:

1. Fully quit Codex.
2. Start Codex again and wait for renderer creation to settle.
3. Leave Codex open on one task without interacting with it.
4. Record the same renderer PIDs and their Memory and VM Compressed values in Activity Monitor.
5. Wait approximately 60 minutes without using Codex.
6. Record the values again.

Observed idle-test results:

- Renderer count before the idle period: 16
- Renderer count after 60 minutes: 16
- The same renderer PIDs remained alive.
- About 13 renderers grew uniformly from approximately 94–102 MB to approximately 194–204 MB each.
- This is approximately 100 MB of additional Memory per renderer per hour while idle.
- Those renderers’ VM Compressed values grew from approximately 23–35 MB to approximately 174–190 MB each.
- Total renderer Memory increased from approximately 1.98 GB to approximately 3.27 GB during the idle hour.
- System-wide compressed memory increased from 8.22 GB to 12.25 GB.

Longer-running state:

After roughly 10–11 hours, many of the same renderers reached approximately 1.04–1.11 GB each, with approximately 1.02–1.08 GB of VM Compressed memory per renderer.

At that point:

- The 15 visible Codex renderers accounted for approximately 13.2 GB of Memory.
- Approximately 12.2 GB of that was shown as VM Compressed.
- System-wide compressed memory was 14.84 GB.
- Swap usage was 15.14 GB.
- Memory pressure was yellow.

A `footprint` inspection of representative affected renderers showed:

- PID 20860: 1,133 MB physical footprint
- PID 20861: 1,134 MB physical footprint
- PID 20831: 1,065 MB physical footprint
- Approximately 1.02–1.09 GB in each process was dirty Chromium app-specific memory.
- Reclaimable memory was reported as 0.

Expected behavior:

Idle renderer memory should stabilize or be released. Background or inactive renderers should not independently accumulate approximately 100 MB per hour indefinitely.

Additional observations:

- The problem is not primarily an increasing renderer count. Existing renderer processes grow while their PIDs and total count remain stable.
- User interaction is not required to trigger the growth.
- The similar growth rate across many renderers suggests a shared periodic background operation or duplicated state, although I cannot determine the underlying allocation from outside the application.
- Fully quitting and restarting Codex is currently the only reliable workaround.
- Chrome’s Memory Saver does not affect these Codex renderer processes.

I am attaching screenshots showing:

1. The long-running state with approximately 1 GB of compressed memory per renderer.
2. The state shortly after restarting Codex.
3. The same renderer PIDs after approximately 60 minutes of inactivity.

Please investigate whether background renderer/WebContents state or a periodic task is allocating data in every renderer without releasing it.

mattLummus · 5 days ago

+1 - having issues on both Windows and OSX