Codex Desktop: /responses request silent for 6m19s, then returns HTTP 507; automatic retry succeeds immediately

Summary

On Codex Desktop for Windows, a normal POST /backend-api/codex/responses request remained completely silent for about 6 minutes 19 seconds: no persisted reasoning, assistant message, or tool event appeared during the gap.

The request then completed with:

HTTP 507 Insufficient Storage
content-type: text/plain
content-length: 53
x-openai-proxy-wasm: v0.1
server: cloudflare

Codex automatically retried the same turn immediately. The retry returned 200 OK in about two seconds, the first reasoning item appeared one second later, and the turn then continued normally.

I am not interpreting the status text as proof that a physical server disk was full. The useful signal is that the 507 came from the remote Responses/proxy path, and an immediate retry of effectively the same large request succeeded.

Environment

• Codex Desktop package: OpenAI.Codex 26.803.5235.0
• OS: Windows 11 Pro, build 26200, x64
• Model: gpt-5.6-sol
• Reasoning effort: xhigh
• Auth mode: ChatGPT
• Transport: responses_http
• Endpoint: POST https://chatgpt.com/backend-api/codex/responses
• Model context window reported locally: 258,400 tokens
• Active turn context before the affected request: approximately 190,724 tokens
• Serialized request logged locally: approximately 1.51 MB
• Parent rollout JSONL at diagnosis time: approximately 120.9 MB

The separately installed codex command reports codex-cli 0.145.0; the Desktop runtime is the Microsoft Store package listed above.

Sanitized timeline

All timestamps are UTC on 2026-08-10.

14:21:06  task/turn started and user message persisted
14:21:06  POST /backend-api/codex/responses logged

            No reasoning/message/tool event during this interval.

14:27:25  request logged as completed:
            HTTP 507 Insufficient Storage
            response included x-openai-proxy-wasm and Cloudflare headers

14:27:26  Codex automatically retried POST /backend-api/codex/responses
14:27:27  retry logged as HTTP 200 OK
14:27:28  first reasoning item appeared
14:28:06  first visible assistant commentary appeared

The user-visible state throughout the silent interval was only Thinking.

Secondary observation

Later in a different turn on the same Desktop installation, a follow-up /responses request was sent after a successful local version-inspection tool call. It produced no response headers or new model event for about two minutes and was then manually interrupted. No HTTP status was received for that second wait, so I am not claiming it was another 507; it is included only as an additional pre-first-event stall observation.

Why this seems distinct

• This was not merely a renderer failing to display already-produced progress: the persisted rollout also had no reasoning/message/tool item during the 6m19s gap.
• It was not an automatic compaction request; the affected endpoint was the ordinary /responses path, not /responses/compact.
• It did not behave like a permanent request-size limit: the immediate automatic retry succeeded and continued normally.
• The UI did not surface the 507, retry, or current request phase to the user.

Expected behavior

At minimum, Codex should:

1. Apply a bounded first-response/first-event timeout before several minutes have elapsed.
2. Retry a transient upstream 5xx earlier when safe.
3. Surface a durable diagnostic state such as “waiting for response headers”, “retrying after HTTP 507”, or an actionable error instead of generic Thinking.
4. Preserve phase-specific timing for request sent, response headers received, first stream event, retry, and first persisted output.
5. Warn or offer a bounded handoff/continuation when a large long-running thread materially increases request size or startup risk.

Actual behavior

• The turn was accepted and remained on Thinking.
• No model output event was persisted for 6m19s.
• The first request ended with HTTP 507.
• The automatic retry was invisible to the user and succeeded immediately.
• Without inspecting the local HTTP logs, the user could not distinguish slow reasoning from an upstream request/proxy stall.

Related issues

• #24260 — long pre-first-output stalls that later resume normally
• #24287 — Desktop stuck in Thinking / loss of progress visibility
• #25779 — long-session/context bloat and lost active-turn control
• #21360 — turn lifecycle stalls
• #24618 — long remote HTTP waits on the former compaction path; related symptom, different endpoint

Privacy

This report intentionally omits prompt/response text, thread IDs, task titles, local user paths, request IDs, Cloudflare ray IDs, installation IDs, authentication material, and full logs. I can provide additional sanitized timing/status fields if maintainers need them.

Start by tracing the responses_http POST /backend-api/codex/responses request lifecycle and the persisted rollout events described in the report. Review how first-response timing, HTTP 507 retries, and the Thinking state are currently recorded. Done means bounded timeout and retry behavior plus durable, phase-specific user diagnostics for stalls and upstream failures.