Codex Renderer is consuming excessive memory #38176

Activity

1. barisyild

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Aug 12, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   performance

   on Aug 12, 2026
3. github-actions commented on Aug 12, 2026

   

   github-actionsBot

   on Aug 12, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [app][macOS] ChatGPT uses 3–5 GB RAM and makes an 8 GB Mac unusable even with no project open #36920
   • [Windows] Desktop app 26.803.41515: memory leak → silent crashes, UI desyncs from backend, project threads never load #37584

   Powered by Codex Action
4. mrkn commented on Aug 13, 2026

   

   mrkn

   on Aug 13, 2026

   More actions

   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.
   

   👍React with 👍3Reacted by Barış Yıldırım, lrehmann and Paulo Molina
5. mattLummus commented on Aug 22, 2026

   

   mattLummus

   on Aug 22, 2026

   More actions

   +1 - having issues on both Windows and OSX
6. petaxie commented on Sep 14, 2026

   

   petaxie

   on Sep 14, 2026

   More actions

   Adding measurements from a long-running local Codex conversation on ChatGPT desktop 26.908.40834 (build 8881), macOS 26.6.2 (25G83), M1 Pro / 16 GB, with embedded renderer version 152.0.7977.83.

   Our strongest observation is high memory cost when opening and interacting with the long conversation, rather than continuous idle growth. This may be a related manifestation; we have not established the same root cause as the original report or the idle-growth report above.

   Open → send → idle measurements

   We used Physical footprint from vmmap --summary, cross-checked with footprint, not RSS. Under compression, RSS substantially understated the footprint. Peaks and settled readings are separated below.

   September 14, same renderer PID 60239; times are UTC+8. Settled values held on a 30-second sampler after approximately 1–2 minutes:

   Time / action	Observed peak	Settled footprint
   ~09:55, long conversation not displayed	—	~340 MB
   ~09:56, switch to long conversation without sending or scrolling	—	~605 MB
   10:37, send first short message (hi)	964 MB	~723 MB
   10:41–10:45, send second short message (hi)	~1.4 GB; a later peak of 1.7 GB was recorded	~990 MB
   10:45–11:05, no interaction after settling	—	~940–996 MB, with some reclamation

   Thus opening alone added about 265 MB; subsequent interactions left higher settled readings within the observation window. We do not infer a leak, O(n) scaling, or “never released” from two sends. Send/response processing was not separately instrumented.

   A nearby short/blank-conversation comparison stayed at 77.9 MB after 6–8 messages (peak 78.1 MB). Renderer identities were checked in the app's Task Manager. Different conversations/renderers and rich-content differences mean this is not a length-only controlled experiment.

   Renderer recovery is only temporary relief

   Manually ending the affected renderer made the chat window transparent; it automatically recovered without a whole-app restart. Replacement renderers returned to approximately 1.16–1.18 GB, and after another replacement 1.44 GB. Other processes survived, so these were not cold application starts.

   Pinned/unpinned fresh-launch comparisons ending on a non-long conversation had similar profiles. Pinning alone did not explain the difference in those tested conditions.

   Coarse allocation evidence

   Two captures of the same replacement renderer on September 13:

   Capture (UTC+8)	Physical footprint	Lifetime peak	Tag 255: dirty / swapped	Tag 253: dirty / swapped
   20:52:16, live vmmap	1.3G	2.0G	95.6M / 1.0G	30.1M / 133.8M
   21:11:56, saved memgraph	1.7G	2.1G	108.6M / 1.3G	38.6M / 209.3M

   These are rounded tool values, and the interval contained ongoing interaction. Upstream Chromium defines Tag 255 as V8 heap pages and 253 as PartitionAlloc (source); the custom desktop binary's tag implementation was not independently verified. This prioritizes V8-managed pages, not necessarily live-object bytes. SWAPPED includes the original size of compressed/swapped pages, not literal SSD occupancy.

   The capture warned that the PartitionAlloc zone could not be examined. Offline heap analysis exposed only two system malloc zones (~306 KB), not the GB-scale V8 object graph. Task Manager reported 0K JavaScript memory for generic Renderer entries, so that column could not provide useful attribution.

   Remaining questions

   Installed-code inspection finds virtualization and paginated history APIs, so we are not claiming that the entire transcript is in the DOM. During both recoveries, the primary window initially resumed with 5 turns, then became a follower of the same surviving client a few seconds later. Cross-client snapshot/state retention is a candidate, not a confirmed cause; existing logs lack snapshot byte counts and allocation deltas. Related mechanism report: #32722, on an older Windows build.

   A supported V8 heap/retainer profile plus loaded-history/DOM counts and aggregate snapshot sizes, at switch-in and after response completion, would help distinguish history data, display/cache state and unused heap capacity. We have repeated the behavior on the affected private conversation, but do not yet have a shareable minimal synthetic reproducer.

   This is work-impacting on a 16 GB machine: one system snapshot showed 13.84 GB used, 6.35 GB compressed and 11.08 GB system swap with yellow pressure. Other applications also contribute. Short conversations were much lighter in our tests. No private transcript, raw heap contents or credentials are attached.
7. anon5376 commented on Sep 23, 2026

   

   anon5376

   on Sep 23, 2026

   More actions

   Still present on macOS desktop 26.915.31945 (build 9922), Codex Framework 153.0.8010.48.

   Idle, no running thread, no built-in browser: 10 Codex (Renderer) processes, ~2.01 GB RSS together. Largest single renderer was 844 MB. The app as a whole (ChatGPT/Codex helpers only) was ~3.87 GB.

   Closed #47519 in favor of this thread for the renderer working set.
8. barisyild commented on Oct 9, 2026

   

   barisyild

   on Oct 9, 2026

   Author

   More actions

   Consumption is still terrible; please migrate the application to Tauri.
9. ellahyyan commented on Oct 12, 2026

   

   ellahyyan

   on Oct 12, 2026

   Last edited by ellahyyan

   More actions

   Related macOS workaround documented in my report: #53427 (comment)

   I had a 1–2 second delay per typed character even in a blank conversation, severe desktop UI lag, renderer memory above 2 GB per process, and yellow macOS memory pressure. Safari and a new macOS user account using the same ChatGPT account were normal.

   What worked in my original macOS user account:

   1. Completely quit the ChatGPT/Codex desktop app.
   2. Rename the entire ~/.codex folder to ~/codex-backup-test, keeping the original folder intact.
   3. Relaunch the app to generate fresh local state.

   Typing, overall app performance, renderer memory usage, and memory pressure have now returned to normal in my case. Reinstallation had not helped. Keep the old folder: local sessions/configuration may temporarily be unavailable in the fresh profile, and the backup allows recovery.

   This is a user-observed workaround in my case, not proof that the idle memory growth or large-conversation behavior reported here has the same cause.
10. barisyild commented on Oct 12, 2026

    

    barisyild

    on Oct 12, 2026

    Author

    More actions

    Related macOS workaround documented in my report: #53427 (comment)

    I had a 1–2 second delay per typed character even in a blank conversation, severe desktop UI lag, renderer memory above 2 GB per process, and yellow macOS memory pressure. Safari and a new macOS user account using the same ChatGPT account were normal.

    What worked in my original macOS user account:

    1. Completely quit the ChatGPT/Codex desktop app.
    2. Rename the entire ~/.codex folder to ~/codex-backup-test, keeping the original folder intact.
    3. Relaunch the app to generate fresh local state.

    Typing, overall app performance, renderer memory usage, and memory pressure have now returned to normal in my case. Reinstallation had not helped. Keep the old folder: local sessions/configuration may temporarily be unavailable in the fresh profile, and the backup allows recovery.

    This is a user-observed workaround in my case, not proof that the idle memory growth or large-conversation behavior reported here has the same cause.

    The cause of the issue is already bloated chats; if you enter a bloated chat, memory usage increases, but—contrary to expectations—the memory is not released when you switch to an empty chat.