Repository navigation
Local Windows and remote SSH tasks fail during compaction: response body decoding / SSE idle timeout #45216
Description
Environment
- Codex Desktop on Windows, affecting both local tasks and tasks on a remote SSH host.
- Remote Codex CLI version verified during troubleshooting: 0.154.0.
- Authentication: ChatGPT subscription.
- The exact Windows Desktop build and its local runtime version have not been independently captured for this report.
What happened?
Multiple existing Codex tasks fail during automatic context compaction and cannot continue. This was reproduced in remote SSH tasks. I also encounter the error in a local Windows Desktop task, so the reported scope is not limited to remote SSH.
Observed error messages include:
Error running remote compact task: stream disconnected before completion:
Transport error: network error: error decoding response body
stream disconnected before completion: idle timeout waiting for SSE
stream disconnected before completion:
IO error: cannot decrypt peer's message
The local occurrence and the additional SSE timeout are user-observed symptoms; the remote diagnostics below do not independently establish the local failure stage or that all three messages have the same cause.
Reproduction and impact
- Continue an existing Codex Desktop task until automatic context compaction is required.
- Send another message.
- Compaction fails with a stream/transport error.
- Retrying the affected task triggers compaction again and can fail before any normal task work begins.
During the remote tests, failed no-op turns lasted approximately 208, 230, 251, and 240 seconds. These are whole-turn durations, not independently measured durations of a single network request or a proven proxy timeout.
Expected behavior: compaction completes and the task continues, or Codex provides a safe recovery path that preserves completed work and conversation context.
Actual behavior: repeated compaction failures prevent continuation of affected tasks. Other tasks can still be used to inspect the failures.
Remote diagnostics already performed
- Configuration loads successfully;
remote_compaction_v2was restored to its default value,true. - The Responses WebSocket handshake succeeded with HTTP 101. This verifies connection establishment, not long-stream reliability.
- Restarting the remote app server did not resolve the compaction failure.
- The decode failure recurred with multiple proxy routes and TCP/gRPC transports.
- Direct access to the authenticated ChatGPT request returned HTTP 403, so a successful direct-versus-proxy comparison was not possible.
- Experimental proxy routing changes were reverted.
These tests do not isolate the cause to a proxy, the client, the model, or the OpenAI backend. The additional local Windows occurrence also needs investigation.
Separate legacy endpoint error during troubleshooting
Setting remote_compaction_v2 = false produced a different error:
Error running remote compact task: unexpected status 404 Not Found
URL: https://chatgpt.com/backend-api/codex/responses/compact
That override has been removed. After restarting with the default enabled, the tested task stopped returning this 404 but continued failing with the response-body decoding error.
Diagnostic identifiers
- Codex Desktop feedback ID:
01a099ef-7998-7181-9482-c4065a287da2 - Example affected remote thread ID:
01a099ce-6369-74b0-85af-ca74ebb30a1e - The following request identifiers are specifically from the separate legacy 404 attempts, not from the SSE/decode failures:
- Request ID:
3079b92a-a1ec-4d73-8367-06313b9e98fc; CF-Ray:a3a5dbfef8981ea1-AMS - Request ID:
293df0ca-9d17-43c6-89d7-c3e4aa7c0b4e; CF-Ray:a3a5dc62ac2e1add-AMS
- Request ID:
Related reports
- Codex Desktop on macOS: automatic context compaction fails every time with “error decoding response body” #38969 — automatic context compaction fails with
error decoding response body. - Remote compaction and long-running tasks consistently fail across Codex Desktop/Work, VS Code, and WSL CLI #38434 — remote compaction and long-running task failures across clients.
- ChatGPT Working Astra Compaction takes 5x longer than before Astra update with Sol #43038 — compaction hangs, including reports of
idle timeout waiting for SSE. - HTTP SSE response.failed waits for EOF and can be replaced by idle timeout (0.153.4; tested fix) #43140 — a reported SSE terminal-error handling defect that can mask the original error as an idle timeout.
- High-reasoning Responses WebSocket idle timeout is a false dead-stream (model resumed after 8.5 min of no text frames) #39771 — reported false idle timeouts during high-reasoning WebSocket generation.
- Windows Desktop 26.901 / core 0.153.0:
remote_compaction_v2 = falsenow routes to retired/responses/compact(404) and kills the thread; earlier desktop builds ignored the flag #42468 —remote_compaction_v2 = falseand the legacy compaction endpoint 404.
These are related symptoms and diagnostic leads, not a claim of identical root causes or released fixes.
Could maintainers investigate the affected compaction requests, advise on recovery of existing tasks, and identify whether this report should be consolidated with one of the issues above?
Activity
github-actions commentedon Sep 13, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
[-]Remote SSH threads become unusable when automatic context compaction fails[/-][+]Local Windows and remote SSH tasks fail during compaction: response body decoding / SSE idle timeout[/+]SouthWinter commentedon Sep 13, 2026
Independent Linux remote-SSH reproduction: both WebSocket and HTTP/SSE compaction time out
Adding a separate Linux incident because it overlaps this report closely and provides a same-machine, two-thread comparison. This does not establish that every transport error in this issue has one root cause.
Environment
codex-cli 0.153.4gpt-6-astra, reasoning effortmediumremote_compaction_v2=trueObserved behavior
Two independent tasks on the same remote host entered automatic compaction and could not continue. The newer task was genuinely fresh rather than a fork or imported transcript.
The newer task reached
run_auto_compact{reason=ContextLimit phase=MidTurn}, then followed this sequence:falling back to HTTP.A fresh task therefore did not avoid the failure once one tool-heavy turn crossed the context threshold.
Historical comparison
The older task had completed 34 automatic context compactions successfully under the same installation. The last successful compaction was persisted at
2026-09-13T11:32:47Z.That final success already showed degradation: two earlier SSE attempts hit idle timeouts, while a later attempt eventually completed after roughly 20 minutes for the overall compaction/retry sequence. Subsequent compactions failed.
This suggests that merely reaching the configured token threshold is not sufficient to explain the failure. The threshold had been crossed and compacted successfully many times before.
Approximate incident window:
2026-09-13 11:10-14:00 UTC.Request and connectivity observations
codex doctorreported:These checks establish successful setup and connection establishment; they do not rule out a long-stream proxy problem or identify a server-side cause.
Correlation identifiers
Shared with the users explicit authorization:
01a0918c-fed7-7623-b9ed-7342111a6b9601a09ad1-94ae-7120-8e8d-d9f74bcf5b6201a09b16-f0d4-7cb0-98de-c749fded552eThe built-in
/feedbackreport was submitted without full session logs because the conversations contain unpublished research material. No project name, prompts, local paths, credentials, raw transcripts, or research content are included here.This incident also resembles the WebSocket retry amplification documented in #42896, with the additional observation that HTTP/SSE did not recover either. Please correlate the identifiers above with remote compaction latency and emitted application-level stream events if those traces are available.
Nobodyrookie commentedon Sep 23, 2026
Windows Desktop follow-up (2026-09-23): compaction failure and bounded recovery test
A long-running GPT-6 Astra task on Codex CLI 0.156.1 was blocked by automatic remote compaction. Its history shows 13 successful compactions, most recently at 2026-09-23 06:20 UTC. The last token-count event reported 243,295 input tokens against a 258,400-token effective window. The next mid-turn compaction and a subsequent pre-turn compaction both failed after retries with
stream disconnected before completion: Transport error: network error: error decoding response body. The compact request was approximately 2.33 MB before zstd compression and 1.17 MB after compression. The HTTP attempts received status 200 with chunked transfer encoding before the stream failed. The goal was then marked blocked. Existing workspace edits remained on disk.A separate network symptom occurred later on the same Windows machine: even a minimal fresh CLI request received a Cloudflare 403 at
/backend-api/codex/models?client_version=0.156.1on one proxy exit. After switching the proxy route, an identical minimal request completed. This establishes a route-specific connectivity problem at that later time, but does not establish that the earlier 200-then-disconnect compaction failures had the same cause.As a reversible recovery experiment,
model_context_window = 400000was added to the user config. A fresh CLI session reported an effective 380,000-token window and completed the minimal request. The blocked original task has not yet been successfully resumed or verified under this setting. Please advise on a supported way to recover an existing blocked goal without losing its completed work, and whether backend traces can distinguish proxy stream loss from compaction service failure. No project content, credentials, or raw logs are included.ddddyyyy commentedon Oct 4, 2026
I have an additional Windows Desktop observation with a model-switch recovery. This does not establish that the model itself is the root cause.
Environment
OpenAI.Codex_26.930.3930.0_x64__2p2nqsd0c76g0. This is the verified package version, not a value copied from the About dialog.0.160.0.Observed sequence
gpt-6.1-sol, mediumgpt-6.1-sol, mediumgpt-6.1-sol, highgpt-6-astraAll three failed tasks ended with:
After successful compaction, I switched back to
gpt-6.1-soland continued working in the same thread normally.Diagnostic evidence
total_usage_tokens=245842, against a threshold of244800and an effective context limit of258400. The log recordedfull_context_window_limit_reached=false.https://chatgpt.com/backend-api/codex/responses, then failed while consuming the response stream.compactedrecord, a completedContextCompactionitem, andtask_completewithout an error.Identifiers for investigation:
01a10105-fa4f-7331-af2f-40dbcb936d85.efb1523a-6924-4a42-96ee-4703f8766395.3dd4e820-d8b6-4a18-b4c5-670837f00e09.Reproduction boundary and expected behavior
These are repeated observations in one existing thread, not a minimal reproduction or a controlled comparison of models. I have not independently reproduced this in a fresh thread or ruled out transient network/backend behavior.
The observed steps were: continue a long image/tool-heavy thread until automatic compaction triggers; retry manually with Sol at medium and high; switch to Astra and compact the same thread; switch back to Sol and continue.
Expected: compaction completes and preserves task continuity, or the app provides a recoverable failure with actionable diagnostics.
Could maintainers inspect the failed and successful requests to determine whether this belongs to the existing transport/compaction issue or a separate model-dependent compaction path?
Authentication headers, cookies, local usernames/paths and full conversation contents are omitted.
ViktorVr1981 commentedon Oct 11, 2026
Additional independent user report from a ChatGPT Pro subscriber on Windows 10 Pro 22H2, with recurring failures since 2026-10-03 and still ongoing 2026-10-11. The reporter has captures from multiple distinct Codex/Work threads, including both:
One recovery thread shows the decode error three times in succession; a separate thread shows repeated SSE idle timeouts. The reporter also describes a failure in a new thread on Oct 7 (timeline reported by user; screenshot calendar date not embedded). Longer tasks are blocked; small, bounded tasks sometimes remain usable.
Detailed independent report (environment, limitations, timeline, and maintainer questions): #53111.
We are seeking a supported way to recover existing long-running conversations safely, and a method to provide request/session IDs privately without exposing user project data. No specific root cause is asserted.