Codex doesnt auto compact its context with gpt 5.5 xhigh

From a quick read of the compaction path, the symptom "auto-compact starts but never reaches the end" lines up with two likely failure modes — would be useful for the team to disambiguate by rollout id (019e1c4e-d8ce-7292-b32a-e9b0080a5be1):

1. Remote compact call hangs / disconnects mid-stream. codex-rs/core/src/compact_remote.rs::run_remote_compact_task_inner_impl issues compact_conversation_history(...) against the compact endpoint and awaits the full reply before replace_compacted_history runs. If that call drops mid-stream (SSE disconnect, transient 5xx swallowed by retry, slow server), the UI stays in the "compacting…" state because emit_turn_item_completed is only reached on Ok(...). There are several recent reports of "Error running remote compact task: stream disconnected before completion" against the same endpoint (e.g. #22449, #22348, #22107) — gpt 5.5 xhigh would be more sensitive to this since its compact summaries are typically larger.

1. Inline compact retry loop on ContextWindowExceeded. If the same provider lands the user on the inline (non-remote) path for some reason — or the remote path fails over — codex-rs/core/src/compact.rs::run_compact_task_inner_impl removes the oldest history item and retries on every ContextWindowExceeded, with retries = 0 reset each time. When the post-trim prompt still overflows on a very large session, this loop walks history down to turn_input_len == 1 before finally erroring out. That isn't strictly infinite, but on a multi-MB context it can take many seconds of "compacting…" UI with no externally visible progress.

Quick diagnostic that would narrow this down without a full repro: when it gets stuck, does the TUI ever surface "Error running remote compact task" (failure mode 1) or does it stay quiet indefinitely until the user sends another message (failure mode 2 / 1 with a very long stream)?

If it's mode 1, the fix probably lives in compact-endpoint retry/timeout handling rather than the model. If it's mode 2, the inline retry loop could emit a progress event per history trim so the user sees forward progress instead of a frozen state.

(For context: I've been digging into this area because of #7808 / context-window mid-turn recovery — happy to help reproduce or surface more data if useful.)

Following up because this looks closely related to #7808 and the earlier overflow auto-compaction attempt in #22141 / revert #22170.

I have a focused local patch that handles the mid-turn ContextWindowExceeded case by running one recovery compaction and retrying the turn from the outer run_turn loop. It also addresses the review concerns from #22141:

• keeps the latest user message untruncated during recovery compaction,
• rebuilds tool routing after compaction,
• recomputes hook input from the recovered request,
• preserves multimodal user content through compaction,
• adds unit + integration coverage for local and remote compaction recovery.

I do not want to send an unsolicited PR against the contribution policy. Would the Codex team be open to inviting a PR for this recovery path, or would you prefer to keep the patch details in the issue so the team can implement internally?

Happy to adapt the shape if there is a preferred direction.

I just ran into this in codex-cli 0.130.0, right after I wrote a really long prompt.

<img width="928" height="100" alt="Image" src="https://github.com/user-attachments/assets/ad907994-e125-4a9d-8e00-e05fafbccf51" />

And thanks to #7808 I can't resume.

Uploaded feedback about multiple chats today using MacOS Codex -> Submit feedback. Blocking issue

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 compacted
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

This has been happening for many weeks now! GPT 5.5 xhigh. Auto-compacting an errors all the time, seemingly because it doesn't have enough context left to autocompact without an error.

I am seeing the same class of failure repeatedly on macOS/Codex Desktop, with gpt-5.5 and reasoning_effort=xhigh.

Environment:

• Codex Desktop: 26.602.30954 (CFBundleVersion=3575)
• Bundled/CLI runtime: codex-cli 0.137.0-alpha.4
• macOS: 26.5.1 (25F80)
• Auth mode in logs: ChatGPT
• Model: gpt-5.5
• Reasoning effort: xhigh

User-visible error:

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

This is now happening across multiple long threads. Once a thread approaches the context limit and Codex tries to run the remote pre-sampling compact, the compact request fails and the thread effectively cannot continue.

Sanitized local evidence from logs_2.sqlite across recent failures:

2026-06-05 18:24:24
last_api_response_total_tokens=227188
all_history_items_model_visible_bytes=974237
estimated_tokens_of_items_added_since_last_successful_api_response=12862
estimated_bytes_of_items_added_since_last_successful_api_response=51439
model_context_window_tokens=Some(258400)
failing_compaction_request_model_visible_bytes=995711
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

2026-06-05 18:08:43
last_api_response_total_tokens=224050
all_history_items_model_visible_bytes=878783
estimated_tokens_of_items_added_since_last_successful_api_response=1215
estimated_bytes_of_items_added_since_last_successful_api_response=4858
model_context_window_tokens=Some(258400)
failing_compaction_request_model_visible_bytes=900257
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

2026-06-05 13:39:32
last_api_response_total_tokens=219493
all_history_items_model_visible_bytes=946740
estimated_tokens_of_items_added_since_last_successful_api_response=315
estimated_bytes_of_items_added_since_last_successful_api_response=1257
model_context_window_tokens=Some(258400)
failing_compaction_request_model_visible_bytes=968214
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

2026-05-28 21:06:02
last_api_response_total_tokens=227609
all_history_items_model_visible_bytes=978149
estimated_tokens_of_items_added_since_last_successful_api_response=787
estimated_bytes_of_items_added_since_last_successful_api_response=3148
model_context_window_tokens=Some(258400)
failing_compaction_request_model_visible_bytes=999623
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

Additional observation: basic reachability to the endpoint host appears fine from the same machine. A direct unauthenticated GET probe to https://chatgpt.com/backend-api/codex/responses/compact returns 405 Method Not Allowed quickly, so this does not look like a complete local network/DNS/TLS block. The failure appears specific to the long-running POST /responses/compact streaming path near the context limit.

Privacy note: I am not posting raw transcripts, local paths, or project contents publicly. I can submit private feedback with session/log upload separately if helpful.

I submitted in-app Codex feedback with current session logs included.

Feedback ID: 019e98bb-4410-7623-82c5-fc91d8757210

This looks related to this issue, but it may be a broader transport/streaming failure class rather than a compaction-only bug. The same environment is seeing both variants:

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

and the newer user-visible non-compact/regular stream variant:

stream disconnected before completion: Transport error: network error: error decoding response body

Environment remains:

• Codex Desktop: 26.602.30954, bundle build 3575
• Codex CLI: 0.137.0-alpha.4
• macOS: 26.5.1 build 25F80
• Architecture: arm64
• Model: gpt-5.5
• Reasoning effort: xhigh

My current hypothesis is that compact is the most sensitive path because it involves a large/long-running request near context pressure, but the error decoding response body variant suggests the root cause may sit in the shared response streaming/transport layer. Please correlate the uploaded feedback logs with this issue if useful.

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.