Codex Desktop: context compaction fails with remote compact stream disconnected

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

• #22031
• #21343
• #20931
• #21643

Powered by Codex Action

Adding another user-impact report for this same Codex Desktop compaction failure.

Visible UI error from the reporter's screenshot:

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)

Context compacted

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

The main impact is not only the error banner. The reporter says they often lose crucial accumulated context after this happens and cannot reliably retrieve or pass that context into another thread in the same project. As a result, they have to explain the same project state again from scratch in new threads.

Estimated frequency from the reporter: roughly 65% to nearly 100% of their longer threads hit this context-loss / unrecoverable-context problem.

Expected behavior: if remote compaction fails, Codex Desktop should preserve a recoverable project/thread summary or provide a reliable way to export/transfer the compacted context into another thread, so users do not lose task continuity.

Adding another concrete data point from Codex Desktop/CLI usage on a relatively large local codebase. The impact is severe enough that the product becomes effectively unusable for long-running coding work, not just noisy.

Environment:

• Product: Codex Desktop + Codex CLI
• CLI package: @openai/codex@0.130.0
• Platform: macOS
• Model: gpt-5.5
• Reasoning effort: xhigh
• Provider: OpenAI

Observed model/catalog data:

• codex debug models reports for gpt-5.5:
• context_window = 272000
• max_context_window = 272000
• effective_context_window_percent = 95
• Effective live window is therefore about 258400 tokens.

Earlier failing state:

• Local config had stale/unsafe values:
• model_context_window = 1000000
• model_auto_compact_token_limit = 900000
• Logs showed repeated codex_core::compact_remote / Failed to run pre-sampling compact failures.
• Error included:

compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

• Relevant log numbers around the failure included:
• model_context_window_tokens=Some(258400)
• last_api_response_total_tokens=244546
• failing_compaction_request_model_visible_bytes=998251

After manual mitigation:

• I corrected the config to match the catalog and reduced the auto-compact threshold:

model_context_window = 272000
model_auto_compact_token_limit = 160000

• This avoided the original obviously-too-late compaction cliff, but the session still felt unstable for real large-codebase work.
• Recent session token accounting still showed individual requests hovering near the manual threshold, for example roughly 154k to 159k input tokens in one session and about 147k in another, with cumulative session input totals in the millions.
• That means the manual threshold reduces one failure mode, but the user still ends up with frequent fragile compaction churn during normal work on a large repo.

User impact:

• This makes Codex unreliable for the exact use case where long context matters: sustained work in a relatively large codebase.
• The user should not have to keep guessing lower model_auto_compact_token_limit values to keep the product usable.
• Lowering the limit to 100000 is only a local seatbelt, not a real fix.

Expected behavior:

• Codex should derive safe effective compaction thresholds from the selected model catalog automatically.
• It should reserve enough margin for hidden/system/plugin/tool context instead of compacting near the cliff.
• It should handle tool-heavy histories and large local codebase sessions without requiring manual tuning.
• If responses/compact fails or disconnects, Codex should retry/fallback/recover cleanly and preserve usable thread continuity.
• The UI/CLI should surface a clear diagnostic when configured values exceed or conflict with the active model's effective window.

Related product direction: this also overlaps with the model-aware context/auto-compaction request in #16140, but the failure mode here is user-visible reliability: Codex Desktop compaction remains too fragile to support large-codebase work reliably.

The core issue is that the damn gpt-5.5 model hasn't opened up a 1M context window, but many people have configured it with the 1M setting from 5.4, which is causing 5.5 to fail to compact properly.

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

I was able to get past a stuck state by

1. switching to 5.4 (xhigh)
2. running compact
3. switching back to 5.5 (xhigh)

I'm adding model_auto_compact_token_limit = 180000 to my config.toml to try to see if that stops it from getting stuck for the time being

eh my optimism was not warranted - it's not really fixed - codex is basically unusable at the moment

Эх, мой оптимизм был неоправдан — проблема на самом деле не решена — кодекс сейчас практически непригоден для использования.

I also couldn't find even a temporary solution. Sometimes compaction succeeds, but most often it doesn't. The only more or less working method is to switch to 5.4 and send a message for automatic compression (not a command). Then compaction succeeds, but there remains a risk of quality degradation due to the model change.

Additional sanitized reproduction/request from Windows Codex Desktop:

• Bundled Codex CLI observed locally: codex-cli 0.133.0-alpha.1.
• Failure signature: Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact).
• Pattern: automatic compaction tends to trigger only when the active thread is already very large. In this user's case it is repeatedly observed around >85% context usage, where the remote compaction request is more likely to disconnect before completion.
• Local config inspection did not find a supported user-facing numeric threshold for auto-compaction. The only related local app state found was the auto-context toggle.

Request: please make automatic compaction trigger earlier, around 80% context usage, or expose a supported configurable threshold/retry/fallback path so remote compaction can complete before the thread becomes too large to compact reliably.

I am seeing the same failure in Codex Desktop on Windows during automatic context compaction.

Error

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

Impact

This is disruptive for long-running unattended goals. The failure appears only after the thread is already large enough to need compaction, so when /responses/compact fails the session is left in a fragile high-context state and the active goal stalls.

Sanitized environment

Collected on 2026-05-26:

OS: Windows NT 10.0.26200.0, x64
PowerShell: 7.6.2
Codex Desktop package: OpenAI.Codex_26.519.5221.0_x64__2p2nqsd0c76g0
Desktop version: 26.519.5221.0
Desktop-linked Codex runtime: codex-cli 0.133.0-alpha.1
Standalone global Codex CLI after manual update: codex-cli 0.133.0
Microsoft Store update check for Codex Desktop: no available upgrade
Model: gpt-5.3-codex-spark
Reasoning effort: xhigh

Relevant feature state from the Desktop-linked runtime:

enable_request_compression              stable             true
remote_compaction_v2                    under development  false
hooks                                   stable             true
plugins                                 stable             true

Observed pattern

1. Work in Codex Desktop for a long session.
2. Context grows until automatic compaction is triggered.
3. Desktop calls the ChatGPT remote compact endpoint:

https://chatgpt.com/backend-api/codex/responses/compact

1. The compact task fails with stream disconnected before completion.
2. The thread/goal stalls and requires manual recovery from a local handoff or a fresh thread.

Local session search found prior session/archive records containing this same compact failure signature. I am not attaching raw rollout logs because they may contain private prompts, local paths, or tool output.

Why I suspect the Desktop runtime still matters

I saw that openai/codex#23451 added a timeout for remote compaction and that 0.133.0 includes Add timeout for remote compaction requests. My standalone global CLI is now 0.133.0, but the Desktop-linked runtime on this Windows installation still reports codex-cli 0.133.0-alpha.1, and Microsoft Store reports no newer Desktop update. If Desktop is still using the alpha runtime, the released mitigation may not be active for Desktop users.

Requested fixes

• Ship the final remote compact timeout/retry mitigation into the Desktop bundled/runtime path.
• Add a supported setting or safer default to trigger automatic compaction earlier, e.g. around 80 percent context, before the thread is already in the danger zone.
• Add a recoverable fallback when remote compaction fails: retry with bounded timeout, preserve a pre-compaction checkpoint, or let the user continue from a generated handoff.
• Surface context usage and compact state in Desktop so users can intervene before unattended work stalls.
• Make the error actionable by distinguishing backend timeout, network disconnect, unsupported compact model, request validation failure, and context-too-large failure.

This appears to be a remote compaction robustness issue rather than a repository-specific problem.

Update with VPN/WebSocket evidence after OpenAI Support asked about network scope.

I refreshed the local diagnostics and the strongest suspect is now the VPN path rather than only the Desktop runtime mismatch.

New local network findings

chatgpt.com:443 TCP connect: OK
auth.openai.com:443 TCP connect: OK
Windows Firewall profiles: disabled
Windows user proxy: disabled
DNS auth.openai.com: resolves

A raw WebSocket probe to wss://chatgpt.com/ reached the server, but returned HTTP 403 instead of 101 Switching Protocols. I do not treat that as a failure by itself because it was not an authenticated Codex stream path, but it confirms the request reaches chatgpt.com rather than timing out locally.

The important finding is routing. Both chatgpt.com and auth.openai.com currently route through Surfshark OpenVPN:

chatgpt.com route: OpenVPN Data Channel Offload for Surfshark
auth.openai.com route: OpenVPN Data Channel Offload for Surfshark

OpenAI's Help Center network guidance for ChatGPT/Codex says Codex uses WebSockets over TCP 443 to chatgpt.com, and that proxy/firewall/TLS-inspection/security-gateway controls should not block, rewrite, or prematurely close the WebSocket handshake or long-running WebSocket connection. That matches this failure mode:

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

Current interpretation

This may be a VPN/exit-path idle timeout or long-stream handling issue triggered specifically by Codex remote compaction. Normal ChatGPT/Codex requests can work, while the long remote compact task fails after the context is already large.

Requested product behavior

Even if VPN/network is the proximate trigger, Codex Desktop still needs a resilient failure path: bounded retries, a pre-compaction checkpoint, a local fallback/escape hatch, or a supported way to trigger compaction earlier. A remote compact stream disconnect should not strand a long-running Desktop goal.

Adding a Windows Codex Desktop data point with local log evidence that distinguishes this from a basic local connectivity/VPN failure.

Environment

Product: Codex Desktop for Windows
Desktop package: OpenAI.Codex_26.519.5221.0_x64__2p2nqsd0c76g0
Desktop version: 26.519.5221.0
Bundled runtime seen in logs/state: codex-cli 0.133.0-alpha.1
Model: gpt-5.5
Reasoning effort: xhigh
Auth mode: ChatGPT account
Originator: Codex_Desktop
Platform: Windows, PowerShell host
Observed local time: 2026-05-26/27, UTC+8
Endpoint: POST https://chatgpt.com/backend-api/codex/responses/compact

User-visible behavior

A long-running Desktop thread entered automatic context compaction and stayed stuck in the UI as "auto compacting context" / "thinking" for many minutes. The thread did not recover cleanly after the compact request failed.

Key local log evidence

Automatic compaction was normally triggered by token accounting, then the remote compact HTTP call failed with a server/gateway response rather than a local network timeout:

post sampling token usage
turn_id=019e6458-332f-7493-bda1-dcefe88bb038
total_usage_tokens=245072
auto_compact_scope_tokens=245072
auto_compact_scope_limit=244800
token_limit_reached=true
model_needs_follow_up=true
needs_follow_up=true

The compact request itself:

api.path="responses/compact"
method=POST
url=https://chatgpt.com/backend-api/codex/responses/compact
estimated_bytes=1057839

Network/client progression from the same request:

starting new connection: https://chatgpt.com/
Http::connect; scheme=https host=chatgpt.com
connecting to 172.64.155.209:443
connected to 172.64.155.209:443
http1 handshake complete
connection is ready

Failure result:

Request completed method=POST url=https://chatgpt.com/backend-api/codex/responses/compact
status=504 Gateway Timeout
cf-ray=a01de0246acef244-KHH

event.name="codex.api_request"
duration_ms=1776225
http.response.status_code=504
error.message="http 504"
attempt=0
auth.header_attached=true
auth.header_name="authorization"
endpoint="/responses/compact"
auth_mode="Chatgpt"
originator=Codex_Desktop
app.version=0.133.0-alpha.1
model=gpt-5.5

There was also a local log line immediately before the 504 was surfaced:

shouldn't retry!

However, the same compact request was then emitted again one second later with the same turn_id and same approximate request size:

2026-05-27 00:09:28 POST https://chatgpt.com/backend-api/codex/responses/compact
estimated_bytes=1057839

That suggests two separate problems:

1. /responses/compact returned an actual Cloudflare/backend 504 Gateway Timeout after about 29m36s.
2. Desktop did not recover the compact turn cleanly in the UI after that failure, and appeared to continue/re-enter the compact path.

Why this does not look like a basic local network/VPN outage

Local diagnostics at the same machine showed:

WinHTTP proxy: Direct access (no proxy server)
Environment proxy variables: none found
Default IPv4 route: WLAN -> 192.168.2.1
Cloudflare WARP: Disconnected
Cloudflare WARP reason: Manual Disconnection
WARP Include mode targets: 192.168.71.0/24, simplezion.cloudflareaccess.com, edge.browser.run
chatgpt.com is not in the WARP include targets

Connectivity probes:

Test-NetConnection chatgpt.com:443: TcpTestSucceeded=True, InterfaceAlias=WLAN
Test-NetConnection api.openai.com:443: TcpTestSucceeded=True, InterfaceAlias=WLAN

Direct curl checks were fast:

https://chatgpt.com/cdn-cgi/trace
code=200 remote_ip=172.64.155.209 total=0.777s

https://chatgpt.com/
code=403 remote_ip=172.64.155.209 total=0.695s

unauthenticated POST https://chatgpt.com/backend-api/codex/responses/compact with {}
code=401 remote_ip=172.64.155.209 total=0.807s

unauthenticated ~1MB POST to the same /responses/compact endpoint
code=401 remote_ip=172.64.155.209 total=3.270s size_upload≈900952

Normal Codex Responses/WebSocket traffic in the same thread immediately before compaction was healthy, with many transport="responses_websocket" api.path="responses" events completing in tens to hundreds of milliseconds around 23:39:46-23:39:48. The failing compact HTTP request started at 23:39:51.

Current interpretation

This looks like a remote compaction reliability/recovery bug rather than ordinary network unreachability:

• The authenticated /responses/compact request reached chatgpt.com and completed at the HTTP layer with 504 Gateway Timeout.
• Basic TLS/HTTP POST connectivity to the same host and endpoint was healthy locally.
• The normal WebSocket Responses path was healthy immediately before the compact request.
• After the 504, Desktop did not present a clean recovery path and the thread remained stuck in the compact/thinking state.

Requested behavior

• Treat 504 from /responses/compact as a recoverable compact failure with a clear UI state.
• Preserve a checkpoint before starting a compact turn so the thread can resume/fork cleanly after failure.
• Avoid indefinite "thinking" / "auto compacting context" when the compact endpoint has already returned a terminal 5xx.
• If the client logs shouldn't retry!, ensure it does not immediately re-enter the same compact request without a user-visible recovery path.
• Consider falling back to normal Responses/WebSocket summarization when remote compact returns 5xx, or expose a supported setting to choose the fallback compaction mechanism.

Adding another fresh feedback data point for the same remote-compaction stream-disconnect cluster.

Visible UI error:

Error running remote compact task: stream disconnected before completion: WebSocket protocol error: Connection reset without closing handshake

Observed details from the attached logs:

• App build 26.527.21038 (3328), Codex CLI 0.133.0-alpha.4, session source vscode, model gpt-5.5-oai, effort xhigh.
• Doctor report: app-server running; Responses WebSocket reachability completed with HTTP 101 Switching Protocols; no doctor failures. Warnings were auth.credentials and mcp.config.
• At 2026-05-29T00:40:23.993Z, the /responses WebSocket stream emitted response.output_item.added with item type compaction.
• At 2026-05-29T00:40:51.559Z, the same /responses WebSocket stream logged success=false with WebSocket protocol error: Connection reset without closing handshake, after duration_ms=27565.
• Feedback upload started immediately after, at 2026-05-29T00:41:31.358Z.

This variant is the Responses WebSocket path resetting during/after a compaction output item, rather than a local doctor/connectivity failure.

Adding a macOS Codex Desktop data point with local diagnostics. This looks broader than a basic connectivity failure and appears to involve long-running thread state / compaction input size / abnormal token counters.

Environment

Platform: macOS
Codex CLI installed: codex-cli 0.135.0
Codex Desktop/runtime observed in local logs: Codex_Desktop, 0.135.0-alpha.1
Model: gpt-5.5
Reasoning effort: xhigh
Endpoint: POST https://chatgpt.com/backend-api/codex/responses/compact

User-visible error

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

Why this does not look like simple local connectivity

codex doctor --summary on the same machine reported a healthy runtime and Responses WebSocket reachability:

16 ok, 1 idle, 1 warn, 0 fail
Responses WebSocket: connected (HTTP 101 Switching Protocols)

The remaining warning was unrelated local thread inventory drift, not network reachability.

Local evidence from affected long-running threads

This has occurred repeatedly on multiple long-running Codex Desktop threads. One representative thread showed:

failing_compaction_request_model_visible_bytes=1028393
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
request attempt=4
duration_ms≈76497

The local rollout JSONL had grown to roughly 32 MB and included prior image payloads / large tool outputs / long compact replacement history. Locally trimming large image and string payloads reduced the rollout by ~13 MB, but compaction could still fail until a local compact checkpoint was appended and stale process state was cleared.

A second notable issue: the local state_5.sqlite thread row had an extreme token counter, e.g.:

tokens_used=353333553

After backing up the DB and setting the target thread tokens_used back to 0, the running Codex Desktop app-server wrote an abnormal value back again, e.g.:

tokens_used=362421042

That suggests the Desktop/app-server can keep stale in-memory thread state and rewrite bad counters even after the on-disk state is repaired.

Workaround that helped locally

The only reliable workaround so far has been:

1. Back up the rollout JSONL.
2. Replace embedded image payloads, huge tool outputs, and very large historical string fields with placeholders.
3. Append a short local compacted recovery checkpoint at the end of the rollout.
4. Back up state_5.sqlite and reset only the affected thread's tokens_used to 0.
5. Fully restart Codex Desktop / app-server so stale in-memory history is dropped.

If the Desktop process is not restarted, it may continue compacting old in-memory history and/or write the abnormal tokens_used value back to SQLite.

Expected behavior

For long-running Desktop threads, Codex should be able to recover without manual JSONL/SQLite surgery:

• Remote compaction should chunk, truncate, or otherwise safely handle large local history, images, and tool output payloads.
• If the request is too large or contains unsupported payloads, the UI/logs should report a clear actionable error instead of a generic stream disconnect.
• tokens_used should not jump to hundreds of millions or be written back from stale app-server state after local recovery.
• Desktop should prefer the latest sanitized/checkpointed on-disk history after restart/reload, instead of continuing to send stale pre-cleanup history.

Impact

This significantly impacts multi-day / long-running Codex Desktop tasks. Once a thread enters this failure mode, further work in that thread becomes unreliable until the user performs manual local repair and restarts the app.

Adding a fresh internal-feedback data point for the same remote compaction reliability cluster, with a newer TLS-shaped failure on a newer CLI.

Environment / visible details:

Codex app build: 26.527.41828 (3413)
Codex CLI: 0.136.0
Failure: Error running remote compact task: stream disconnected before completion: IO error: peer closed connection without sending TLS close_notify

This is slightly different from the earlier WebSocket protocol error: Connection reset without closing handshake reports. The reporter noted they were on the latest 0.136.0 and had previously been seeing the older compaction/reset failures, so this looks like a recurrence/new transport variant after the prior update guidance rather than the old stale-CLI case.

I could not resolve the feedback UUID to detailed Sentry logs yet, but broad recent Sentry search still shows many /codex/responses/compact stream disconnected before completion reports from the last day. Treating this as another breadcrumb for the same open compaction-disconnect issue unless later logs prove a distinct root cause.

Adding a macOS/Desktop-adjacent data point and linking the fuller CLI report I posted in #22309.

I am seeing the same core failure shape on current local Codex surfaces: remote compact goes through https://chatgpt.com/backend-api/codex/responses/compact, then can fail with stream disconnected before completion, leaving the user at risk of losing long-running coding context.

The relevant current environment:

• macOS arm64, Mac mini
• Codex CLI: codex-cli 0.137.0
• Model/config: gpt-5.5, xhigh
• Failed/guarded compact point observed locally: 195306 / 258400 input tokens
• Network route: chatgpt.com via a WireGuard-style utun5 route with MTU 1380 (public IP redacted)

The upstream ask is the same for Desktop and CLI: remote compact should retry/resume or degrade to a recoverable handoff/fallback, rather than interrupting or wedging the active thread. A user should not need a custom local PreCompact hook to avoid losing a long coding session.

Full report with suggested recovery semantics is here: https://github.com/openai/codex/issues/22309

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.

A possible workaround / diagnostic clue from another user report:

The repeated remote compaction failure (stream disconnected before completion / peer closed connection without sending TLS close_notify) turned out to be network-path specific. The user was connected through a company-provided Wi-Fi network configured for proxying overseas traffic, and remote compaction consistently failed even after Codex automatically retried the connection.

After switching from the company proxy Wi-Fi to the user's own VPN connection, remote compaction started working normally again.

This suggests that, for users seeing persistent failures specifically on long-running compaction requests, an intermediate corporate proxy / gateway timeout or idle-connection timeout may be closing the TLS stream before the compact request completes.

Possible troubleshooting step: try a different network path or VPN/proxy provider, and check corporate proxy/gateway timeout settings (especially long-lived or idle HTTPS connections). This may not be the root cause for every report, but it could be a useful workaround for some users.