Codex Desktop GPT-5.5 remote compaction fails and leaves thread unusable

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

• #19538
• #19441
• #19329
• #18450
• #19255

Powered by Codex Action

Same for me since week and they still didnt fix https://github.com/openai/codex/issues/17928

Wow!!! Exactly what happen to me, the fricking thread got auto compacted, then model start to to repeat itself without the correct context

Got this problem too. started today

Same problem here.

<img width="464" height="77" alt="Image" src="https://github.com/user-attachments/assets/6dfb00e4-d5da-4ac1-b887-c5ee6f2a6df1" />

<img width="1053" height="292" alt="Image" src="https://github.com/user-attachments/assets/9fbbe059-f920-4712-abf8-89ff5d4e9629" />
Same problem

I'm having this problem for 2 days now, literally compaction never works anymore 🥀

So, I was running into the same problem, and though it had to do with a VPN or network configuration. I tried multiple different solutions, including the increasing of time from idle time and the rewq in timeout to something like 15 minutes.
(I am running codex in a windows, linux, and mac via codex app, and in all 3 of them I was facing the same problem, in my dorms, faculty internet, and cellular network)

What seemed to happened is that it always cuts out after 5m01s so, I found it strange, tried to clone the codex repo and all that.

After trying some more things.

I found a comment saying that changing the model provider from OpenAI to something else might work

'''
model = "gpt-5.5"
model_provider = "openai-local-compact"
model_reasoning_effort = "high"
model_auto_compact_token_limit = 233000
personality = "pragmatic"
approval_policy = "never"
sandbox_mode = "danger-full-access"
plan_mode_reasoning_effort = "xhigh"

[model_providers.openai-local-compact]
name = "OpenAI Local Compact"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = true
stream_idle_timeout_ms = 900000
'''

So, I resumed around 5 sessions without this first, tried compacting a few times, and it didn't worked.
And then resumed the sessions and tried compacting again, with this workaround, and in less than 10 seconds the compact was working. (Only downside is I can't see the previous codex history with the resume command, or in the app history, as it's model provider filtered)

Right now I am trying in some long running tasks that previously failed, and checking if this is a good workaround for the time being, and so far it seems it works, and no major issues, will try to have something running for around 5-15 hours to confirm.

So, actually the model provider is not a real provider, but since codex doesn't detect it as OpenAI. then it fallbacks from responses/compact to a normal request for the summarization.

What my Codex says is the following:

----
The main issue, #14559, is still open and labeled bug + context, which means it is tracked as a compaction/context problem: https://github.com/openai/codex/issues/14559

• A later issue, #16281, was closed as a duplicate of #14559, so reports are being consolidated rather than ignored: https://github.com/openai/codex/issues/16281
• A newer issue, #19400, specifically calls out the same architectural gap we found: Codex decides remote compaction by provider, not by whether the active model actually works with /responses/compact. It proposes fallback/local compact/config options:

https://github.com/openai/codex/issues/19400

• I do not see a public assignee, linked PR, milestone, or maintainer comment promising a fix. So: likely known, not publicly confirmed as fixed.

Why avoiding the compact server works:

OpenAI’s own Codex architecture writeup says Codex normally uses a special /responses/compact endpoint for compaction. That endpoint returns a compacted history, including an opaque type=compaction item, and Codex uses it automatically when the compact limit is exceeded: https://openai.com/index/unrolling-the-codex-agent-loop/

Our workaround changes this decision. Codex’s local code enables remote compaction when the provider name is exactly OpenAI or Azure-like. By naming the custom provider OpenAI Local Compact, it still uses OpenAI auth and normal Responses/WebSocket calls, but it no longer matches the “use remote compact endpoint” predicate.

So compaction changes from: chatgpt.com/backend-api/codex/responses/compact
to the older/local strategy: normal Responses request that summarizes/compacts history

That works because your normal Responses path is healthy, while the special compact endpoint is the thing timing out/failing. It is not magic; it just routes around the brittle endpoint.

it is still doing real compaction in the practical sense: it replaces the live conversation history with a shorter compacted history and recomputes token usage.

What changes with openai-local-compact is only which compaction mechanism is used:

• OpenAI provider name -> uses remote /responses/compact.
• OpenAI Local Compact provider name -> skips remote compact and uses local compaction through the normal Responses/WebSocket path.

The local path still does this:

1. Sends the current history plus the compact prompt to the model.
2. Waits for the model’s compact summary response.
3. Builds a new shorter history from recent user messages plus the summary.
4. Calls replace_compacted_history(...).
5. Recomputes token usage.

Relevant code:

• codex-rs/core/src/compact.rs:152 runs local compaction.
• codex-rs/core/src/compact.rs:279 creates the CompactedItem.
• codex-rs/core/src/compact.rs:285 installs the replacement history.
• codex-rs/core/src/compact.rs:466 builds the shortened history.

So: yes, it compacts. It just does not use OpenAI’s special server-side compact endpoint that can return opaque type=compaction items. It uses a normal model-generated summary as the replacement history instead.
----

tldr;
In the code, remote compaction is enabled only when: provider.is_openai() || is_azure_responses_provider(...) and is_openai() is literally: self.name == "OpenAI" if it's not then Codex selects the normal compaction path instead of calling /responses/compact

I think this is just a TEMPORARY workaround, but probably OpenAI team is already investigating this more in depth, they are great at fixing issues faced by the community.

• An update I have is I'm running a couple of tasks now for maybe 1 hour in the Ubuntu pc (2 compactions), and around 30 minutes in the Mac (2 compactions), and they seem to be working all right, while previously this same tasks were failing after a single compaction

Hi Codex team — could you clarify whether this GPT-5.5 Desktop remote compaction failure is being tracked under this issue, #14559, #19400, or another internal tracker?

There seem to be several related compaction threads:

• #14559: general stream disconnected before completion for /codex/responses/compact
• #19400: gpt-5.5 appears to be sent directly to /responses/compact, which may not support it reliably
• #19771: merged fix for the tools.defer_loading requires tools.tool_search compaction payload issue

For users, the practical impact is still severe: once auto-compaction fails, the current Desktop thread can become unusable and long-running GPT-5.5 sessions are risky.

A short status update would help a lot: is this considered fixed by #19771, still pending a release, a separate /responses/compact backend issue, or something that should be consolidated into #14559/#19400? Thanks!

Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
All day today on every session requiring compaction.

Additional report for the compaction-specific failure:

The user reports that this is not a proxy issue. Their earlier reconnect / retry problem has been resolved, but remote context compaction still frequently fails after running for a long time.

Error shown:

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

Observed behavior:

• Normal request reconnect behavior is no longer the problem.
• The failure happens specifically during automatic context compression / remote compaction.
• The compact task appears to run for a long time before failing, which looks like a timeout / long-running request reliability issue.
• The user asked whether the compaction timeout/deadline can be configured or increased.

Expected behavior:

• Remote compaction should either complete successfully, retry gracefully, or provide a recovery path that does not leave the thread unusable.
• If there is a fixed timeout or stream deadline for /backend-api/codex/responses/compact, it would help to document it or expose a way to tune/retry it.

This seems aligned with this issue's core problem: compaction/autocompaction failure after long-running context accumulation, independent of proxy configuration.

I get the same problem in EVERY thread now. I am almost unable to complete tasks. It can happen as soon as the first compaction.
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

GPT5.5
Codex Desktop latest update

Thread ID 019dc54d-4fe7-7f12-a99c-678425fc5aee.

No VPN.

Additional current reproduction after updating to the latest Codex:

codex-cli 0.128.0
@openai/codex@0.128.0
Codex Desktop log app.version: 0.128.0-alpha.1
Platform: macOS
Auth mode: ChatGPT
Model: gpt-5.5
Endpoint: /backend-api/codex/responses/compact

The user updated from 0.125.0 to 0.128.0, but automatic context compaction still fails in the same way. Local logs show the compact request is still routed through the remote compact endpoint and fails after about 60 seconds:

event.name="codex.api_request"
duration_ms=60431
attempt=2
endpoint="/responses/compact"
auth.header_attached=true
auth.header_name="authorization"
auth.retry_after_unauthorized=false
auth.env_openai_api_key_present=false
auth.env_codex_api_key_present=false
auth.env_codex_api_key_enabled=false
auth.env_refresh_token_url_override_present=false
auth_mode="Chatgpt"
originator=Codex_Desktop
model=gpt-5.5
slug=gpt-5.5
error.message="error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)"

Immediately after that, the log contains:

Request failed method=POST url=https://chatgpt.com/backend-api/codex/responses/compact error=error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
shouldn't retry!

This appears to still be reproducible on the latest public npm package, so upgrading alone does not resolve it.

One useful detail: normal Responses/WebSocket requests with gpt-5.5 continue to work in the same environment; the failure is specific to the remote compaction path.

Adding one more current Desktop reproduction with local log evidence.

Environment from logs:

Codex Desktop app-server: 0.128.0-alpha.1
Runtime bundle selected: 26.505.10851
Platform: macOS / Darwin
Auth mode: ChatGPT account
Conversation/thread id: 019ddd9c-9371-7942-8e70-48b596f3e5b2

What happened:

• The original thread entered context compaction and stayed stuck in the UI for 12+ minutes (Skracanie kontekstu / context shortening).
• The user tried to continue typing in the same thread, but the app could not submit/steer because the active turn was still the compact turn.
• The only practical recovery was to fork the thread to avoid losing the working context.

Relevant local log lines:

2026-05-06T06:45:24.014Z method=thread/compact/start conversationId=019ddd9c-9371-7942-8e70-48b596f3e5b2 errorCode=null
2026-05-06T06:45:51.019Z method=turn/steer error={"message":"cannot steer a compact turn","codexErrorInfo":{"activeTurnNotSteerable":{"turnKind":"compact"}}}
2026-05-06T06:52:36.919Z method=turn/steer error={"message":"cannot steer a compact turn","codexErrorInfo":{"activeTurnNotSteerable":{"turnKind":"compact"}}}
2026-05-06T06:52:50.623Z method=thread/fork conversationId=019ddd9c-9371-7942-8e70-48b596f3e5b2 errorCode=null

So this looks like two related problems:

1. The compact turn can remain active/stuck long enough that the thread is effectively unusable.
2. The current product-level recovery path is manual fork/new thread, which is why #21288 would be valuable as a first-class recovery UX.

I am adding this here rather than opening a new issue because it appears to be the same failure family as the reports above.

+1 on macOS, with two new data points beyond the OP.

Environment

• Codex CLI (not Desktop) on macOS
• Model: gpt-5.5, model_reasoning_effort = "xhigh"
• Auth: ChatGPT account, Pro ($200) tier
• Effective context ceiling observed: ~258K

Verbatim error (auto-compact path):

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)

New info beyond the OP:

1. Manual /compact also fails the same way after the auto-compact failure. So this isn't only an auto-trigger problem — once the thread is in this state, the user has no recovery path inside the session. Same endpoint, same disconnect.
2. The model_auto_compact_token_limit = 200000 workaround does not prevent the unrecoverable state — it just delays which turn trips it. Once compact fires, success or unrecoverable is binary.

Pro-tier ask (cross-ref #19464): GPT-5.5 ships with 1M tokens at the API per OpenAI's launch notes. The 272K Codex cap means Pro users hit /responses/compact constantly — and when it disconnects, the session is gone. Pro is paid headroom; please make 1M an opt-in for Pro/Team, even with a higher usage multiplier (the model already supports it, this is purely a Codex-side cap).

The acute fix is making /responses/compact reliable for gpt-5.5 payloads (see also #19400 — endpoint may not fully accept the gpt-5.5 slug) and keeping the thread usable when it doesn't.

I will note, it works when I disable my VPN 🥀

Also seeing this on Codex Desktop for macOS.

Thread ID: 019e0390-d329-74c3-b8ab-13a32d339c9b
Codex App: 26.429.61741 (2429)
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 still happening today (2026-05-07).

I’m seeing the same failure on a newer Codex Desktop build, with repeated remote compaction failures near the context limit.

Environment:

• Product: Codex Desktop for macOS
• Desktop app: 26.506.31421 (2620)
• Logged app.version in request: 0.130.0-alpha.5
• Model: gpt-5.5
• Auth mode: ChatGPT
• Endpoint: POST https://chatgpt.com/backend-api/codex/responses/compact
• Observed: 2026-05-11

Key redacted log evidence:

• target: codex_core::compact_remote
• error: remote compaction failed
• compact_error: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
• last_api_response_total_tokens=236091
• model_context_window_tokens=Some(258400)
• all_history_items_model_visible_bytes=970057
• failing_compaction_request_model_visible_bytes=991531
• estimated_tokens_of_items_added_since_last_successful_api_response=5915
• request duration_ms is consistently around 60s, e.g. 60371 / 60386 / 60424
• attempts observed: 3 and 4
• local log has 19 codex_core::compact_remote ERROR entries

Behavior:
The thread gets close to the model context limit, auto compact starts, the /responses/compact request runs for about 60 seconds, then disconnects before completion. The thread is left effectively unusable because later turns keep hitting the failed compact path.

This does not look repo-specific. It looks like the remote compaction path either needs chunking, a longer deadline, better retry behavior, or a recovery path that lets the user continue from a summarized/new thread state.

I’ve redacted account/email fields from the logs.

Changing auto compact token limit in config to a smaller value seems to help.

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

I have had the same issue for a few weeks as well. However, for me it seems to happen consistently. I now have to use a workaround where I get Codex to keep a per-task journal so that I can get it to pick up where it left off in a fresh session by referring to the journal due to the consistent context compaction issue.

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.

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.

When will this issue be fixed in the release? It has seriously affected my work efficiency