Codex Desktop remote compaction repeatedly fails on long sessions

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

• #24449
• #23733
• #23263
• #24538
• #24432

Powered by Codex Action

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_remote ERRORs in ~/.codex/logs_2.sqlite ~8 minutes apart with identical diagnostics:

last_api_response_total_tokens=229596
all_history_items_model_visible_bytes=901048
failing_compaction_request_model_visible_bytes=922395
model_context_window_tokens=Some(258400)
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

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.com idle-times-out streaming responses at ~300s for non-Enterprise tiers. The codex Rust client retries via ApiRetryConfig with max_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/compact endpoint 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 when provider.name == \"OpenAI\" (case-sensitive literal). Defining a custom provider with the same backend/auth but a different name field drops the client onto the streaming POST /responses path which doesn't hit Cloudflare's idle cap.

In ~/.codex/config.toml:

# MUST be at the TOP of the file, BEFORE any [table] header
model_provider = \"openai-custom\"

# ...rest of your existing config...

[model_providers.openai-custom]
name = \"OpenAI-Custom\"
base_url = \"https://chatgpt.com/backend-api/codex\"
wire_api = \"responses\"
requires_openai_auth = true

TOML gotcha: a naive append puts the key inside the last [plugins.*] table above it and silently no-ops. Verify with codex exec --skip-git-repo-check \"say hi\" — the banner should show provider: openai-custom, not provider: 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.

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:

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

Environment:

Codex Desktop version: 26.601.21317
Build: 3511
Platform: macOS
Workspace: /Users/seima/Documents/Covari CTO
Failed conversation: 019e89da-5600-77f3-b92a-d00923868555

Failed log:

/Users/seima/Library/Logs/com.openai.codex/2026/06/02/codex-desktop-ddf9e318-3dc3-4c4f-bf98-d37e18c1ae35-18639-t0-i1-225000-0.log

Relevant sequence from the failed thread:

2026-06-02T22:51:07.969Z info [AppServerConnection] response_routed broadcastFallback=false conversationId=019e89da-5600-77f3-b92a-d00923868555 durationMs=0 errorCode=null hadInternalHandler=false hadPending=true method=thread/compact/start originWebcontentsId=1 requestId=c1b11b23-9fa9-4178-9f2c-6719b3b6030f targetDestroyed=false

2026-06-02T23:24:51.852Z warning [browser-sidebar-manager] IAB_LIFECYCLE route window is not live hasWindowState=false ownerDestroyed=null windowDestroyed=null windowId=1
2026-06-02T23:24:51.852Z warning [browser-sidebar-manager] IAB_LIFECYCLE browser use route window missing for cursor state conversationId=019e89da-5600-77f3-b92a-d00923868555 windowId=1
2026-06-02T23:24:51.852Z warning [browser-sidebar-manager] IAB_LIFECYCLE browser use route window missing for active state conversationId=019e89da-5600-77f3-b92a-d00923868555 windowId=1
2026-06-02T23:24:51.852Z info [browser-session-registry] IAB_LIFECYCLE removed browser session window windowId=1

2026-06-02T23:24:51.856Z warning [IpcRouter] Socket error errorCode=EPIPE errorMessage="write EPIPE" errorName=Error errorStack="Error: write EPIPE\n    at afterWriteDispatched (node:internal/stream_base_commons:159:15)\n    at writeGeneric (node:internal/stream_base_commons:150:3)\n    at Socket._writeGeneric (node:net:966:11)\n    at Socket._write (node:net:978:8)\n    at writeOrBuffer (node:internal/streams/writable:570:12)\n    at _write (node:internal/streams/writable:499:10)\n    at Writable.write (node:internal/streams/writable:508:10)\n    at $ (/Applications/Codex.app/Contents/Resources/app.asar/.vite/build/src-CH84TShJ.js:655:1744)\n    at Jj.broadcastClientStatus (/Applications/Codex.app/Contents/Resources/app.asar/.vite/build/src-CH84TShJ.js:655:6982)\n    at Jj.unregisterClient (/Applications/Codex.app/Contents/Resources/app.asar/.vite/build/src-CH84TShJ.js:655:6078)"
2026-06-02T23:24:51.901Z info [AppServerConnection] Stopping app-server transport connectionId=1 transport=stdio
2026-06-02T23:24:51.902Z info [AppServerConnection] app_server_connection.state_changed cause=stop_process connectionError=null currentConnectionId=null currentState=connected hasConnection=false hostId=local initialized=false initializeInFlight=false next=disconnected pendingClientRequests=0 pendingInternalRequests=0 previous=connected reconnectAttempt=0 reconnectTimerScheduled=false restartInFlight=false targetConnectionId=null targetReadyState=null transport=stdio

Successful comparison from the same app/workspace session:

/Users/seima/Library/Logs/com.openai.codex/2026/06/03/codex-desktop-64b54539-5a8d-4b4a-9fa1-a7de61d4874a-8318-t0-i1-045733-0.log

2026-06-03T10:32:38.761Z info [AppServerConnection] response_routed broadcastFallback=false conversationId=019e8d00-6e7c-7202-858e-4a487f06ba66 durationMs=2 errorCode=null hadInternalHandler=false hadPending=true method=thread/compact/start originWebcontentsId=1 requestId=29309921-4b2f-45fe-9d26-add0cabb224b targetDestroyed=false
2026-06-03T10:42:36.246Z info [AppServerConnection] response_routed broadcastFallback=false conversationId=019e8d00-6e7c-7202-858e-4a487f06ba66 durationMs=5 errorCode=null hadInternalHandler=false hadPending=true method=turn/start originWebcontentsId=1 requestId=f4c8d6c5-aa43-4524-8b7a-1b849c383929 targetDestroyed=false

I checked that successful log for EPIPE, Stopping app-server transport, browser use route window missing, and route 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/compact timeout class, but the local evidence points to Desktop route/window ownership or app-server transport lifecycle being part of the failure mode on macOS.

I can corroborate this class of failure on Windows Codex Desktop with current local evidence from long-running /goal sessions.

Environment observed locally:

Codex Desktop originator: Codex Desktop
Bundled runtime: codex-cli 0.136.0-alpha.2
Platform: Windows 11 x64
Auth: ChatGPT auth
Model: gpt-5.5, xhigh reasoning
Config loaded: ~/.codex/config.toml
Doctor: auth/websocket/provider reachable; rollout DB parity warning only

What makes this look like more than ordinary summarization loss:

• Multiple active /goal threads have hundreds of thread_goal_updated events in their rollout JSONL.
• One long /goal thread shows an explicit compaction boundary:

2026-06-09T23:47:02.913Z  type=compacted
2026-06-09T23:47:02.944Z  payload.type=context_compacted

• Other active goal threads do not show a clean explicit compact marker in the local tail, but later token_count events look corrupted/saturated rather than merely high:

thread A, 2026-06-10T01:53:03Z: model_context_window=475000, input_tokens=0, total_tokens=475000
thread A, 2026-06-10T01:53:25Z: model_context_window=475000, input_tokens=0, total_tokens=475000
thread B, 2026-06-10T01:04:17Z: model_context_window=475000, input_tokens=0, total_tokens=475000
thread B, 2026-06-10T01:04:28Z: model_context_window=475000, input_tokens=0, total_tokens=475000

That pattern appears after long /goal execution 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:

• Auto-compaction in /goal mode can leave a thread unable to keep progressing reliably.
• The user reports the same family of failure when controlling Codex from mobile: auto-compaction from the mobile/remote-control surface can break the thread rather than compacting and continuing. This overlaps with the mobile-specific reports such as #22890, but the goal-mode state aspect seems important here too.
• Raising the configured context window reduces how soon this happens, but does not fix the underlying failure mode.

Expected behavior:

• If auto-compaction succeeds, the active goal objective, current task pointer, pending next action, and enough recent tool/file state should survive and the goal should continue.
• If remote compaction fails or cannot safely compact the thread, Codex should surface a recoverable error with a retry/local-fallback/checkpoint option instead of leaving the thread in a broken or saturated state.
• /status or 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 on 0.136.0-alpha.2 with fresh Windows local rollout evidence.

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.