Repository navigation
App UI gets extremely slow and laggy during long sessions #11984
Description
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.
Activity
github-actions commentedon Feb 17, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
michaeltyson commentedon Feb 18, 2026
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:
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:
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 commentedon Feb 18, 2026
I'm experiencing this too on a 16GB Macbook pro, had thought it might be my RAM but apparently now
etraut-openai commentedon Feb 24, 2026
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 commentedon Feb 24, 2026
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.
.codex/.../Library/Application Support/Codex/open -na /Applications/Codex.app --args --disable-gpu. does not even startStill super slow. back to codex cli.
peteromallet commentedon Feb 24, 2026
Similar for me also
BlueBlazin commentedon Feb 25, 2026
@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 commentedon Feb 25, 2026
@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 commentedon Feb 25, 2026
@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 commentedon Feb 25, 2026
@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 commentedon Feb 25, 2026
Thanks! I'll give it a try and see if it improves agent output.
BlueBlazin commentedon Feb 25, 2026
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 ...orI 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.BlueBlazin commentedon Feb 26, 2026
@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.
4 remaining items
ivanovandrewx commentedon Mar 16, 2026
Same issue. Codex app barely useable now, with no parallel threads and MacBook Air M2 16gb. The UI is just freezing.
lyyuexiaoxiang415-lgtm commentedon Mar 17, 2026
IGNORE: diagnostic comment from tooling
wbdb commentedon Mar 19, 2026
@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. #11011 (comment)
I start a new thread for almost every task, so that’s not the problem.
juanlla commentedon Mar 19, 2026
Same issue here. Started happening after I installed a new update today.
timwedde commentedon Mar 30, 2026
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.
KiaArmani commentedon Apr 2, 2026
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.
xingwangyong commentedon Apr 8, 2026
For me, the startup of codex windows app is extremely slow, usually takes more than 5 minutes to load.
zmts commentedon Apr 18, 2026
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
squarepots commentedon Apr 30, 2026
Same on Windows.
oxysoft commentedon May 9, 2026
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.rdylina commentedon May 10, 2026
+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.rdylina commentedon May 10, 2026
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:
thread/read,thread/resume, and stream-state snapshots cannot produce 100MB+ payloadsThe 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.
Dirard commentedon Jun 22, 2026
try this
https://github.com/Dirard/CodexDesktopFix
ljx2 commentedon Jun 23, 2026
Codex is too laggy