Abnormally high ram usage in mac app

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

• #18567
• #18545
• #18568

Powered by Codex Action

was it both high ram and high cpu presist even launch/reopen the app?
that might half similar to #18463, just render proc no high ram like urs. but i did saw codex app use 29gb before i hit oom

wait, but first time ever i observed this

<img width="343" height="134" alt="Image" src="https://github.com/user-attachments/assets/a8de786a-5ad8-454e-b83d-19496302ee56" />
indeed it use lot ram then usage now. codex app Version 26.417.41555 (1858)

I often get a MacOS system dialog popping up saying my system has run out of RAM. That's usually when Codex gets to about 20GB of RAM usage.

@matthabermehl was cpu usage high too?

@happyf-weallareeuropean It was high, but I do not remember exact numbers (around 80% or so). My laptop fans were pretty loud (I have a Macbook Pro M5, it takes heavy usage to push it to this fan noise level).

@lauorbit mine today cpu really chill, but ram bulk at 1.6gb+
at least my macbook dont like macmini need to always plug in. just not sure what next moment it gone back. it looks like it have one more hidden trigger or what.

I’m seeing a similar Renderer memory/performance issue on Codex Desktop for macOS.

Setup:

• Mac with 16GB RAM
• Codex Desktop version: 26.417.41555 (build 1858)
• macOS version: macOS 26.4.1 (25E253)

What I observed:

• With Memory enabled, Codex Desktop became very sluggish.
• Renderer memory climbed noticeably, and opening multiple windows/threads made the app much worse.
• After disabling Memory in Settings, the app became immediately smoother. I could open several windows without the same level of lag.
• This looks like a strong A/B signal: Memory enabled makes the desktop app much heavier; Memory disabled improves it a lot.

Remaining issue:

• Disabling Memory improves single-window usage, but multiple open threads still cause lag and Renderer CPU/RAM pressure.
• My local ~/.codex/sessions directory is around 5.2GB.
• The largest rollout file is around 207MB, with several others over 80-130MB.
• So this may involve both Memory overhead and large local conversation history/thread switching overhead.

Current workaround:

• Disable Memory
• Restart Codex when Renderer usage climbs
• Keep fewer threads/windows open
• Avoid keeping very large old threads active

Happy to provide logs or a /feedback session ID if useful.

I got a pop up from mac that my system was running low on memory and I need to close some apps. The window showed ChatGpt app using 36GB of memory. I wish i had taken a screenshot.

I was able to take a screenshot this time.

<img width="796" height="942" alt="Image" src="https://github.com/user-attachments/assets/2757e906-548d-4742-a86d-a2645bfd8889" />

same..

What's going on here? This has been an issue for at least 6 months. On my computer, when ChatGPT is open it steadily eats memory until restarted (right now it's at 26.5 GB!). On two occasions I've woken up my computer in the morning to find it completely hung, with ChatGPT at over 100 GB and the system kernel panicked and requiring a hard restart.

For now I'm adding ChatGPT to Quitter, but this seems like a good opportunity to try out Claude.

For me this happens everytime I use the @ function to reference a file, every single time codex/chatgpt will balloon to about 60GB before cooling down again.

Adding a fresh macOS data point with process-level measurements.

Environment

• Codex Desktop / ChatGPT app: 26.803.41515 (build 6321)
• macOS 15.7.8 (24G824)
• Apple Silicon / arm64
• 16 GB physical memory

Observed behavior

During a long-running, tool-heavy Codex task, the app UI became effectively unusable and I could no longer continue the conversation. The affected process was the Codex content renderer inside /Applications/ChatGPT.app, not the local model/runtime process.

Measurements taken while the UI was stuck:

• Codex (Renderer) physical footprint remained at approximately 13.1–13.2 GB
• Approximately 11.6 GB of that process's memory had been swapped out by macOS
• The retained footprint was predominantly dirty process-created memory rather than ordinary file cache
• CPU usage peaked at approximately 350%
• During a 5-second process sample, the renderer main thread remained continuously inside Chromium/Electron's V8 JavaScript execution path and did not return to the normal UI event loop
• A short repeat measurement showed no meaningful memory decline

Restarting Codex Desktop immediately cleared the condition and restored normal operation.

Workload context

The affected task had been active for a long time and accumulated many tool calls and substantial tool-result output in one thread. This is a workload correlation, not a proven root cause. I do not have a renderer heap snapshot, so I cannot responsibly attribute the retained memory to a specific component, DOM subtree, tool-output block, or application state path.

Expected behavior

Renderer memory should remain bounded during long tool-heavy tasks. Older or collapsed tool results should be virtualized or released so that one task cannot make the entire Desktop UI unresponsive. If the renderer exceeds a safe resource threshold, the app should recover the renderer or preserve the task while presenting a recoverable error rather than requiring a full app restart.

Raw transcripts and local paths are intentionally omitted for privacy. I can collect a heap snapshot or another maintainer-requested diagnostic if there is a supported procedure for doing so.