Slow thread switching / loading on Codex macOS desktop app (v26.429.30905, regression)

Resolved 💬 7 comments Opened May 2, 2026 by farbodg Closed May 27, 2026

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?

  1. Update Codex macOS desktop application to version 26.429.30905 (2345)
  2. Open Codex
  3. Switch between existing threads
  4. 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

View original on GitHub ↗

7 Comments

gavinmclelland · 2 months ago

I’m seeing what looks like the same regression on macOS app.

  • Codex App: Version 26.429.30905 (2345)
  • macOS: 26.4.1 (25E253), arm64 (M4 MAX 128GB RAM)
  • Symptom: switching/loading existing threads takes seconds. Initial thread load is the worst; performance improves after a thread has been opened once, but remains slower than previous builds.
  • Uploaded performance trace: 816b1b72-cfe9-49da-a206-de5ef832c586

A local check while reproducing showed the desktop log rapidly filling with warnings of this form:

warning [electron-message-handler] No cwd found for local task conversationId=...

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 · 2 months ago

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 · 2 months ago

@guzhiling Codex was working normally for me after GPT 5.5. I only encountered this issue after updating Codex to v26.429.30905.

gavinmclelland · 2 months ago

Small follow-up: after reproducing this slowdown, the Codex macOS app terminated and I had to manually relaunch it.

Local details:

  • Previous desktop log stopped around 2026-05-02 16:36:38 PDT.
  • Relaunched Codex main process started at 2026-05-02 17:03:50 PDT.
  • I did not find a matching macOS DiagnosticReports crash file or Crashpad dump; Crashpad only had settings.dat.
  • After relaunch, the app continued emitting repeated:

warning [electron-message-handler] No cwd found for local task conversationId=...

  • One older codex_chronicle process survived from before relaunch: PID 22433, started 2026-05-02 13:42:34 PDT.
  • The relaunched app also started a new codex_chronicle PID 26925, 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 · 2 months ago
Small follow-up: after reproducing this slowdown, the Codex macOS app terminated and I had to manually relaunch it. Local details: Previous desktop log stopped around 2026-05-02 16:36:38 PDT. Relaunched Codex main process started at 2026-05-02 17:03:50 PDT. I did not find a matching macOS DiagnosticReports crash file or Crashpad dump; Crashpad only had settings.dat. After relaunch, the app continued emitting repeated: warning [electron-message-handler] No cwd found for local task conversationId=... One older codex_chronicle process survived from before relaunch: PID 22433, started 2026-05-02 13:42:34 PDT. The relaunched app also started a new codex_chronicle PID 26925, 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.

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 · 2 months ago

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 · 1 month ago

I haven't encountered any further slowness problems, so I'll close this issue.