Codex Desktop: image-only first turn remains inProgress after websocket prewarm timeout without sampling
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_startedwas emitted, but there was notask_complete.tokens_usedremained exactly0.- 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:
- Open Codex Desktop on macOS.
- Create a new projectless thread.
- Paste/upload an image without additional text and submit it.
- The thread enters
inProgressand 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=0and the turn remainedinProgress.
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 itmessage, 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.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗