Windows Codex Desktop: gpt-5.5 xhigh remote compaction repeatedly disconnects near context limit

Resolved 💬 3 comments Opened Jun 1, 2026 by mikutea Closed Jun 29, 2026

What version of the Codex App are you using (From "About Codex" dialog)?

26.527.31326

What subscription do you have?

Pro subscription user

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (AMD64)

What issue are you seeing?

I am seeing repeated remote context compaction failures in Codex Desktop on Windows, mostly in long-running gpt-5.5 / Extra High sessions near the context limit.

This is severely impacting my work. I use Codex for long-running coding tasks, and when compaction fails the active thread often becomes difficult or impossible to continue. That interrupts ongoing implementation/debugging work and forces me to recover manually in a new thread.

Visible/local error:

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

Sanitized local log evidence from logs_2.sqlite:

ERROR codex_core::compact_remote
remote compaction failed
last_api_response_total_tokens=233258..274010
model_context_window_tokens=Some(258400)
failing_compaction_request_model_visible_bytes=815243..1082164
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

One larger failing case had about 2.9 MB of model-visible bytes. One earlier failure was:

compact_error=request timed out

In the inspected logs, this was concentrated on gpt-5.5:

  • 13 codex_core::compact_remote errors
  • 12 stream disconnects
  • 1 request timeout
  • Request telemetry shows many /responses/compact API errors/failures for gpt-5.5
  • As a comparison point, recent gpt-5.3-codex compact requests on the same machine completed successfully

The local session JSONL files parse successfully and archived sessions also contain successful context_compacted events, so this does not look like local transcript corruption. The machine has no WinHTTP proxy configured.

What steps can reproduce the bug?

  1. Use Codex Desktop on Windows with gpt-5.5 and Extra High reasoning.
  2. Work in a long-running coding thread with many tool calls until context approaches the model window.
  3. Allow automatic context compaction to run, or trigger compaction near the limit.
  4. Observe that remote compaction may fail with:
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
  1. The affected thread becomes difficult or impossible to continue unless starting a fresh thread.

In the local logs the failures occurred when last_api_response_total_tokens was about 233k-274k against model_context_window_tokens=Some(258400).

What is the expected behavior?

Remote compaction should complete, or fail gracefully with automatic retry/backoff and a recovery path that does not leave the thread unusable.

The app should also avoid sending compaction requests so close to the limit that service overhead or request latency makes them fragile.

Additional information

  • Auth mode: ChatGPT
  • I am a Pro subscription user, and this issue significantly affects my ability to rely on Codex for sustained engineering work
  • Internal app telemetry in logs also showed app.version=0.136.0-alpha.2
  • Related reports with similar failure: #25493, #21343, #19558, #18450, #17392, #19660
  • Privacy redaction: personal identifiers, local paths, work titles, and raw transcripts were removed
  • This report is intended to add Windows Desktop plus structured local-log evidence rather than only another screenshot of the same error

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗