codex - 💡(How to fix) Fix Codex Desktop: /responses/compact can hang for 30-60 minutes or return 504 while normal responses_websocket works

What happened?

Codex Desktop can get stuck for a very long time at the automatic context compaction step (正在自动压缩上下文 / 正在思考). This is not the normal model response path: regular sampling is using responses_websocket and continues to work, but automatic compaction appears to use a separate HTTP endpoint:

POST /responses/compact

In one affected Codex Desktop thread, local rollout evidence shows a long blank interval around the compaction step:

2026-05-26T15:39:50.608Z  last normal tool output before compact
2026-05-26T16:40:31.346Z  type=compacted
2026-05-26T16:40:31.394Z  type=context_compacted

That is about 60 minutes 40 seconds with no rollout progress before context_compacted was finally recorded.

Earlier in the same investigation, a /responses/compact request also returned a 504 after a very long backend wait:

HTTP 504 Gateway Timeout
endpoint: /responses/compact
duration_ms: 1776225   # about 29m 36s
cf-ray: a01de0246acef244-KHH
client log: "shouldn't retry!"

The UI remains stuck in a thinking/compacting state during this period, and the user cannot tell whether it is uploading, waiting on the backend, retrying, or dead.

Why this looks specific to compact, not local network or ordinary response streaming

Local checks on the same Windows machine showed:

• Normal Codex sampling path is using responses_websocket.
• chatgpt.com:443 is reachable.
• WinHTTP proxy is direct access.
• No HTTP_PROXY / HTTPS_PROXY style environment variables were set for Codex.
• Cloudflare WARP was disconnected and its include routes did not cover chatgpt.com.
• An unauthenticated small POST to https://chatgpt.com/backend-api/codex/responses/compact returned 401 quickly.
• An unauthenticated approximately 1 MB POST to the same endpoint also returned 401 in a few seconds.

So this does not look like a general local network outage or upload throughput problem. It looks like the authenticated /responses/compact request can spend a very long time in the HTTP/backend path, while ordinary websocket responses are fine.

Thread size after compaction was not huge

After compaction completed, the same thread was well below the model context limit:

last_total ~= 109,177 tokens
model_context_window = 258,400

The local compacted rollout record itself was only about 83 KB. The problem is the time spent generating/returning the compacted result, not that the compacted result is enormous.

Environment

OS: Windows
Codex Desktop package: OpenAI.Codex_26.519.5221.0_x64__2p2nqsd0c76g0
Codex runtime / CLI: 0.133.0-alpha.1
Model: gpt-5.5
Reasoning effort: xhigh
Auth mode: ChatGPT
Normal response transport observed: responses_websocket
Problem endpoint observed: HTTP POST /responses/compact

Expected behavior

Automatic context compaction should not leave the UI stuck for tens of minutes with no actionable state.

At minimum, Codex should:

• expose clear progress/state for /responses/compact,
• have a bounded timeout with a recoverable error,
• avoid a no-progress spinner after a 504,
• allow the user to retry or continue from the last usable compacted/local state,
• preferably use the same reliable websocket transport/path as ordinary responses, or otherwise make the compact HTTP path resilient.

Actual behavior

Intermittently, automatic context compaction blocks the thread for 30-60 minutes or returns 504. Reconnecting/restarting can sometimes make progress again, but the issue recurs. This makes long-running Codex Desktop threads unreliable even when normal network access and ordinary websocket response streaming are working.