Switching between threads is very slow

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

• #11000
• #10996

Powered by Codex Action

+1 - app currently unusable for me

After updating the app to the new version, I cannot use it anymore!

+1 app completely unusable (MacOS)

+1
The app is hung and completely unusable. Restarting the app does not resolve the issue. Archiving project threads also has no effect. The problem persists across relaunches.

Yes please fix this, its bad. 2021 M1 MBP

Have to put a +1 here, it is barely usable at least when you have multiple big threads going.

Same experience, M1 Max.

Just discovered that in one particular thread, there was a very large diff of unstaged changes that seemed to be choking the whole app's performance. Getting rid of that solved the performance issues on that thread at least.

I’m seeing very similar behavior, but in the Codex IDE extension running inside Cursor, not the standalone Codex desktop app.

In my case:

• Switching between long-running threads causes a full UI freeze for 10–30 seconds.
• The freeze happens immediately on selecting the thread, even before sending a new prompt.
• CPU spikes during the switch.
• The behavior worsens with longer transcripts.

From observation, it appears that the entire conversation is being loaded and rendered synchronously when switching threads. If the desktop app is using a similar rendering model, that might explain why multiple large threads cause the UI to hang or crash.

By contrast, Cursor’s native chat interface progressively hydrates messages (loading recent content first and backfilling on scroll), which avoids blocking the UI thread.

If the Codex app and extension are eagerly hydrating full transcripts on thread switch, implementing:

• Message virtualization
• Incremental/lazy loading
• Background hydration off the main thread

would likely resolve both the freezing and the memory growth issues people are reporting.

Happy to provide more detailed reproduction info from the extension side if helpful.

+1
I'm running into the same performance issues. The lag is making it difficult to use.

+ 1

+1

Same here, on huge Mac Ultra, I just have about 10 threads on my Codex app.
Each time I switch from on thread/tab to another, there is 6-10sec of loading. It's a real pain.

Same here - Windows / WSL - 26.313.41514

Same here - M2 max

@etraut-openai Can you do something agianst this big_model_radar spam on all your Github issues? Can you block that somehow? It doesn't even help to block the user. Reports to Github were also unsuccessful.

Seems this has not been updated since March, but just to highlight, 23rd April, and this is still an issue for me.
Codex Mac App, Version 26.417.41555 (1858).
macOS Tahoe 26.3
Can't be limited resources, running on a Apple M3 Pro, 36GB memory. And very few other windows open.

Just wanted to back up @redfox05 . Previously, it was far worse, made the entire app chug and borderline unusable. Now though, it can still take a couple of seconds to swap to a different chat thread. Are we always pulling the chats down from OpenAI's servers? It seems like it would make sense to cache them locally, no?

I am seeing the same thing Codex Version 26.422.62136 (2176) MBP M2 32GB RAM macOS 15.7 (24G207)

THe only apps I've got open are Chrome and Codex. Theres tonnes of CPU, GPU, RAM etc available. It feels like some kind of an io/locking issue.

Here is my feedback id: 019f57d8-c57e-7be3-b6ed-c211ab2785b1 (same issue, very slow switching tabs on Windows)

Still reproducible on macOS with ChatGPT/Codex Desktop 26.803.41515 (build 6321) and bundled Codex 0.147.0-alpha.6.5.

I captured two cold task switches immediately after a full Desktop restart:

• First task: maybe_resume_started, then maybe_resume_owner_discovery_failed exactly 5,000 ms later. The fallback thread/read took 2 ms and thread/resume took 40 ms.
• Second task: the same owner-discovery timeout after 5,001 ms, followed by a 2 ms thread/read.
• One affected task history was only 1.5 MiB, so a large transcript was not required to reproduce it.
• Reopening a task after the first cold load is faster.
• Desktop reached about 3.3 GiB resident memory across its backend, renderers, and services within a few minutes. That may amplify UI jank, but it does not explain the fixed five-second boundary.

The task data is present and readable. The visible delay is the owner-discovery watchdog before the fast read/resume fallback, not the actual history read. This looks like the same specific owner-discovery path tracked in #37398 under the broader thread-switching symptom here.

I am on Version 26.803.41515 on Windows, a workaround I did was:

• I closed ChatGPT
• I moved the files ~/.codex/logs_2.sqlite, ~/.codex/logs_2-wal.sqlite and ~/.codex/logs_2-shm.sqlite to a quarantine folder on my desktop
• Restarted my computer (not sure if needed)
• Restarted ChatGPT

And switching threads is _much_ faster. Not instantaneous, but way faster. I still have all of my chats, settings, etc. Of course, do so at your own risk, I am not sure of the ramifications of deleting the logs database.

+1