Repository navigation
Codex Desktop remote compaction repeatedly fails on long sessions #24544
Description
What version of the Codex App are you using?
- Windows desktop package path:
OpenAI.Codex_26.519.5221.0_x64__2p2nqsd0c76g0 - Crashpad annotation seen in local process args:
26.519.41501 - Codex CLI/runtime:
codex-cli 0.133.0-alpha.1/windows-x86_64
What subscription do you have?
ChatGPT-authenticated Codex Desktop session. Plan not included in this redacted local report.
What platform is your computer?
Windows, Codex Desktop app.
What issue are you seeing?
Remote compaction repeatedly fails across multiple Codex Desktop threads when sessions become long-running / large-context. This makes /goal and long standing Codex workflows effectively unusable, because the thread reaches compaction and then dies instead of compacting/resuming normally.
The repeated local log error is:
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
This does not appear to be a local auth/reachability issue. Running codex doctor --summary against the real user profile after cleanup reports:
13 ok · 1 idle · 0 warn · 0 fail ok
Doctor also reports auth configured, WebSocket connected with HTTP 101, and provider endpoints reachable over HTTP.
What steps can reproduce the bug?
- Use Codex Desktop on Windows with
gpt-5.5and high reasoning. - Start or resume a long-running task such as a
/goalworkflow, Git hygiene audit, or large structured extraction job. - Continue until the session reaches the remote compaction path.
- Codex POSTs to
/backend-api/codex/responses/compact. - The request connects and auth is attached, but compaction fails with
stream disconnected before completion.
Local evidence
Recent compact failures from logs_2.sqlite, redacted to thread IDs and request-size diagnostics only:
2026-05-26T08:39:15+02:00 thread=019e5f7f-2a42-7491-94b1-3a3b65c55600
last_api_response_total_tokens=237047
all_history_items_model_visible_bytes=804876
estimated_tokens_of_items_added_since_last_successful_api_response=1466
failing_compaction_request_model_visible_bytes=826350
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
2026-05-26T08:36:50+02:00 thread=019e5b53-d4cc-7183-9a21-3a0544595302
last_api_response_total_tokens=234680
all_history_items_model_visible_bytes=1010829
estimated_tokens_of_items_added_since_last_successful_api_response=1428
failing_compaction_request_model_visible_bytes=1032303
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
2026-05-26T08:32:34+02:00 thread=019e62df-52ae-74f3-b54f-9cb040ef6f92
last_api_response_total_tokens=235538
all_history_items_model_visible_bytes=681186
estimated_tokens_of_items_added_since_last_successful_api_response=12634
failing_compaction_request_model_visible_bytes=702660
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
A detailed trace for one failure shows:
api.path="responses/compact"
auth_header_attached=true
duration_ms=67288
connected to 172.64.155.209:443
Request failed method=POST url=https://chatgpt.com/backend-api/codex/responses/compact error=error sending request
Local mitigations attempted
- Archived failed/giant local active thread rows in
state_5.sqlite. - Stopped stale per-thread
codex.exe app-server --listen stdio://workers that were reactivating failed rows. - Reduced active local session load from hundreds of millions of tracked tokens to ~26M, with no active row above 1M tokens.
- Verified no new compact errors immediately after cleanup.
- Tried enabling
remote_compaction_v2, but it caused Codex Desktop to crash on reload, so it was disabled and removed from config.
Expected behavior
Remote compaction should complete reliably for long-running Desktop sessions, or Codex should gracefully fall back / retry / trim locally instead of making /goal workflows unusable.
Additional information
This appears similar to prior stream disconnected before completion reports, but the impact here is specifically that Codex Desktop long-running /goal workflows cannot be used reliably even when local auth, websocket, and reachability checks pass.
Activity
github-actions commentedon May 26, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
EthanSK commentedon May 27, 2026
Hitting the exact same failure pattern on macOS / Codex Desktop / codex-cli 0.130.0 / gpt-5.5 / xhigh reasoning today (2026-05-27). Two consecutive
codex_core::compact_remoteERRORs in~/.codex/logs_2.sqlite~8 minutes apart with identical diagnostics:Session UI froze at "Context compacted" exactly as described — both attempts terminated at the same byte threshold, single retry budget per turn, no recovery.
Root cause (matches @aydos's #17880 hypothesis)
The Cloudflare edge in front of
chatgpt.comidle-times-out streaming responses at ~300s for non-Enterprise tiers. The codex Rust client retries viaApiRetryConfigwithmax_attempts = request_max_retries = 4(plus initial = 5 total attempts); each attempt is killed at the same idle cap, so the visible "stream disconnected before completion" is the 5-retry budget collapsing to ~300-317s. Compact payloads under ~600-700KB normally finish in the window; once history crosses ~800KB the unary/responses/compactendpoint can no longer reliably complete inside that budget.Workaround (works on macOS, untested on Windows)
Force the local compaction code path. The gate is
codex-rs/core/src/compact.rs::should_use_remote_compact_task → provider.supports_remote_compaction() → is_openai() || is_azure_responses_provider().is_openai()returns true ONLY whenprovider.name == \"OpenAI\"(case-sensitive literal). Defining a custom provider with the same backend/auth but a differentnamefield drops the client onto the streamingPOST /responsespath which doesn't hit Cloudflare's idle cap.In
~/.codex/config.toml:TOML gotcha: a naive append puts the key inside the last
[plugins.*]table above it and silently no-ops. Verify withcodex exec --skip-git-repo-check \"say hi\"— the banner should showprovider: openai-custom, notprovider: openai.After applying, sessions that were stuck mid-compaction need to be restarted (closing/reopening the affected thread) since the broken compact attempt is already in the in-memory state.
Same workaround applied earlier this week on the OpenClaw embedded codex-app-server (which uses the same compact code path) cleared the identical failure cluster. Auth still passes, ChatGPT-OAuth tokens are signed identically, just the unary→streaming code-path swap.
Possible upstream fix candidates: short-circuit the 5× retry on Cloudflare hangup (currently they all hit the same idle cap, wasting ~300s before surfacing the error), or fall back to the local streaming path automatically when remote compaction fails repeatedly on the same payload.
[-]Codex Desktop remote compaction repeatedly fails on long sessions, breaking /goal workflows[/-][+]Codex Desktop remote compaction repeatedly fails on long sessions[/+]Arnasltlt commentedon Jun 3, 2026
I’m seeing the same Desktop remote compaction failure on macOS, but with local Desktop lifecycle evidence that may narrow the cause beyond a generic backend timeout.
User-facing error:
Environment:
Failed log:
Relevant sequence from the failed thread:
Successful comparison from the same app/workspace session:
I checked that successful log for
EPIPE,Stopping app-server transport,browser use route window missing, androute window is not live; there were no matches.Interpretation: in at least this failure, compact starts successfully, but Desktop later loses the browser/sidebar route window for the same conversation and the app-server stdio transport dies with
EPIPE. The UI then reports the compact stream as disconnected. This may be related to the larger/responses/compacttimeout class, but the local evidence points to Desktop route/window ownership or app-server transport lifecycle being part of the failure mode on macOS.2batsloverandomartifactromps-dotcom commentedon Jun 10, 2026
I can corroborate this class of failure on Windows Codex Desktop with current local evidence from long-running
/goalsessions.Environment observed locally:
What makes this look like more than ordinary summarization loss:
/goalthreads have hundreds ofthread_goal_updatedevents in their rollout JSONL./goalthread shows an explicit compaction boundary:token_countevents look corrupted/saturated rather than merely high:That pattern appears after long
/goalexecution and suggests the app/server context accounting or rehydration state can get pinned at the context limit with zero per-turn input, making the thread appear effectively broken even when the model-visible context should have been compacted or recoverable.User-visible impact:
/goalmode can leave a thread unable to keep progressing reliably.Expected behavior:
/statusor local telemetry should distinguish actual context saturation from compaction/replay/accounting corruption.This seems related to the broader cluster around goal continuity and compaction (#5957, #19910 as referenced from #24016, #22890, #25215, #25779), but this comment is specifically confirming the Desktop
/goal+ auto-compaction breakage on0.136.0-alpha.2with fresh Windows local rollout evidence.etraut-openai commentedon Jun 29, 2026
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
/feedbackand open a new bug report.