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

What version of the Codex App are you using (From “About Codex” dialog)?

26.415.30602 (1773)

What subscription do you have?

plus

What platform is your computer?

macos m5

What issue are you seeing?

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

What steps can reproduce the bug?

I am experiencing repeated failures in Codex Desktop when a long conversation reaches the context limit and triggers automatic remote context compaction.

The error message is:

Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
From the local Codex logs, the failure consistently happens on this request:

POST https://chatgpt.com/backend-api/codex/responses/compact
The related logs include:

Request failed method=POST url=https://chatgpt.com/backend-api/codex/responses/compact
remote compaction failed
Failed to run pre-sampling compact
What stands out is that every failed compact request takes almost exactly 60 seconds before failing. Examples from my logs:

duration_ms=60819
duration_ms=60671
duration_ms=60643
duration_ms=60864
duration_ms=60663
duration_ms=60691
duration_ms=60666
duration_ms=60644
duration_ms=60575
duration_ms=60709
This does not look like a random network issue. It looks like there may be a fixed timeout or deadline of around 60 seconds somewhere in the Codex Desktop remote compaction path.

Some additional context from the logs:

remote compaction failed
last_api_response_total_tokens=232337
all_history_items_model_visible_bytes=930076
model_context_window_tokens=Some(258400)
failing_compaction_request_model_visible_bytes=948544
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

I have two questions:

Is there a 60-second limit in Codex?
If so, I'd like to configure this 60-second limit and increase it to enable automatic context compression requests.

What is the expected behavior?

No response

Additional information

No response

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

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

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 Remote compact task consistently times out on CLI (author login), while API-compatible provider path works #19979: failures are on the ChatGPT-login backend (chatgpt.com/backend-api/codex/responses/compact).

Two things that would help triage:

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.
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

@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 #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:

Close codex app, and open codex CLI. Use 'codex resume' from the directory you were working in
In the CLI, send any message or ask it to compact the context
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.

Navigation Menu

Repository navigation

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

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Apr 18, 2026

ttllyy111 commented on Apr 18, 2026

douglasware commented on Apr 22, 2026

DuskLin commented on Apr 24, 2026

uujx commented on Apr 24, 2026

aaronysl commented on Apr 28, 2026

sinopec commented on Apr 29, 2026

xuzheliu commented on Apr 29, 2026

MrVampy commented on Apr 29, 2026

pcristin commented on Apr 30, 2026

bjmark commented on May 5, 2026

endoibiza commented on May 5, 2026

presidenzo commented on May 7, 2026

yuweuii commented on May 15, 2026

michaliskon commented on May 16, 2026

hatab2010 commented on May 22, 2026

MaiHoangViet1809 commented on May 23, 2026

CptHolzschnauz commented on May 27, 2026

Wolbyworld commented on May 28, 2026

AhmedRMIT commented on Jun 1, 2026

etraut-openai commented on Jun 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions