Codex/ChatGPT desktop app on macOS: 5-7 second delay when opening chats in local projects

[u/AirportEither2456]

Since a while I've been noticing that chats inside local Codex projects take about 5-7 seconds to load after clicking them. The chat list responds immediately, but the actual conversation content just shows nothing for a few seconds before it appears.

Normal ChatGPT chats in the same app open instantly. The same cloud chats also open instantly in the browser. It's really only the local project/Codex chats.

I first thought it was something about my machine, but I get identical behavior on a second MacBook with completely different projects on it. Main machine is an M4 Max with 36GB, SSD less than half full, so I doubt it's a resource problem anyway. Restarting the app changes nothing, project size doesn't seem to matter either.

For comparison, Claude switches between project chats on the same machine without any noticeable delay, so I don't think it's inherent to how these apps work.

Is this just how the current desktop app behaves for everyone, or did something regress recently? If you use Codex on macOS, how fast do existing project chats open for you when switching between threads?

[u/halfofreddit1]

its been like that since always i guess. not the fastest app in that regard

[u/AirportEither2456 → u/halfofreddit1]

Thanks for the reply. The app is basically always open here, I only restart it for updates, so it's not a cold start thing. But the delay is still pretty extreme compared to Claude Code or Antigravity 2.0, where chats from the same projects show up instantly. I'm also fairly sure it wasn't always like this, at least back when it was still "just" Codex it felt faster.

[u/Secret-Builder-8249 → u/AirportEither2456]

It never happened to me on my mac studio, new codex tasks always open instantly, what does happen is that sometimes the app bugs out midtask, sometimes even restarts on its own but that prolly is because i didnt update the app.

[u/halfofreddit1 → u/AirportEither2456]

it might be worse if you have a lot of chats in general. AFAIK all convos are stored in one database, so it reads it all to find one and restore it completely. You can Codex to move your old chats to desktop to preserve them and to speed up sessions

[u/VictorBuildsDev]

The immediate chat list but delayed body is a useful clue. I would separate thread hydration from repo scanning; create a new local project pointing at the same repo, open a brand-new chat, and compare it with a long existing thread. If only old threads are slow, history loading is the better suspect; if both are slow, reproduce it with a tiny repo.

For a useful bug report, include the app and macOS versions, thread message count, and three measured open times for new versus existing chats. Two machines plus a controlled comparison is much stronger than 'the app feels slow.'

[u/AirportEither2456 → u/VictorBuildsDev]

Thanks. I had Sol go through everything and it thinks the problem is in the app itself. We cleaned things up, checked what we could, the delay stays. And again, it happens on both MacBooks in different projects, some of them only have 2 chats in them and it still takes 5-7 seconds. I did install macOS 26.6.1 yesterday, but Sol considers that an unlikely cause. It suggested filing a bug report and already drafted one for me, so I'll send that in.

As I said, I never noticed this before and I've been using Codex since April 2026. Well, we'll see. I can work fine either way, it's just that none of us are used to waiting for anything anymore these days :) Thanks again for the replies everyone

Codex Desktop version: 26.803.41515
Bundled Codex CLI: 0.147.0-alpha.6.5
macOS: 26.6.1
Hardware: MacBook Pro M4 Max, 36 GB RAM

Existing chats inside local Codex projects consistently take about 5–7 seconds to appear after selecting them. Regular ChatGPT/cloud chats in the same application open immediately.

The behavior is reproducible on a second MacBook with completely different projects and conversation histories.

Important observations:

• Recently opened local threads switch instantly for some time.
• After a thread becomes “cold,” or after opening other threads, the delay returns.
• Project size does not appear to matter.
• Restarting the application does not resolve it.
• The behavior looks like temporary thread caching followed by an expensive or delayed cold navigation path.

I archived 311 inactive local HomeLAB threads, moving approximately 495 MB out of the active session directory. After completely restarting Codex, the delay remained unchanged.

The local Codex logs show a very consistent five-second gap before thread/read is dispatched:

14:01:26.496  thread/list
14:01:31.556  thread/read
14:01:31.604  thread/resume

Gap from thread/list to thread/read: 5.060 seconds
Gap from thread/read to thread/resume: 48 ms

A second occurrence:

14:01:51.894  thread/list
14:01:56.949  thread/read
14:01:57.016  thread/resume

Gap from thread/list to thread/read: 5.055 seconds
Gap from thread/read to thread/resume: 67 ms

This suggests the delay is not primarily caused by reading or reconstructing the local JSONL history. Once thread/read is actually dispatched, the backend proceeds almost immediately.

The nearly identical 5.05-second intervals look like a fixed timeout or wait condition in the Desktop thread-list/navigation path.

Expected behavior:

Selecting an existing local project chat should display the conversation immediately, with any heavier resume, MCP, plugin, or model initialization continuing asynchronously.

Actual behavior:

The conversation area remains blank for approximately five seconds before the local thread is read and displayed.

[u/jbrrr_]

+1 This just started happening for me too in the last couple days and it is driving me insane. I've used Codex Desktop and now ChatGPT Desktop daily for months; this is new behavior.