Codex Desktop: 5–12 minute TTFT in a 210k-token legacy thread before any tool I/O

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

What version of Codex CLI is running?

Codex Desktop 26.727.40816 (build 6067); embedded runtime 0.146.0-alpha.3.1; codex-cli 0.146.0

What subscription do you have?

ChatGPT subscription (tier not exposed by local diagnostics)

Which model were you using?

gpt-5.6-sol, high reasoning

What platform is your computer?

Darwin 27.0.0 arm64 arm; macOS 27.0 (26A5388g)

What terminal emulator and version are you using (if applicable)?

Codex Desktop app (not a terminal workflow); rollout source recorded as vscode

Codex doctor report

Full diagnostics and the affected rollout were uploaded through /feedback for thread 019faf0c-480a-73b3-82ff-dc1b93835762. The local doctor output is not pasted publicly because it contains local filesystem and configuration inventory. Codex version 0.146.0; auth/config/state integrity checks passed. Network failures reported by doctor occurred inside the restricted diagnostic shell and are not evidence for the user-facing incident.

What issue are you seeing?

Routine messages in one long-lived Codex Desktop task frequently show no assistant update for 5–12 minutes. Local rollout timestamps prove that the delay is backend-visible, rather than only a UI rendering delay or slow local tool execution.

Affected task uploaded via /feedback: 019faf0c-480a-73b3-82ff-dc1b93835762
Representative turn: 019fbc77-e231-7782-8fad-dbe2a4bca13a

2026-08-01T08:36:41.169Z task_started
+0.620s   429-character text-only user message recorded; 0 images
+302.522s first model-emitted tool call
+302.683s first tool result; measured tool runtime 0.161s
+302.683s token event: input=210017, cached=11008, output=185
+310.596s first assistant-visible update
+403.491s compaction (after the initial stall)

The recorded time_to_first_token_ms is 302274. No tool I/O occurred during the first 302.5 seconds.

Across 13 completed turns in the affected task:

  • total duration p50 136.7s, p95 925.6s;
  • TTFT p50 59.4s, p95 468.7s;
  • first assistant update p50 102.0s, p95 515.5s;
  • 65 tool calls used 36.9s total, only 0.83% of 4,465s completed-turn time;
  • peak per-turn input grew to 223,230/258,400 tokens;
  • context size versus TTFT has Spearman rank correlation about 0.77 (correlation only, not proof of causality).

The public report intentionally excludes private conversation content, local project details, and secrets.

What steps can reproduce the bug?

Uploaded thread: 019faf0c-480a-73b3-82ff-dc1b93835762

  1. Open the uploaded task in Codex Desktop.
  2. Continue it with legacy history at roughly 210k–223k input tokens.
  3. Send a short text-only request with no attachment.
  4. Observe that task start and the user message are recorded within one second, followed by minutes without a model-produced tool call or assistant update.

The symptom is intermittent: short text/no-image turns in this task ranged from 7.4s to 302.3s TTFT.

What is the expected behavior?

The first assistant update should arrive within normal interactive latency, or the UI should expose whether the request is queued, prefilling, or compacting rather than appearing frozen for several minutes.

Additional information

The leading unresolved component is large-context prompt assembly/prefill/model inference or backend queueing, amplified by sequential high-reasoning rounds. Local events do not expose enough telemetry to separate queue time from compute time.

Photos, web search, compaction, and client rendering do not explain the clean initial 302-second stall. Compaction happened only after the first model/tool event and first visible update.

A separate same-installation web-research task produced its first visible update in about 22 seconds. The older broad outage report #14048 is related, but it used older versions/models and was closed; this report adds a current Desktop/runtime reproduction with exact backend timestamps and a high-context correlation.

Please correlate the uploaded UTC timestamps and thread/turn IDs with server-side queue, prompt assembly, compaction, and model-serving telemetry.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 27 days ago

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

  • #35808

Powered by Codex Action

glook9001 · 26 days ago

you can acctually mention a thread, it should not compete with the older thread structure if mentioned an older thread

The feature is named @ mentions in the Codex documentation.

`````
More specifically, the item you select is added as composer context or an attached ChatGPT conversation. It is not officially called “pinning,” even though selecting it effectively pins that conversation to the current Codex prompt.

Useful documentation terms to search:

Codex @ mentions
Codex composer context
Codex ChatGPT conversation context
Codex file and chat mentions

OpenAI’s changelog uses wording such as “app and file @ mentions in the composer.”

````

raymond-itsec · 22 days ago

At least codex is faster than resolving issues that were raised 5 days ago ;-)