Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

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

• #17392
• #17508
• #17335
• #18363

Powered by Codex Action

I reviewed the suggested duplicates (#17392, #17508, #17335, #18363). They appear to describe the same remote compaction failure path, but I did not find a confirmed fix, timeout configuration, or official workaround. My local logs add one more data point: each failed /responses/compact request consistently fails at about 60.6 seconds, across multiple attempts, while other proxy traffic can remain active for more than 60 seconds.

Error running remote compact task: We're currently experiencing high demand, which may cause temporary errors.

All day.

+1

same

same

0.125 is still the same, failing over and over again. For such a high-frequency, recurring issue, it has been reported for so long and has severely affected the user experience—basically making it impossible to carry out long-running tasks. Yet there still hasn’t been an urgent fix. This should be prioritized as one of the most critical issues to be fixed immediately.

I consistently encounter this issue whenever a Codex session gets close to the context window limit. Codex attempts to run automatic context compaction, but the compaction task fails and the session becomes unable to continue.
The error I often see is: "Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)"
This is especially disruptive during long-running coding tasks. In my case, the agent had already delegated or started multiple subtasks, but once automatic compaction failed, the whole session got stuck and I could no longer continue the task or recover the previous plan reliably. Codex running in WSL2 ,Also project located inside the WSL environment

Repro on Codex 0.125.0 / NixOS, with measured failure durations

Hitting this consistently. Pulled compact-failure data from 4 sessions in ~/.codex/sessions/:

| Rollout size | Duration before stream-disconnect |
|---|---|
| 3.8 MB | 364 seconds |
| 11.8 MB | 93 seconds |
| 48.2 MB | 325 seconds |
| 81.3 MB | 756 seconds |

The failures span 93s to 756s — not a fixed 60s timeout as some earlier comments suggest. Smaller rollouts (3–4 MB) also fail. Pattern looks more like: the server holds the connection open during processing, then drops it at variable durations depending on queue depth or processing load.

Other observations:

• Manual /compact triggered earlier in a session (smaller rollout) usually succeeds. Auto-compact triggering near the context-window threshold is where the failures cluster.
• codex_error_info field on the error event reports "other" — suggesting the client lacks specific error categorization for this failure mode.
• Confirming the auth-path-specific finding from #19979: failures are on the ChatGPT-login backend (chatgpt.com/backend-api/codex/responses/compact).

Two things that would help triage:

1. The bug is auto-compact-specific, not generic compact. Manual /compact reliably succeeds; auto-compact at trigger threshold fails. Filing it as "auto-compact fails at the auto-trigger size" rather than the generic title may help focus a fix.
2. Recovery after the failure is unclear. When auto-compact fails mid-session, it is hard to know whether retrying succeeds, whether the rollout is still consistent, or whether the session needs to be ended. Client-side fallback (retry with smaller window, prompt the user, fall back to truncation) would make the failure recoverable rather than session-ending.

Environment: Codex 0.125.0, NixOS host, ChatGPT subscription auth (plan_type: pro).

Have exactly the same issue as @trivially , e.g. with id 019de044-c6dd-72c0-8ddc-4f14fd70f0e8

Adding another data point from Codex Desktop.

Observed on May 5, 2026 while Codex was running a coding task and automatic context compaction was triggered.

Error shown in the UI:

Context automatically compacted

Error running remote compact task: stream disconnected before completion: error sending request for url
(https://chatgpt.com/backend-api/codex/responses/compact)

Task context at the time of failure:

2 files changed +257 -0
packages/domain/src/billing-calculation.test.ts +101 -0
packages/domain/src/index.ts +156 -0

Expected behavior: automatic context compaction should complete and allow the active coding task to continue.

Actual behavior: the remote compact request failed, leaving the session at risk of losing continuity during a long-running task.

Same here. Happened 5x today and burned through all my tokens and did nothing basically.

Also seeing this on Codex Desktop for macOS.

Thread ID: 019e0390-d329-74c3-b8ab-13a32d339c9b
Codex App: 26.429.61741 (2429)
Error:

Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

This is still happening today (2026-05-07).

@etraut-openai looping you in because you previously commented in #14860 that increasing timeouts may paper over an underlying latency issue.

I opened a focused diagnostic issue here: #22798

The goal is not to claim that all /responses/compact failures are caused by the user's network. It is to give users a concrete way to test one specific failure class: whether the same network/proxy/VPN/gateway path used by Codex can keep a long-idle HTTPS request alive for more than 90 seconds.

The proposed self-test uses slee.pt, which intentionally waits before replying. This is different from a basic connectivity check against chatgpt.com, because the failure mode here is about surviving a long silent wait, not just DNS/TLS/connectivity.

If slee.pt >90s is cut off early on the same path used by Codex, that user has evidence of a transport-path idle cutoff that can directly explain stream disconnected before completion during remote compaction. If it succeeds, that specific explanation becomes less likely and the report can focus more on backend/client compaction behavior.

This may help triage the many duplicate stream disconnected before completion reports by separating network-path idle cutoff from remote compact service/client failures.

Issue "Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)"

WIndows 11
Codex 26.506.3741.0

Adding a concrete data point for the ~60s /responses/compact failures.

In my case Codex Desktop failed with:

Error running remote compact task: stream disconnected before completion:
error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

Local logs showed the compact request failing after about 60s.

I initially suspected a Codex-side timeout, especially because the Desktop bundle I had did not yet appear to include the timeout-related fix from https://github.com/openai/codex/pull/23451. However, the more useful finding was that the same local network/proxy path used by Codex could not keep a long-idle HTTPS request alive.

This test failed after about 60s on the failing path:

curl --http1.1 -v -sS -o /dev/null \
  -H 'Content-Type: application/json' \
  -d '{}' \
  -w '\nhttp_code=%{http_code} total_time=%{time_total} exit=%{exitcode} err=%{errormsg}\n' \
  --max-time 100 \
  'https://slee.pt/75s'

The upstream/remote path itself survived the same 75s delay, so the cutoff was in my local client/network path. One client I used generated aggressive idle settings and did not expose a persistent way to change them; reconnecting regenerated the config.

After switching to a client/configuration that allowed the same slee.pt/75s request to complete normally, remote compaction stopped failing in my setup.

So this does not explain every /responses/compact failure, but for failures that happen consistently around ~60s, testing the exact Codex network path with a long-idle HTTPS request is a useful diagnostic step.

Symptom
Codex Desktop compact/fork/resume fails when a thread reaches 0% context:

Context compacted
Error running remote compact task: stream disconnected before completion:
unknown variant `auto`, expected `high` or `original` at line 1 column 121843

Editing old session JSONL/transcript files does not fix it, because the failing payload is generated during the new remote compact request, not necessarily read from saved rollout history.

Root Cause / Likely Cause
remote_compaction_v2 was disabled while enable_request_compression was enabled. The old remote compaction path appears to serialize or replay an image/detail value as auto, but the receiving parser only accepts high or original.

Observed environment:

MacOS
Codex Desktop: 26.519.41501
Codex CLI: 0.133.0
enable_request_compression = true
remote_compaction_v2 = false

Fix / Workaround
Enable remote_compaction_v2, then fully restart Codex Desktop.

cp ~/.codex/config.toml ~/.codex/config.toml.bak-before-remote-compaction-v2

codex features enable remote_compaction_v2

codex features list | rg '^remote_compaction_v2|^enable_request_compression'

Expected:

enable_request_compression              stable             true
remote_compaction_v2                    under development  true

Then quit Codex Desktop completely with Cmd+Q and reopen it. After restart, compact/fork/resume works again.

Notes
Before finding the actual workaround, I checked the saved session files and confirmed there were no real JSON fields left with detail == "auto". That confirmed this was not just stale transcript corruption; it was the active compact path generating an incompatible request.

I got
Error running remote compact task: stream disconnected before completion: unknown variant auto, expected high or original at line 1 column 233067
on Mac Visual Studio Code

Adding another macOS Codex Desktop data point for the same visible error.

Environment:

Codex Desktop: 26.519.41501 (3044)
Bundled CLI: codex-cli 0.133.0-alpha.1
macOS: 26.5 (25F71), Darwin 25.5.0, arm64
Observed: 2026-05-28

Feature flags from the bundled CLI:

enable_request_compression              stable             true
remote_compaction_v2                    under development  false

Visible error:

Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

The error has been recurring during normal Codex Desktop use when a thread gets long enough to trigger automatic remote compaction.

I also ran the long-idle HTTPS probe mentioned above on the same machine/network path:

curl --http1.1 -sS -o /dev/null \
  -H 'Content-Type: application/json' \
  -d '{}' \
  -w 'http_code=%{http_code} total_time=%{time_total} exit=%{exitcode} err=%{errormsg}\n' \
  --max-time 100 \
  'https://slee.pt/75s'

Result:

curl: (52) Empty reply from server
http_code=000 total_time=60.605310 exit=52 err=Empty reply from server

So this machine appears to have a ~60s idle HTTPS cutoff on that probe, which may put this report in the client/network-path timeout bucket rather than proving a backend-only compact failure.

This worked for me:

1. Close codex app, and open codex CLI. Use 'codex resume' from the directory you were working in
2. In the CLI, send any message or ask it to compact the context
3. once done, switch back to the codex app and the error should have been fixed.

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.