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

Summary

Codex Desktop repeatedly fails during automatic remote context compaction after switching to GPT-5.5. Once this happens, the current thread becomes unusable and every later instruction fails, so the only practical recovery is to start a new thread.

Environment

Product: Codex Desktop
Model: GPT-5.5
Auth mode: ChatGPT account
Platform: macOS
Date observed: 2026-04-25
Subscription: Plus
Codex app version: 26.423.10653

Actual behavior

When the thread context usage grows above roughly 90%, Codex automatically starts context compaction. After waiting for a long time, it fails with:

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

After this error, the current conversation can no longer execute any further instructions. The thread appears stuck in a failed compact / pre-sampling state.

Expected behavior

When automatic context compaction is required, Codex should either:

complete the compaction successfully, or
fail gracefully and allow the current thread to continue, retry compaction, or recover without forcing the user to abandon the thread.

Reproduction pattern

Use Codex Desktop with GPT-5.5.
Work in a long-running thread until context usage is above about 90%.
Let Codex trigger automatic remote context compaction.
Wait for the compact request to run.
The request fails with stream disconnected before completion for https://chatgpt.com/backend-api/codex/responses/compact.
Try to send another instruction in the same thread.
The thread remains unusable.

Notes

This looks similar to existing remote compaction failures, but it became much more frequent after the GPT-5.5 update. My guess is that GPT-5.5 long-context sessions generate larger or heavier compaction requests, making the remote compact path more likely to hit a timeout or stream disconnect. The bigger issue is that the failed compact leaves the thread unrecoverable.

Impact

This is high impact for long-running coding tasks because it tends to happen after substantial work has accumulated in the thread. When it fails, the user loses the active working context and has to manually recover from files, git diff, or handoff notes in a new thread.

Suggested fix direction

Add retry / backoff for failed remote compact requests.
If compaction fails, keep the thread usable and surface a recovery action instead of leaving it stuck.
Consider exposing manual compact / handoff controls before the automatic threshold.
Check whether there is a fixed timeout around /backend-api/codex/responses/compact, especially if failures cluster around a consistent duration.

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

Powered by Codex Action

Same for me since week and they still didnt fix #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.

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: #14559

A later issue, Auto-compaction fails near context limit with "stream disconnected before completion" #16281, was closed as a duplicate of Error running remote compact task: stream disconnected before completion BUG #14559, so reports are being consolidated rather than ignored: Auto-compaction fails near context limit with "stream disconnected before completion" #16281
A newer issue, Remote compaction fails when using gpt-5.5 because /responses/compact does not appear to support the model #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:
Remote compaction fails when using gpt-5.5 because /responses/compact does not appear to support the model #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:

Sends the current history plus the compact prompt to the model.
Waits for the model’s compact summary response.
Builds a new shorter history from recent user messages plus the summary.
Calls replace_compacted_history(...).
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

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:

The compact turn can remain active/stuck long enough that the thread is effectively unusable.
The current product-level recovery path is manual fork/new thread, which is why Add a recovery option to start a new session from previous context after repeated compact failures #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:

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

@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

Navigation Menu

Repository navigation

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

Summary

Environment

Actual behavior

Expected behavior

Reproduction pattern

Notes

Impact

Suggested fix direction

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.

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Actual behavior

Expected behavior

Reproduction pattern

Notes

Impact

Suggested fix direction

Activity

github-actions commented on Apr 25, 2026

seeb1337 commented on Apr 25, 2026

Tomer96 commented on Apr 25, 2026

EricXiang400 commented on Apr 25, 2026

Gelurban commented on Apr 25, 2026

Loveishax commented on Apr 26, 2026

igreat commented on Apr 26, 2026

Cesar514 commented on Apr 26, 2026

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.

2 remaining items

zixuanjiang332 commented on May 3, 2026

shred686 commented on May 3, 2026

joelreymont commented on May 5, 2026

Rockhilly commented on May 6, 2026

pdurlej commented on May 6, 2026

LaFleurAdvertising commented on May 6, 2026

igreat commented on May 6, 2026

presidenzo commented on May 7, 2026

Rockhilly commented on May 11, 2026

Gusarich commented on May 11, 2026

yuweuii commented on May 15, 2026

ralfepoisson commented on May 17, 2026

etraut-openai commented on Jun 29, 2026

zzzzzzyang commented on Jul 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions