Codex Desktop: context compaction fails with remote compact stream disconnected

[bjmark]

Summary

Codex Desktop showed a context compaction failure while working in a local coding session.

Error message

Context compacted

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

Context

• Product: Codex Desktop app
• Platform: macOS
• Approximate app version observed from local process: 26.506.31421
• The error appeared during automatic context compaction in an active coding thread.

Expected behavior

Context compaction should complete successfully, or retry/recover without interrupting the thread.

Actual behavior

The UI displayed the compaction failure message above.

Screenshot

The screenshot attached by the reporter shows the same error text:

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

Notes

I do not have additional logs beyond the visible UI error at this time.

[github-actions]

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

• Error running remote compaction task #22031
• Context compact error #21343
• Compaction failure #20931
• Compaction/reconnect can drop live orchestration state after stream disconnect #21643

Powered by Codex Action

[hacksurvivor]

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.

[Rockhilly]

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.

[reliefeai]

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.

[yuweuii]

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

[snissn]

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

[snissn]

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