App UI gets extremely slow and laggy during long sessions

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

• #11975
• #11981

Powered by Codex Action

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.

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

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.

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.

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

@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.

@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.

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

@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.

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

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.

@etraut-openai An update on your suggestion. Even with a new thread, right now Codex has been working on the same problem I gave it for 8+ hours and in that time RAM usage has gone to 2.9 GB. So even if I create a new thread for the next task once this run ends, I'm still experiencing performance issues from this single run.

I ran into the problem too.. no idea how to fix. Also on m1 macbook pro 32gb. On version Version 26.303.1606 (806)

I ran a long session last night (about 1.5hr) and updated codex this morning. Either due to the long session or the update, codex is really really laggy. I archived the long session, still having issues tho.

This is a consistent problem for me as well. I update frequently and still run into this problem every time. Maybe I have many threads in the app? I'm not intending them all to be active, but I don't want to have to go through and continually archive threads, because it's useful to have old threads around to return to reread from time to time (especially "how-to-run" type of threads"). However, right now it is too slow to be usable at all.

In theory, this app is an amazing way to organize threads and organize a project, and not sure anything else like it exists right now. However, based on how it's currently designed, and what it keep in memory right now, it's totally unusable.

<img width="233" height="579" alt="Image" src="https://github.com/user-attachments/assets/56407f4e-82f1-4ca9-b4c5-f772472b2b94" />

Maybe building everything electron and javascript framework is not always a good idea
The codex app get horribly laggy the more i use it

Have the same issues as described above. To the point where the App becomes unusable on a MacBook Pro with an M4 Max. This should not happen!

Same issue. Codex app barely useable now, with no parallel threads and MacBook Air M2 16gb. The UI is just freezing.

IGNORE: diagnostic comment from tooling

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.

@etraut-openai Yes! The version of Windows is also affected. Approximately 700–800 MB of RAM (25 GB free). However, switching between threads takes 3–8 seconds. https://github.com/openai/codex/issues/11011#issuecomment-4086420251

I start a new thread for almost every task, so that’s not the problem.

Same issue here. Started happening after I installed a new update today.

Same here. Startup takes over a minute (!) before the app becomes properly interactive. Animations lag during this time and it says 'Model Loading' at the bottom. The app consumes 100% of a single core during this entire time.
After this initial startup, interacting with threads and switching is reasonably fast, but this doesn't feel right for startup performance.
M1 Ultra Mac Studio, so my CPU isn't that bad, either.

Codex Desktop App is basically unusable for me at this point. When it is running, explorer.exe starts hanging eventually and the entire PC becomes unresponsive until I close Codex. Memory usage eventually jumps to hundreds of GBs.

For me, the startup of codex windows app is extremely slow, usually takes more than 5 minutes to load.

Have same on Tahoe 26.2 Apple M1 Max 32GB.
Downgrade to Version 26.409.20454 (1462) solves issue. Hope OpenAI will resolve it in las updates

Same on Windows.

For anyone interested in the CLI TUI side of this: #21945 traces the equivalent root cause in the Rust TUI renderer (codex-rs/tui/). The transcript overlay (Ctrl+T) has the same architectural problem — O(n) full-session rebuild with no virtualization, no height caching, and full markdown re-parse per cell on every overlay open and width change. Different renderer, same disease.

+1 on a recent version: Codex Desktop 26.506.31421 became very slow after opening giant local histories. In my case it was not just renderer DOM growth: app-server built/resumed huge state from an 825MB rollout (~4.5GB RSS, 252s thread/resume) and attempted a 405MB IPC state broadcast. Long-session UI performance needs bounded history hydration, not only UI virtualization.

Follow-up / PR offer: I read the contribution docs and understand external PRs are invitation-only. If the team thinks this direction fits, I’d be happy to take a stab at an invited PR for the open-source app-server side.

Conceptually, the fix I’d propose is:

• in no case should opening a thread load the entire transcript into app-server + client state
• open threads from metadata + the latest tail only, roughly the most recent 100-200 messages or a small byte cap, whichever comes first
• lazy-load older chunks only when the user scrolls upward / explicitly asks for them
• compact or summarize the old head for model context instead of treating the full durable transcript as active state
• keep large tool outputs/artifacts behind references, not inline in normal thread state
• add hard byte/count limits so thread/read, thread/resume, and stream-state snapshots cannot produce 100MB+ payloads
• document that Desktop/IDE clients should use paged turns/items and never full-hydrate a completed thread just because it was clicked

The desktop side still needs closed-code changes, but the app-server can provide the safe bounded contract and fail gracefully when a client asks for full hydration of an oversized rollout.

try this
https://github.com/Dirard/CodexDesktopFix

Codex is too laggy