›_ Codex Issues
Codex Issues / #14795

gpt-5.4: new-thread first turn is still extremely slow

Open 💬 7 comments Opened Mar 16, 2026 by Sapientropic
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

### What version of Codex is running?

Observed on March 16, 2026.

Windows machine with detailed local evidence:

  • Codex App: 26.311.2262.0
  • codex-cli: 0.113.0
  • local models_cache.json refreshed on 2026-03-16T07:46:08Z with client_version: 0.115.0 and still included gpt-5.4

Also observed on local Codex clients on macOS on the same date, but the detailed log excerpts below are from Windows Desktop because that is the machine I could inspect directly.

What issue are you seeing?

gpt-5.4 is still intermittently extremely slow on the first turn of a brand-new thread in local Codex clients, even though the March 9-11, 2026 incident was marked resolved.

The key boundary for this report is:

  • new thread + first prompt is the slow path
  • once the first response finally lands, later turns in the same thread are much healthier
  • existing threads are much faster to reopen / continue
  • this reproduces across local clients on both Windows and macOS

So this does not look like generic "all prompts are slow equally." It looks much closer to a fresh-session / cold-start path.

Typical user-facing behavior:

  • brand-new thread sits in Thinking / Working for a long time
  • sometimes it goes through the familiar reconnect / retry sequence before any response appears
  • existing threads that were already alive earlier seem much less affected

What steps can reproduce the bug?

  1. On March 16, 2026, open Codex Desktop or another local Codex client using gpt-5.4.
  2. Start a brand-new thread.
  3. Send a trivial first prompt.
  4. Observe a long no-op delay / reconnect retries / very slow first response.
  5. Then reopen an existing thread and send a comparable prompt.
  6. Observe that the resumed thread is much faster.

What is the expected behavior?

Fresh threads should start as quickly as resumed threads. The first turn of a new thread should not stall for tens of seconds or require repeated reconnect retries before anything appears.

Additional information

This report adds a more specific boundary than the broader slowness reports:

  • new thread first turn is slow
  • existing thread resume is fast
  • the Windows Desktop logs point at model/list / models refresh during the conversationId=null phase

Sanitized Windows Desktop log excerpts from March 16, 2026:

2026-03-16T01:47:21.846Z ... response_routed ... conversationId=null durationMs=5019 ... method=model/list
2026-03-16T02:13:31.139Z ... Codex app-server connection state changed ... mostRecentErrorMessage="... failed to refresh available models: timeout waiting for child process to exit" next=disconnected previous=connected
2026-03-16T07:15:33.085Z ... response_routed ... conversationId=null durationMs=2848 ... method=model/list
2026-03-16T07:16:59.166Z ... response_routed ... conversationId=... durationMs=102 ... method=thread/resume
2026-03-16T07:28:40.062Z ... response_routed ... conversationId=... durationMs=1 ... method=turn/start

Another new-thread run showed this sequence:

2026-03-16T01:56:43.595Z ... conversationId=null ... durationMs=3044 ... method=model/list
2026-03-16T01:57:14.373Z ... conversationId=... durationMs=1 ... method=turn/start

So in that run, model/list returned, but turn/start for the new thread still did not happen until about 31 seconds later.

Related context / not exact duplicates:

  • #14048 looked like the broader March 9 incident and was closed after mitigation
  • #14756 is broader "Codex is very slow lately"
  • #4541 is an older newConversation timeout report with a similar entry point

This report is specifically about the still-reproducible March 16, 2026 residual / recurrence where the sharpest boundary is new-thread first turn vs existing-thread resume.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 4 months ago

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

  • #13869
  • #13709
  • #14756
  • #14048

Powered by Codex Action

Sapientropic · 4 months ago

I reviewed the auto-suggested overlaps:

  • #14048 looks like the broader March 9-11 incident and was already closed after mitigation.
  • #14756 is a broader ongoing slow-response report, but it does not isolate the fresh-thread boundary.
  • #13709 is much more macOS Desktop bundled-worker / proxy specific.

The reason I kept this as a separate report is the narrower boundary and the extra local evidence from March 16, 2026:

  • new thread first turn is the slow path
  • existing thread thread/resume stays relatively fast
  • Windows Desktop logs point at slow model/list plus failed to refresh available models: timeout waiting for child process to exit during the conversationId=null phase

If maintainers prefer, I am happy to consolidate this into #14756, but I wanted the new-thread-first-turn cold-start pattern to be searchable on its own.

etraut-openai contributor · 4 months ago

Please use /feedback to upload logs and session details, then post the thread ID here.

Sapientropic · 4 months ago

The thread ID：019cdce9-237b-7a90-8366-410c0ed286fb

moomoohorse321 · 4 months ago

I also observe this on our school's arm-cpu clusters using the VScode extension. The slow part lasts around couple minutes and is reproducible on all the new threads as detailed in previous discussion. It's also worth noting that we have this on all the models (not just GPT-5.4).

When it's hanging, the entire text box is not working (i.e. can't put text, can't choose model, can't change reasoning effort and all other buttons at the bottom.)

Some additional details on our cases:
On our cluster the https://github.com/openai/codex/issues/8965 is still not resolved, meaning all of our school's student has their codex spinning the same error:

listen EACCES: permission denied /tmp/codex-ipc/ipc-90816.sock
shoyann · 3 months ago

I reproduced this on the Windows desktop app and collected a small comparison set.

Environment

  • Codex desktop app
  • Version: 26.313.5234.0
  • Windows
  • Prompt: say hi
  • Same network / same client session
  • Measured to first visible response

New thread, first turn:
2.13s, 1.96s, 4.68s, 1.91s, 1.90s, 1.68s, 3.19s

Existing thread, same prompt:
3.45s, 1.63s, 1.56s, 2.11s, 1.68s, 1.31s, 1.29s

Summary from this small sample:

  • Mean: 2.49s for new threads vs 1.86s for existing threads
  • Median: 1.96s vs 1.63s
  • If I remove the single highest outlier from each group: 2.13s vs 1.60s

So this is still a small and noisy sample, but it points in the same direction: brand-new threads appear to have modest extra first-turn latency compared with resumed threads on Windows desktop.

My guess is that there may be some startup cost on the new-thread path (thread bootstrap, context preparation, summary initialization, model availability refresh, etc.) that is already amortized on resumed threads.

Not sending an unsolicited PR per the contribution policy, but happy to run more controlled comparisons if helpful.

lumincui · 2 months ago

I’m seeing a similar new-session / first-turn latency pattern from Codex CLI 0.125.0.

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 from fresh codex exec processes:

  • 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

This does not appear to be a full hang. The command eventually returns pong, but a trivial first turn still has a ~6-8s latency floor.

I also noticed repeated TUI warnings:

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:

[features]
tool_suggest = false

codex features list shows tool_suggest disabled, but the minimal codex exec latency did not materially improve. So my current guess is that the baseline delay is separate from tool suggestion loading, possibly somewhere in session/thread startup or the send/first-response path.

One other non-blocking error appears after codex exec returns:

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

The command still succeeds, so this may be unrelated, but it suggests there may also be a session persistence race/state issue.