Repository navigation
Slow thread switching / loading on Codex macOS desktop app (v26.429.30905, regression) #20802
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.429.30905 (2345)
What subscription do you have?
Pro
What platform is your computer?
Darwin 24.5.0 arm64 arm (M4 Pro 24GB RAM)
What issue are you seeing?
After updating to Codex macOS desktop app version 26.429.30905 (2345), switching between threads is noticeably slower. Previously, thread switching was near-instant, but now it consistently takes a few seconds (2-4s) to load each thread.
What steps can reproduce the bug?
- Update Codex macOS desktop application to version 26.429.30905 (2345)
- Open Codex
- Switch between existing threads
- Observe delay when loading content
What is the expected behavior?
Thread switching should be near-instant and responsive.
Additional information
- Regression from previous versions
- Occurs consistently when switching threads
- Most noticeable when first opening the app
- Initial thread load has the biggest delay
- Performance improves after a thread has been opened once (likely cached), but remains noticeably slower than previous versions
Activity
gavinmclelland commentedon May 2, 2026
I’m seeing what looks like the same regression on macOS app.
816b1b72-cfe9-49da-a206-de5ef832c586A local check while reproducing showed the desktop log rapidly filling with warnings of this form:
The active desktop log had ~52k occurrences of that warning. During the slowdown, Codex was also doing sustained local work across the app-server, renderer, and GPU helper processes. Memory, disk, and basic network checks looked healthy, so this appears local to thread/session loading rather than a general network issue.
Hope the trace helps; happy to capture anything else that would be useful.
guzhiling commentedon May 2, 2026
Significant slowdown on viscose codex as well. The codex has not been responsive and basically not usable since GPT5.5 release. I have trouble shooted with codex for potential reasons for the slowdown, terminal codex seems to speed up a little bit, but vscode codex still is not responding..
farbodg commentedon May 2, 2026
@guzhiling Codex was working normally for me after GPT 5.5. I only encountered this issue after updating Codex to v26.429.30905.
gavinmclelland commentedon May 3, 2026
Small follow-up: after reproducing this slowdown, the Codex macOS app terminated and I had to manually relaunch it.
Local details:
2026-05-02 16:36:38 PDT.2026-05-02 17:03:50 PDT.settings.dat.warning [electron-message-handler] No cwd found for local task conversationId=...codex_chronicleprocess survived from before relaunch: PID22433, started2026-05-02 13:42:34 PDT.codex_chroniclePID26925, and the current log reports:Waiting to acquire lock (owned by pid=22433)...I’m not claiming this proves the crash root cause, but it looks related to the same session/thread-loading path and may help correlate the uploaded trace.
gavinmclelland commentedon May 3, 2026
I used codex to post this because I wanted to see if the API would lag. Its quite responsive, and that leads me to believe the issue is UI specific.
Scrolling the thread is extremely slow, but if you focus the cursor on the chat follow up panel, thread scrolling speeds up to expected responsiveness levels. Does that make this a scroll-container issue?
The past two mac app release versions have had this issue for me, but did not report because I've been too busy.
farbodg commentedon May 5, 2026
Updated Codex to version 26.429.61741 (2429) today and things already seem noticeably better. Too early to say if it’s fully back to the pre-performance issue state, but definitely an improvement so far. I’ll keep testing over the next couple of days and report back with any additional findings.
farbodg commentedon May 27, 2026
I haven't encountered any further slowness problems, so I'll close this issue.
andybergon commentedon Aug 9, 2026
This cold-first-load regression is reproducible again in ChatGPT/Codex Desktop
26.803.41515(build6321) on macOS.The issue improved in
26.429.61741before this report was closed, but the current build shows a fixed five-second wait when opening an unloaded task. Local logs showmaybe_resume_owner_discovery_failedafter exactly 5,000 to 5,001 ms, followed bythread/readin 2 ms and a successful fallback resume. One affected history was only 1.5 MiB, and warm reopening was faster.The current evidence points to thread-owner discovery rather than download, cache, or transcript read time. The broader symptom remains open in #11011, and the exact owner-discovery timeout is tracked in #37398.