Codex Desktop: image-only first turn remains inProgress after websocket prewarm timeout without sampling

Open 💬 1 comment Opened Jul 15, 2026 by prefect12

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop 26.707.72221 (build 5307); bundled codex-cli 0.144.2

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

A new, small, image-only thread was accepted by Codex Desktop and then remained indefinitely in inProgress. The image attachment was successfully embedded in the rollout, but the model turn never started.

Local evidence:

  • task_started was emitted, but there was no task_complete.
  • tokens_used remained exactly 0.
  • There was no assistant output, tool call, or error surfaced in the UI.
  • The logs never reached run_sampling_request.
  • The last relevant startup event was:

startup websocket prewarm timed out before the first turn could use it

After context preparation, no fallback, retry, sampling request, explicit failure, or cancellation state followed. The UI continued to show the turn as active.

This differs from the frozen-renderer/active-backend behavior in #24287: in this occurrence, the backend model request did not start at all.

What steps can reproduce the bug?

The failure is intermittent rather than deterministic:

  1. Open Codex Desktop on macOS.
  2. Create a new projectless thread.
  3. Paste/upload an image without additional text and submit it.
  4. The thread enters inProgress and never produces a response or error.

Affected session ID: 019f635f-aa68-75f2-a6cd-f966af760d7d

Affected turn ID: 019f635f-ab9f-7703-9e3a-09df6d503b6c

Timeline (Asia/Shanghai):

  • 2026-07-15 09:24:01: thread created.
  • 2026-07-15 09:24:16: websocket prewarm timeout logged; context preparation completed.
  • After that: no sampling request or lifecycle completion; tokens_used=0 and the turn remained inProgress.

The local image file still existed and the rollout contained the encoded image input, so this was not caused by a missing temporary attachment.

A different thread successfully entered model sampling approximately one minute later in the same app-server process. This suggests the account and model service were not experiencing a total outage.

What is the expected behavior?

If websocket prewarming fails, Codex should fall back to a normal connection or retry the sampling request. If it cannot continue, it should mark the turn failed and surface an actionable error. A turn that never reaches sampling should not remain indefinitely in inProgress.

Additional information

Possibly related issues:

  • #21360 reports unfinished Codex Desktop turn lifecycles, including small image sessions.
  • #21880 contains the exact startup websocket prewarm timed out before the first turn could use it message, but reports Windows reconnect loops that usually recover.
  • #24287 reports UI/backend state desynchronization, but its backend often continues consuming model resources; this case stayed at zero tokens with no sampling request.

This case may bridge #21360 and #21880: a startup prewarm timeout appears to trigger a lifecycle recovery failure where neither fallback nor terminal cleanup occurs.

I can provide a redacted rollout event sequence and local log timeline if maintainers need them. The original image and private local paths are intentionally not attached.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗