App UI gets extremely slow and laggy during long sessions

[BlueBlazin]

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

26.212.1823 (661)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.2.0 arm64 arm

What issue are you seeing?

The electron UI is reacting very poorly to long running sessions with high number of outputs generated and stored.

In my case, the UI starts to get slow and laggy when the renderer process has consumed about 4GB of RAM and becomes really unresponsive at 5GB+ (which shouldn't be difficult for my 64GB macbook pro to handle).

What steps can reproduce the bug?

Keep using codex without restarting the app until Codex Helper (Renderer) shows 5GB+ memory usage on a 64GB unified memory macbook pro.

What is the expected behavior?

The UI shouldn't become slow, laggy, and at times unresponsive.

Additional information

This issue will only be exacerbated as models get better and are expected to work for longer, so I hope it is given higher priority.

[github-actions]

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

• Codex VS Code: after code changes impossible to continue in the same chat thread because of performance issue #11975
• Codex app 100% CPU Usage even when only one agent is running #11981

Powered by Codex Action

[michaeltyson]

I’m seeing what appears to be a related issue within the VS Code/Cursor extension, but triggered specifically when switching between long-running conversations.

In my case, the slowdown does not only occur after extended uptime. It happens immediately when selecting a large conversation from the sidebar. The extension appears to load and render the entire transcript at once, which blocks the UI thread for 10–30 seconds on sufficiently long sessions.

By contrast, Cursor’s native chat UI progressively hydrates older messages as you scroll, which avoids blocking the interface.

Observed behavior:

• Switching to a long session causes a visible UI freeze.
• CPU spikes during the load.
• The interface becomes unresponsive until the full transcript is rendered.

This suggests that the extension may be deserializing and rendering the entire conversation synchronously instead of using virtualization or incremental loading.

If that’s the case, implementing:

• Message virtualization,
• Lazy loading on scroll,
• Or chunked/background hydration

would likely eliminate the blocking behavior and prevent the renderer memory growth from compounding over time.

Happy to provide additional reproduction details if helpful.

[peteromallet]

I'm experiencing this too on a 16GB Macbook pro, had thought it might be my RAM but apparently now

[etraut-openai]

Are you still seeing this behavior with the latest version of the app? We've made a number of performance improvements in the last week.

[AMilassin]

Maybe those updates made it worse? 26.217.1959. Since like Friday my Codex App (M1, 32GB) is unusable. Like 5-10 seconds to switch threads.

• reinstalled
• nuked .codex/
• nuked .../Library/Application Support/Codex/
• open -na /Applications/Codex.app --args --disable-gpu. does not even start
• disconnected monitors

Still super slow. back to codex cli.

[peteromallet]

Maybe those updates made it worse? 26.217.1959. Since like Friday my Codex App (M1, 32GB) is unusable. Like 5-10 seconds to switch threads.

• reinstalled
• nuked .codex/
• nuked .../Library/Application Support/Codex/
• open -na /Applications/Codex.app --args --disable-gpu. does not even start
• disconnected monitors

Still super slow. back to codex cli.

Similar for me also

[BlueBlazin]

@etraut-openai I now regularly restart the app since I posted this so I don't know if it's still as bad. But what I can report is that I have been working on the same project for 3 weeks now, and Codex briefly consumes more than 6GB RAM after startup and opening the thread before decreasing to ~600MB. I have been watching as this initial RAM usage has gone up from 4gb to 5gb to now over 6gb.

I think you guys need to fundamentally rethink how you are handling long threads as this is not feasible long term.

[etraut-openai]

@BlueBlazin, when you say you've been using the "same project" for three weeks, do you mean you've been using the same thread that entire time? If so, why? We recommend creating a new thread for each task you want to perform. For example, I create many dozens of new threads every day within the same project.

[BlueBlazin]

@etraut-openai Good question. I guess... I didn't know better? Will some of my context carry over when I make a new thread?

[etraut-openai]

@BlueBlazin, the context doesn't carry over to the next thread, but that's fine. The agent will quickly establish the context it needs for the next task. If you keep using the same thread, the context will get diluted through compactions anyway. It's better to start fresh. Not only will you see much better performance, the model will also be more effective because it won't be distracted by all of the context from past tasks.

This is a good insight. It's likely that other Codex users are making similar assumptions about using the same thread for many tasks. That would explain many performance issues and other error conditions that we're hearing about. We should do a better job directing users to create a new thread for each task.

[BlueBlazin]

Thanks! I'll give it a try and see if it improves agent output.

[BlueBlazin]

An interesting change I've noticed immediately. In my extremely long thread the model had stopped 'vocalizing' thoughts completely.

But now in the new thread it's back to outputting things it is currently working on, e.g.: I’ll derive this from the project’s ... or I found dedicated baseline/checklist docs and.... So in my old thread it would just quietly do its thing and only at the end of a round (at least that's what I call it) would it output what was done.