›_ Codex Issues
Codex Issues / #24618

Codex Desktop: /responses/compact can hang for 30-60 minutes or return 504 while normal responses_websocket works

Resolved 💬 6 comments Opened May 26, 2026 by SimpleZion Closed Jun 29, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #24544
  • #24538
  • #24432
  • #24372

Powered by Codex Action

SimpleZion · 1 month ago

Additional clarification after reviewing the automatically linked related issues (#24544, #24538, #24432, #24372): this report overlaps with the general compaction failures, but the distinguishing signal here is the transport/path split.

Local evidence from the affected Windows Desktop session:

  • Normal assistant turns are using transport="responses_websocket" with api.path="responses" and continue to work.
  • The blocking operation is specifically automatic context compaction through POST https://chatgpt.com/backend-api/codex/responses/compact.
  • One observed failure returned HTTP 504 after duration_ms=1776225 (~29m36s), with client log text shouldn't retry!.
  • Another affected compaction window had no rollout progress for ~60m40s before context_compacted was finally persisted.
  • The post-compaction context was not near the model limit: observed last_total=109177 with model_context_window=258400; the persisted compacted record itself was only ~83 KB.
  • Local network checks did not reproduce a general connectivity/upload problem: WinHTTP had direct access, no HTTP(S) proxy environment variables were set, Cloudflare WARP was disconnected/not routing chatgpt.com, chatgpt.com:443 was reachable, and unauthenticated POSTs to the same /responses/compact endpoint returned fast 401 responses, including with an approximately 1 MB body.

So from the local evidence this is not just "large thread reaches context limit" and not a general local network outage. It looks more like /responses/compact HTTP-path reliability/timeout handling diverges from the normal responses_websocket path. The user-visible failure mode is that Codex Desktop stays in "正在自动压缩上下文" / thinking for tens of minutes, with no cancellable or recoverable UI state.

Expected fixes would be along the lines of: bounded timeout, clear recoverable error, cancellation, retry/failover behavior, and/or making automatic compaction use the same reliable transport path as normal turns when possible.

kuangyonglin · 1 month ago

I posted a related workaround report here: (https://github.com/openai/codex/issues/22309#issuecomment-4560402459). In short, pinning the local VS Code extension to 26.506.31004 and Codex Desktop to 26.506.3741.0 made my long-running remote sessions usable again, while keeping the remote CLI at 0.134.0.

koby8260 · 1 month ago

Additional reproduction on Codex Desktop 26.602.40724

I am seeing what appears to be the same long-session compaction/recovery failure family on a newer Codex Desktop build.

Environment

  • Codex Desktop: 26.602.40724
  • App bundle version: 3593
  • Bundled agent: codex-cli 0.137.0-alpha.4
  • Model: gpt-5.5
  • Plan: ChatGPT Pro
  • OS: macOS 26.4.1, Darwin 25.4.0, arm64
  • Session/thread ID: 019e96d3-e6ef-7123-bb9f-05b024bef389

Local rollout evidence

Rollout file: ~/.codex/sessions/2026/06/05/rollout-2026-06-05T16-08-50-019e96d3-e6ef-7123-bb9f-05b024bef389.jsonl

Timeline from the rollout:

  • 2026-06-06T01:32:54.686Z: token count showed last_token_usage.input_tokens = 219085, model_context_window = 258400.
  • 2026-06-06T01:33:44.104Z: token count showed last_token_usage.input_tokens = 239755, model_context_window = 258400.
  • 2026-06-06T01:35:25.519Z: token count showed last_token_usage.input_tokens = 244602, model_context_window = 258400.
  • 2026-06-06T01:40:31.158Z: task_complete emitted with last_agent_message: null.
  • 2026-06-06T01:40:31.656Z: a new automatic task started for the same active goal.
  • 2026-06-06T02:12:32.112Z: I manually interrupted the follow-up turn after it had been stuck/running for about 31 minutes.

The original active goal was not completed. The thread recovered neither with a visible assistant message nor with an actionable compaction error.

Related local prior evidence

This same machine saw a similar failure one day earlier in two other threads:

  • 019e9650-7eaa-7c62-af5d-9544344a721c: null completion at 2026-06-05T05:55:11.240Z; last high token sample last_token_usage.input_tokens = 91847.
  • 019e965c-c94c-70c2-8b17-6a38c23921aa: null completion at 2026-06-05T06:05:58.938Z; last high token sample last_token_usage.input_tokens = 74723.

The local handoff for those failures explicitly called out the symptom family: responses/compact, last_agent_message:null, and repeated empty completion.

Additional observation

~/.codex/process_manager/chat_processes.json still contained 8 records for the affected conversation after the failure, all pointing at pytest commands from the same session. The recorded OS PIDs were no longer alive when checked with ps, so there may also be stale process-manager cleanup state after this failure/abort path.

Expected behavior

When a long thread approaches compaction/recovery conditions, Codex should either:

  • complete context compaction and continue the active goal, or
  • fail with a visible, actionable error that includes request ID / endpoint / retry state, and preserve a reliable recovery path.

Please investigate why task_complete can be emitted with last_agent_message: null near the context limit and whether automatic goal continuation is waiting on/retrying remote compaction without surfacing a failure.

etraut-openai contributor · 21 days ago

Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use /feedback and open a new bug report.

Showing cached comments. Read the full discussion on GitHub ↗