Fix: Desktop App - Message send is delayed for ~8 seconds in new sessions after the latest update

Having exactly same issue after update

Same here. Experiencing significant delay when sending messages. <img width="1098" height="172" alt="Image" src="https://github.com/user-attachments/assets/01a646e6-a0cf-4cce-858c-bdec6c9772d2" />

I'm seeing the same issue. You can downgrade using this link:

https://persistent.oaistatic.com/codex-app-prod/Codex-darwin-arm64-26.415.20818.zip

Having exactly same issue after update

@jaewon-kim-dev Thanks, the issue disappeared after downgrading the version.

Same here on macOS. Codex 26.415.21839 (1763) on macOS 26.3.1 (M-series). New threads created after the update show ~6–8s spinner delay before the message actually sends; second message onward is worst. Reasoning level doesn't change it. Rolling back isn't viable for me — would appreciate a fix rather than a downgrade workaround.

Same here on Codex 26.415.21839 (1763) on macOS 26.3.1 (M-series).

Same here, sometimes taking up to 20s on a message

Can comfirm that the downgrade fixes it and also experiencing the same issue

I can confirm that I am being affected by this issue as well, I do not want to downgrade just yet

same here, I downgraded from Version 26.415.30602 (1773) to Version 26.409.20454 (1462), the problem disappeared immediately.

Codex 26.415.30602 (1773), macOS Darwin 25.5.0 arm64, new thread first message fast, second and later messages stall on send button for ~5-8s before inference starts.

I can still reproduce this on the latest desktop update.

Environment:

• Codex Desktop: 26.415.30602 (1773)
• macOS: 26.4.1 (25E253)

Behavior:

• In non-git directories, pressing Enter or clicking Send can stall for several seconds before inference actually starts.
• A brand new thread may feel normal at first, but after a couple of messages the send button starts spinning for multiple seconds.
• In git-backed projects, the issue is much less noticeable or does not reproduce.

What I ruled out:

• SSH is not the root cause. I can reproduce it locally as well.
• UserPromptSubmit hooks are not the root cause. I disabled them for A/B testing and the delay still happened.

Relevant logs from the latest version still show the same pattern:

• worker_rpc_response_error
• errorMessage="Not a git repository"
• method=stable-metadata
• repeated git rev-parse --git-path codex-shell-environment.json

What seems to be happening:

• turn/start is emitted quickly, so the click/submit action itself is not blocked.
• The desktop app appears to keep hitting git metadata resolution in non-git directories and may be treating "not a git repository" as a retryable error instead of a normal empty result.
• That retry loop seems correlated with the UI delay before the message is actually sent.

This still reproduces for me on 26.415.30602 (1773), so it does not appear to be fixed by the April 18, 2026 update.

but i want the new compact command in the app. any other solution?

I can still reproduce this on the latest desktop update (26.415.30602).

A couple of extra details from my side that may help narrow it down:

• This also happens in Chats, not just in project threads.
• In some cases the message does get sent, but the text stays in the composer for a few seconds as if the UI did not fully clear the draft state yet.
• If I work from a git-backed project, the delay becomes much less noticeable or disappears.
• If I use a non-git context, the send latency is much easier to reproduce.

So from the user side it really feels like there are two related symptoms:

1. delayed send / spinner before inference starts
2. composer state not clearing immediately after send

That makes it feel more like a desktop app state / metadata issue than a model or network issue.

Additional corroborating symptom from another reporter (now tracked in #18461): after the message is already sent, the same text can remain in the composer input box (residual draft text).\n\nObserved on Codex App 26.415.32059 (1789), macOS Darwin 25.4.0 arm64 arm.\n\nThis appears related to the same send-path regression; sharing here so diagnosis stays centralized.

Counter to the git-repo theory: reproduces for me inside a git-initialised project on 26.415.32059 (1789) / macOS 26.3.1 (M-series). Same 6–8s send delay from the second message onward. So the rev-parse retry loop is likely a symptom, not the only cause.

Happening to me on 26.415.32059 (1789) / macOS 26.3 (25D125) MBP M3 Max 128Gb ram, but doesn't happen on 26.415.32059 (1789) / macOS 26.3 (25D125) MBA M4 32GB ram

update: I disabled the Computer Use plugin from my MBP and the issue disappeared

I would say this is related to that

26.415.32059 (1789) on MBP M5 Max 64Gb ram, still happening after disabling Computer Use but does seem like it might have crept in when I installed that.

so I tested it more, seems to be happening to me only for folders, where I don't have a git repo;

so if I create an empty folder test-codex-app and then add that location, it will start lagging from the second message:

Me: greetings <= instant submit in both projects
Assistant: Hello. What do you need?
Me: hi again <= instant submit for project with git, 5-10 seconds for empty folder

Same issue here hangs for 5 to 7 seconds and if I leave the screen to another thread, the thread gets stuck on sending

Using Mac Max Chip 36GB

this is by the way in threads that became over 90K context window

Same issue here hangs for 5 to 7 seconds and if I leave the screen to another thread, the thread gets stuck on sending Using Mac Max Chip 36GB

Identical issue on a Mac Mini M4 Pro with 24GB.
If I leave the thread while it’s sending, it can stay stuck until I return to the app.

I pulled an old version from Wayback Machine. It initially worked. Reconnected to my project folder and it's now broken again.
This suggests that part of it appears to persist in local Codex state/data.

Thanks to everyone who reported this.

We understand the cause of this problem and are working on getting a fix out soon.

@etraut-openai managed to do a full debugging and this is the summary of my finding.

Basically there is a git related metadata fetch that happens and it stalls the UI

I instrumented the desktop app locally and narrowed the stall down pretty precisely.

What I found:
- The delay is not in the backend or `app-server`.
- Once the request is actually sent, `turn/start` returns in `1-2ms`.
- The stall happens **before** `turn/start` is enqueued.

The blocking step is in the desktop app’s local owner submit path:
- submit enters owner path immediately
- then it awaits a function I traced as `K()`
- `K()` does a `refetch()` and then may call `update-thread-git-branch`
- only after that does the app proceed to local preflight and `turn/start`

In my repro, the slow step was exactly that awaited refetch:
- `q begin` / `K begin`: immediate
- `K refetch done`: ~`7012ms` later
- `local preflight`: ~`53ms`
- `turn/start`: `2ms`

I also built a patched test version where `K()` was changed from awaited to fire-and-forget:
- submit became effectively immediate
- `local preflight`: ~`39ms`
- `turn/start`: `2ms`
- no visible stall

So the issue appears to be:
- the desktop app is awaiting a git/branch-refresh sync on the critical send path
- that refresh can take several seconds, especially in non-git folders
- the send should not block on that work

One important extra note:
- I also verified the `stable-metadata` / `Not a git repository` errors are a real separate bug
- but suppressing that error alone did **not** remove the send delay
- the actual submit blocker was the awaited branch-refresh refetch before send

Suggested fix:
- don’t await the thread git branch refresh before submit
- make it fire-and-forget, move it after send, or bound it with a short timeout / skip for non-git folders

Everytime i send a message it takes few secinds to be submitted and sometimes i leave the app and go back few minutes later and still see it is not submitted. And when i click it goes through

@etraut-openai
I just downloaded the updated version: 26.415.40636 (1799) and it is fixed

Problem seems to be the await on the git repo metadata refetch, great work 💪

Confirming that this appears fixed for me after updating Codex Desktop to Version 26.415.40636 (1799) on macOS.

I retested on fresh threads, and follow-up messages are now sending immediately / feeling fast again. Before this update I was consistently seeing the second and later messages sit in the submit spinner for several seconds before the message was actually accepted.

My separate issue was closed as a duplicate of this one, so adding this here as a datapoint that the latest app update seems to have resolved it on my machine.

I’m seeing what looks like a similar ~6-8s baseline delay from Codex CLI as well, not only the desktop app.

Environment:

• codex-cli 0.125.0
• Auth mode: ChatGPT
• macOS / Darwin arm64
• Terminal: iTerm.app 3.6.9
• Default model: gpt-5.5

Minimal repro:

time codex exec --skip-git-repo-check "只回复 pong"

Repeated runs:

• gpt-5.5: 9.45s / 6.50s / 7.26s, average ~7.74s
• gpt-5.4-mini: 6.41s / 7.33s / 7.41s, average ~7.05s

So this does not look like a full hang. The CLI eventually responds, but even a trivial prompt has a 6-8s latency floor.

I also saw repeated warnings in ~/.codex/log/codex-tui.log:

failed to load discoverable tool suggestions: request failed with status 403 Forbidden

The failed request appears to hit:

chatgpt.com/backend-api/.../connectors/directory/list

and returns a Cloudflare challenge HTML page.

I tried disabling tool suggestions:

[features]
tool_suggest = false

codex features list confirms tool_suggest is false, but this did not materially improve codex exec latency. That makes me think the 6-8s delay may be a separate cold-start / send path issue, while the tool suggestion 403 may be extra TUI noise.

I also see this non-blocking error after codex exec returns:

failed to record rollout items: thread ... not found

The command still returns pong, so I don’t think that is the primary latency cause.

Same here

--
Best Regards
Yasin Hassanien
Cell phone: (+974)7778-9476

On Wed, Apr 29, 2026, 8:17 PM Lumin @.***> wrote:

lumincui left a comment (openai/codex#18264) <https://github.com/openai/codex/issues/18264#issuecomment-4345942411> I’m seeing what looks like a similar ~6-8s baseline delay from Codex CLI as well, not only the desktop app. Environment: - codex-cli 0.125.0 - Auth mode: ChatGPT - macOS / Darwin arm64 - Terminal: iTerm.app 3.6.9 - Default model: gpt-5.5 Minimal repro: time codex exec --skip-git-repo-check "只回复 pong" Repeated runs: - gpt-5.5: 9.45s / 6.50s / 7.26s, average ~7.74s - gpt-5.4-mini: 6.41s / 7.33s / 7.41s, average ~7.05s So this does not look like a full hang. The CLI eventually responds, but even a trivial prompt has a 6-8s latency floor. I also saw repeated warnings in ~/.codex/log/codex-tui.log: failed to load discoverable tool suggestions: request failed with status 403 Forbidden The failed request appears to hit: chatgpt.com/backend-api/.../connectors/directory/list and returns a Cloudflare challenge HTML page. I tried disabling tool suggestions: [features]tool_suggest = false codex features list confirms tool_suggest is false, but this did not materially improve codex exec latency. That makes me think the 6-8s delay may be a separate cold-start / send path issue, while the tool suggestion 403 may be extra TUI noise. I also see this non-blocking error after codex exec returns: failed to record rollout items: thread ... not found The command still returns pong, so I don’t think that is the primary latency cause. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/18264#issuecomment-4345942411>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFP6757CARRL3LWU6HTQDDT4YI2I7AVCNFSM6AAAAACX4N2A5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNBVHE2DENBRGE> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: @.***>