Remote compaction intermittently fails with stream disconnected before completion

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

26.406.31014

What subscription do you have?

Pro

What platform is your computer?

No response

What issue are you seeing?

Summary

Codex for macOS intermittently fails when attempting remote compaction of a long thread. The visible error is:

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

This appears to happen during thread compaction near the context limit, not during ordinary local tool execution.

Environment

Codex app: 26.406.31014
Bundled Codex CLI: 0.119.0-alpha.11
Auth mode: ChatGPT
Model observed: gpt-5.4
Platform: macOS
Observed: April 9-10, 2026

Frequency

Observed at least 7 times in local logs during the above window.

Expected behavior

When a thread needs compaction, Codex should either:

complete compaction successfully, or
fail gracefully with a retry/recovery path that preserves usability

Actual behavior

Compaction fails with:

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

This interrupts the thread and forces the user to start over or move to a new thread.

Reproduction pattern

Not fully deterministic, but correlated with:

long-running threads
large accumulated tool output and/or long conversation history
automatic remote compaction near the context window

This does not appear to be caused by local repo code, shell commands, or a project-specific setup issue.

Sanitized evidence

Example sanitized log lines:

remote compaction failed ... last_api_response_total_tokens=230780 ... all_history_items_model_visible_bytes=893315 ... model_context_window_tokens=258400 ... failing_compaction_request_model_visible_bytes=908574 ... compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

remote compaction failed ... last_api_response_total_tokens=234880 ... all_history_items_model_visible_bytes=958429 ... model_context_window_tokens=258400 ... failing_compaction_request_model_visible_bytes=973688 ... compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

Notes

I observed at least one successful compact-related flow in a separate thread, so this looks intermittent rather than a permanent configuration issue.
The failure seems specific to the remote compaction request path.
All account IDs, thread IDs, session IDs, absolute paths, repository URLs, and raw transcripts have been removed.

What steps can reproduce the bug?

Uploaded thread: 019d79a8-88cf-7b32-a79d-97e9d303ea2d

What is the expected behavior?

No response

Additional information

No response

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

Compaction Errors in Codex app and CLI #17335
compact execution failed #16377
■ Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact) #16436
Auto-compaction fails near context limit with "stream disconnected before completion" #16281
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact) #15727

Powered by Codex Action

Close, Restart OS and Run. It should fix it - more detail here: #19255 (comment)

@RossRichardson

Sorry, what is the "root" ticket for this ?
Thanks @RossRichardson for the workaround (didn't tried it yet)

I am seeing the same remote compaction failure repeatedly on a newer CLI version.

Environment:

Codex CLI: codex-cli 0.125.0
Install path: npm global package @openai/codex
Platform: macOS 26.1, Darwin 25.1.0, arm64
Shell: zsh
Auth mode: ChatGPT/Codex CLI
Models observed while retrying: gpt-5.4-mini, gpt-5.4, gpt-5.2, gpt-5.5

Observed error:

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

Full visible sequence:

Model changed to gpt-5.4-mini medium

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

Model changed to gpt-5.4 medium

Conversation interrupted - tell the model what to do differently. Something went wrong? Hit `/feedback` to report the issue.

Model changed to gpt-5.2 medium

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

Model changed to gpt-5.5 xhigh

Impact:

Once compaction fails, the session becomes hard to continue safely because the conversation is near the context limit.
Switching models does not resolve it, which suggests the failure is in the remote compact endpoint/path rather than model-specific generation.
The practical workaround is manual handoff summarization into a new session, but that loses the intended automatic recovery path.

Expected behavior:

/compact should complete, or
fail with a retryable/recoverable path that does not interrupt the session, ideally preserving enough state for the user to continue or retry compaction.

This has happened more than once, not a one-off transient failure.

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

Adding a consolidated signal update here because this issue appears to be the primary tracker for remote compaction failures with stream disconnected before completion.

A recent refresh found several adjacent reports with the same broader failure mechanism: long-running sessions approach the context window, remote compaction starts or is attempted, and the session either fails to compact, hangs, becomes unusable, or loses reliable continuity. Examples I found while de-duplicating include #22309, #22107, #19660, #19558, #19441, #19400, #19386, #18829, #18363, #17802, #14684, #11954, #10986, #9800, and #9198. #18838 also appears to have already been closed as a duplicate of this issue.

The pattern looks broader than a single transient network disconnect. Sanitized local evidence and community reports suggest several useful failure classes:

stream disconnect during remote compact;
timeout or missing completion after compact starts;
compact request becoming too large near the context limit;
model-specific remote compact risk signals;
session unusable or repeated-error-loop states after compact failure;
resume/session continuity issues adjacent to the same long-context recovery path.

Expected upstream behavior, in my view, is not necessarily that every compact always succeeds. The more important recovery invariant is that a failed remote compact should not leave the active thread unrecoverable or stuck in a repeated failure loop.

Concrete improvements that would make reports and recovery much more actionable:

Preserve session usability after remote compact failure where possible, or provide a clear recovery path when continuing the same thread is impossible.
Expose structured compact lifecycle events: started, request sent, failed, completed, fallback attempted, session marked unrecoverable.
Classify failure modes separately instead of collapsing them into a generic compact failure: stream disconnect, timeout/missing completion, context length exceeded, endpoint/model incompatibility, backend high demand, invalid history/client post-processing.
Consider model-aware remote compact fallback or safer retry behavior, especially after the same compact path has already failed for the session.

This comment intentionally avoids raw logs, local absolute paths, account IDs, thread IDs, session IDs, and full transcripts.

I am seeing the same issue in the Codex VS Code extension.

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

It happens for both:

manual compaction
automatic compaction when the thread becomes long

This has been recurring for me for more than 20 days.

Observed local log dates:

2026-05-01
2026-05-02
2026-05-12
2026-05-13
2026-05-17
2026-05-21

Relevant local logs show:
target=codex_core::compact_remote

Examples:

2026-05-21:
last_api_response_total_tokens=216558
failing_compaction_request_model_visible_bytes=947276
2026-05-17:
last_api_response_total_tokens=221908
failing_compaction_request_model_visible_bytes=995111

Environment:

Codex used through VS Code extension
VS Code on Windows
Workspace opened in WSL
Remote extension installed in WSL:
openai.chatgpt-26.513.21555-linux-x64
Local Codex CLI currently reports:
codex-cli 0.130.0

I also tried increasing:
stream_idle_timeout_ms = 900000

That setting was applied on 2026-05-08, but compaction failures continued afterward.

I updated Codex CLI and reproduced the issue again manually in Codex TUI.

Latest reproduction:

Date: 2026-05-22 11:55:11 Asia/Shanghai
Codex CLI version: 0.133.0
Trigger: manual /compact in Codex CLI
Log target: codex_core::compact_remote
Endpoint: /responses/compact
Error:
stream disconnected before completion:
error sending request for url
(https://chatgpt.com/backend-api/codex/responses/compact)

Relevant log details:

originator=codex-tui
app.version=0.133.0
attempt=4
duration_ms=33049
last_api_response_total_tokens=216558
failing_compaction_request_model_visible_bytes=947276

The compact task itself ran for about 168 seconds before failing.

Adding another current reproduction from Codex CLI with the same failure signature.

Environment:

Codex CLI: 0.133.0
Platform: Linux x86_64
Install: npm global package @openai/codex
Auth mode: ChatGPT
Model: gpt-5.5 with high reasoning
codex doctor: install/auth/state/websocket healthy, 13 ok, 0 fail
Websocket check: HTTP 101 Switching Protocols
Proxy env vars: none

Observed behavior:

Normal turns and tool execution continue to work.
Failure appears specifically when remote compaction is triggered near the context limit.
The thread becomes effectively unusable after the compaction failure, which is a serious regression for long-running technical/scientific sessions.

Repeated local log examples:

2026-05-19T21:25:13Z compact_remote failed
  last_api_response_total_tokens=236193
  failing_compaction_request_model_visible_bytes=830827
  compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

2026-05-21T00:26:13Z compact_remote failed
  last_api_response_total_tokens=224924
  failing_compaction_request_model_visible_bytes=905866
  compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

2026-05-21T19:24:27Z compact_remote failed
  last_api_response_total_tokens=234388
  failing_compaction_request_model_visible_bytes=846151
  compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

2026-05-22T05:47:20Z compact_remote failed
  last_api_response_total_tokens=229984
  failing_compaction_request_model_visible_bytes=875864
  compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

2026-05-22T05:54:10Z compact_remote failed again on the same thread
  last_api_response_total_tokens=229984
  failing_compaction_request_model_visible_bytes=875864
  compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

Notes:

This does not look like a general local install/auth failure; doctor and websocket checks pass.
It also does not behave like ordinary latency trouble; regular turns can keep working while compaction fails.
The failing payloads here are around 830-906 KB model-visible history and around 225k-236k prior response tokens.

Expected recovery behavior:

Remote compaction should be retried or resumed idempotently.
If remote compaction cannot complete, Codex should preserve the thread and provide a recoverable local/session handoff instead of breaking the working thread.
For long-running research work, manual checkpointing is not a viable substitute for reliable compaction because it adds substantial token and workflow overhead.

Adding another current macOS datapoint with local logs, since this is now happening constantly on long Codex Desktop threads across multiple repos/dev environments.

Environment:

Codex Desktop: 26.519.41501, build 3044
Bundled Codex CLI: 0.133.0-alpha.1
macOS: 26.5, build 25F71, x86_64
App signature/notarization: accepted, Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2), stapled ticket
Auth mode in compact request logs: ChatGPT; auth header attached
Model in failing examples: gpt-5.5, high or xhigh reasoning

Observed pattern:

Failures occur during remote compaction near the 258,400-token context window, not during repo-specific shell/tool work.
The same error appears across different repos and local/remote dev environments.
Recent local SQLite logs show repeated failures over May 26-28, 2026. Sanitized examples:

2026-05-28 08:55:10Z remote compaction failed model=gpt-5.5 reasoning=high last_api_response_total_tokens=215392 all_history_items_model_visible_bytes=890299 estimated_tokens_added_since_last_successful_api_response=20806 model_context_window_tokens=258400 failing_compaction_request_model_visible_bytes=911646 compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
2026-05-27 16:45:48Z remote compaction failed model=gpt-5.5 reasoning=high last_api_response_total_tokens=240136 all_history_items_model_visible_bytes=863506 estimated_tokens_added_since_last_successful_api_response=58 model_context_window_tokens=258400 failing_compaction_request_model_visible_bytes=884853 compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
2026-05-27 16:23:55Z remote compaction failed model=gpt-5.5 reasoning=xhigh last_api_response_total_tokens=227937 all_history_items_model_visible_bytes=785789 estimated_tokens_added_since_last_successful_api_response=129 model_context_window_tokens=258400 failing_compaction_request_model_visible_bytes=807136 compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

Request timing from trace-safe log lines:

/responses/compact failures are after multiple attempts; examples show attempt=4 with duration_ms around 62,936 ms and 74,191 ms.
Local direct unauthenticated POST probe to the compact endpoint reaches Cloudflare/OpenAI and returns expected HTTP 401 Unauthorized with an x-oai-request-id, so this does not look like local DNS/firewall inability to reach chatgpt.com.

I have not attached full logs because they include private prompt/thread content, but the sanitized numeric telemetry above is directly from ~/.codex/logs_2.sqlite. This looks like the same remote compact stream disconnect issue, currently reproducible on the latest installed macOS app line here.

Adding a current Linux CLI datapoint after updating to Codex CLI 0.135.0.

Environment:

Codex CLI: 0.135.0 via npm
Platform: Linux x86_64
Auth mode: ChatGPT
Model: gpt-5.5, xhigh reasoning
codex doctor: healthy; websocket check passes; no proxy env vars
codex features list: remote_compaction_v2 is under development false

Observed behavior:

The default compaction path still uses /responses/compact.
A remote compact attempt retried attempts 0 through 4.
Each attempt failed after roughly 60-61 seconds with:
error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
Final compact error:
stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

Final failure telemetry:

last_api_response_total_tokens=237419
all_history_items_model_visible_bytes=801190
failing_compaction_request_model_visible_bytes=822537
model_context_window_tokens=Some(258400)
estimated_tokens_of_items_added_since_last_successful_api_response=60

Why this may be useful:

This reproduction is after the merged v2 retry work, but the default feature state still appears to use the legacy compact endpoint.
The failure shape looks like a roughly 60-second request/stream cutoff on a near-limit compact payload, not a local auth/connectivity failure.
Since remote_compaction_v2=false, the v2 retry/fallback fixes may not cover this default path.

This comment intentionally omits account IDs, email addresses, local paths, thread IDs, raw logs, and transcript content.

Codex Desktop remote compaction failures on Windows

Summary

Codex Desktop repeatedly fails when automatic remote context compaction is triggered for long-running threads.

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 interrupts active work and can make long-running threads unusable.

Environment

Platform: Windows 11 Professional, x64
Codex Desktop package: 26.527.3686.0
Bundled Codex CLI: 0.135.0-alpha.1
Authentication mode: ChatGPT
Model provider: openai
Model: gpt-5.5
remote_compaction_v2: under development false

Reproduction pattern

Work in a long-running Codex Desktop thread until the context approaches the model window.
Allow automatic remote compaction to start.
The request to /backend-api/codex/responses/compact fails with stream disconnected before completion.
Retrying work in the affected thread triggers the same failure again.

Sanitized local evidence

The local Codex SQLite logs contain four codex_core::compact_remote failures on May 31, 2026:

2026-05-31T18:39:01Z
last_api_response_total_tokens=228794
all_history_items_model_visible_bytes=944541
estimated_tokens_of_items_added_since_last_successful_api_response=6968
failing_compaction_request_model_visible_bytes=966015
model_context_window_tokens=258400

2026-05-31T19:58:10Z
last_api_response_total_tokens=241526
all_history_items_model_visible_bytes=781135
estimated_tokens_of_items_added_since_last_successful_api_response=4271
failing_compaction_request_model_visible_bytes=797454
model_context_window_tokens=258400

2026-05-31T20:05:35Z
last_api_response_total_tokens=241526
all_history_items_model_visible_bytes=781135
estimated_tokens_of_items_added_since_last_successful_api_response=4271
failing_compaction_request_model_visible_bytes=797454
model_context_window_tokens=258400

2026-05-31T20:33:31Z
last_api_response_total_tokens=241526
all_history_items_model_visible_bytes=781135
estimated_tokens_of_items_added_since_last_successful_api_response=4271
failing_compaction_request_model_visible_bytes=797454
model_context_window_tokens=258400

Local checks

Fresh bundled codex doctor --summary result:

17 ok · 1 idle · 1 notes · 0 warn · 0 fail ok

Connectivity checks:

Responses WebSocket handshake: HTTP 101 Switching Protocols
Proxy environment variables: none
WinHTTP proxy: direct access
DNS resolution for chatgpt.com: OK
TCP chatgpt.com:443: OK
Unauthenticated POST /backend-api/codex/responses/compact: HTTP 401

The endpoint is reachable from this machine. Ordinary turns and tool execution continue to work; the failures are specific to the remote compaction path near the context limit.

Related reports

Primary open tracker: Remote compaction intermittently fails with stream disconnected before completion #17392
Related Windows Codex Desktop report: Codex Desktop remote compaction repeatedly fails on long sessions #24544
OpenAI status incident resolved on May 28, 2026: https://status.openai.com/incidents/01KSN9ATSF1WCJ5ZTQSR1H9CC7

Expected behavior

Remote compaction should complete reliably. If it fails, Codex should preserve thread usability and provide an automatic fallback or a clear recovery path instead of repeatedly breaking the active thread.

Privacy note

This report intentionally omits account identifiers, thread IDs, session IDs, local filesystem paths, repository details, raw logs, and transcript content.

I have a small behavior-preserving patch prepared for the failure-receipt side of this cluster. It does not attempt to fix the underlying /responses/compact stream disconnect, but it makes the user-visible/task error receipt clearer when remote compaction fails before replacement history is installed.

Branch:

https://github.com/carltonawong/codex/tree/carlton/remote-compaction-failure-receipt

Relevant scope:

legacy remote compaction: codex-rs/core/src/compact_remote.rs
remote compaction v2: codex-rs/core/src/compact_remote_v2.rs
regression coverage: codex-rs/core/tests/suite/compact_remote.rs

The main invariant the patch adds to the error receipt is:

remote compaction failed, replacement history was not installed, and existing thread history was preserved

Why I think this is useful for this issue: several reports here mix two separate concerns — the actual remote compact failure, and whether the thread/history was lost or corrupted afterward. This patch keeps those concerns separate in the receipt so users and maintainers can tell that the compact attempt failed without implying that local history replacement happened.

Local validation on the branch:

cargo fmt --check
git diff --check
cargo test -p codex-core --test all compact_remote -- --nocapture
  38 passed; 0 failed; 1 ignored
cargo test -p codex-core --test all compact_remote -- --include-ignored --nocapture
  39 passed; 0 failed; 0 ignored

I tried to open this as a PR, but the compare page reports that openai/codex currently limits opening PRs to collaborators. If maintainers want this split out differently, I can adjust the branch to match the preferred shape.

Looked into this. The /responses/compact call fails at the transport layer (error sending request for url ... → CodexErr::Stream), and run_auto_compact then aborts the turn. Since history is still over the limit, the next turn retries the same failing compaction — so the session stays stuck.

Suggestion: when remote compaction fails with a retryable/transport error, fall back to the existing local summarization compaction (run_inline_auto_compact_task, normal /responses path) instead of aborting. It self-heals on a full window, so the session keeps going.

Reference patch (both v1/v2 paths, with tests): xiaocang#1

when will this bug being fixed? I see 2 other similar issues are closed as duplicate but this annoying bug is never being fixed...

I’m seeing the same failure repeatedly in Codex Desktop, and it is now blocking completion of long-running projects because automatic compaction does not recover.

Environment:

Codex app: 26.602.40724 (CFBundleVersion 3593)
Bundled/session CLI version in local JSONL: 0.137.0-alpha.4
Platform: macOS 26.5.1 (25F80), arm64, Apple Silicon
Model in the affected turn contexts: gpt-5.5
Origin/source in session metadata: Codex Desktop, vscode

Visible error shown in the Codex UI in all three affected conversations:

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

Affected local thread IDs:

codex://threads/019e9b96-b829-7562-96bc-802310766d53
codex://threads/019e9983-6d9f-7ca2-955f-0333080f5fdc
codex://threads/019e9739-ca62-7512-8fe5-aab13b3d4f11

Observed pattern from the local session JSONL/logs:

Thread	Started	Task shape	Local evidence
`019e9b96-b829-7562-96bc-802310766d53`	2026-06-06T06:20:06Z	Long Penman/FSA workbook rebuild with subagents, web/data gathering, and checkpointing	session reached ~100,453 tracked tokens in ~329s; last assistant progress message was mid-pipeline rewrite; compaction failed in UI before the project could finish
`019e9983-6d9f-7ca2-955f-0333080f5fdc`	2026-06-05T20:39:47Z	Long IHG Penman/FSA workbook/report export and visual QA	session reached ~578,944 tracked tokens; on resume the desktop log reports `maybe_resume_success ... latestTurnStatus=interrupted markedStreaming=true`; user had to interrupt/start over after the compact failure
`019e9739-ca62-7512-8fe5-aab13b3d4f11`	2026-06-05T10:00:07Z	TAG/LEG Penman/FSA workflow, then continuation to inspect a Word framework including embedded images	first task completed; continuation later reached ~227,857 tracked tokens, then UI showed the same remote compact error and the JSONL records repeated `turn_aborted` / `interrupted` states

Two details that may help debugging:

The exact compact error is visible in the UI, but in these local JSONL files I do not see a corresponding structured event_msg with the compact error. The JSONL mostly shows token growth and then turn_aborted: interrupted or a resumed turn staying interrupted/markedStreaming in desktop logs. If the compact task is failing outside the normal event stream, that may make recovery/debugging harder.
This is not tied to one workspace or one local command. It appeared across separate long financial-research/workbook threads. The common factor is high accumulated context plus automatic remote compaction.

Expected behavior: automatic compaction should either complete, retry, or fail gracefully while preserving a usable/resumable thread. It should not leave the user forced to restart a multi-hour project in a fresh conversation.

Actual behavior: the thread becomes effectively unusable after the remote compact request disconnects, and the user has to start over or manually reconstruct state from local artifacts/checkpoints.

I’m seeing the same failure repeatedly in Codex Desktop, and it is now blocking completion of long-running projects because automatic compaction does not recover.

Environment:

Codex app: 26.602.40724 (CFBundleVersion 3593)

Bundled/session CLI version in local JSONL: 0.137.0-alpha.4

Platform: macOS 26.5.1 (25F80), arm64, Apple Silicon

Model in the affected turn contexts: gpt-5.5

Origin/source in session metadata: Codex Desktop, vscode

Visible error shown in the Codex UI in all three affected conversations:
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
Affected local thread IDs:
codex://threads/019e9b96-b829-7562-96bc-802310766d53
codex://threads/019e9983-6d9f-7ca2-955f-0333080f5fdc
codex://threads/019e9739-ca62-7512-8fe5-aab13b3d4f11
Observed pattern from the local session JSONL/logs:

Thread Started Task shape Local evidence
019e9b96-b829-7562-96bc-802310766d53 2026-06-06T06:20:06Z Long Penman/FSA workbook rebuild with subagents, web/data gathering, and checkpointing session reached ~100,453 tracked tokens in ~329s; last assistant progress message was mid-pipeline rewrite; compaction failed in UI before the project could finish
019e9983-6d9f-7ca2-955f-0333080f5fdc 2026-06-05T20:39:47Z Long IHG Penman/FSA workbook/report export and visual QA session reached ~578,944 tracked tokens; on resume the desktop log reports maybe_resume_success ... latestTurnStatus=interrupted markedStreaming=true; user had to interrupt/start over after the compact failure
019e9739-ca62-7512-8fe5-aab13b3d4f11 2026-06-05T10:00:07Z TAG/LEG Penman/FSA workflow, then continuation to inspect a Word framework including embedded images first task completed; continuation later reached ~227,857 tracked tokens, then UI showed the same remote compact error and the JSONL records repeated turn_aborted / interrupted states
Two details that may help debugging:

The exact compact error is visible in the UI, but in these local JSONL files I do not see a corresponding structured event_msg with the compact error. The JSONL mostly shows token growth and then turn_aborted: interrupted or a resumed turn staying interrupted/markedStreaming in desktop logs. If the compact task is failing outside the normal event stream, that may make recovery/debugging harder.

This is not tied to one workspace or one local command. It appeared across separate long financial-research/workbook threads. The common factor is high accumulated context plus automatic remote compaction.

Expected behavior: automatic compaction should either complete, retry, or fail gracefully while preserving a usable/resumable thread. It should not leave the user forced to restart a multi-hour project in a fresh conversation.

Actual behavior: the thread becomes effectively unusable after the remote compact request disconnects, and the user has to start over or manually reconstruct state from local artifacts/checkpoints.

I forked codex to fix this problem using local compact
https://github.com/garyfpga/codex-compact-fix

if you don't mind the trouble give it a try
on my CLI I no longer have any problem
but still wish they will fix the remote compact or give back 1m context

I’m seeing the same failure repeatedly in Codex Desktop, and it is now blocking completion of long-running projects because automatic compaction does not recover.

Environment:

Codex app: 26.602.40724 (CFBundleVersion 3593)

Bundled/session CLI version in local JSONL: 0.137.0-alpha.4

Platform: macOS 26.5.1 (25F80), arm64, Apple Silicon

Model in the affected turn contexts: gpt-5.5

Origin/source in session metadata: Codex Desktop, vscode

Visible error shown in the Codex UI in all three affected conversations:

FYI, one of the problem is actually the timeout of the http request / the websocket request
it usually happens when using VPN
and sometimes the problem is complicated due to cloudflare challenge in the middle....

changing to local compact solve the problem but not a good solution

this is so disruptive to our flows ... I hope its fixed asap.

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.

Navigation Menu

Repository navigation

Remote compaction intermittently fails with stream disconnected before completion #17392

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

Summary

Environment

Frequency

Expected behavior

Actual behavior

Reproduction pattern

Sanitized evidence

Notes

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Codex Desktop remote compaction failures on Windows

Summary

Environment

Reproduction pattern

Sanitized local evidence

Local checks

Related reports

Expected behavior

Privacy note

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Remote compaction intermittently fails with stream disconnected before completion #17392

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

Summary

Environment

Frequency

Expected behavior

Actual behavior

Reproduction pattern

Sanitized evidence

Notes

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Apr 10, 2026

RossRichardson commented on Apr 25, 2026

JulienJBO commented on Apr 26, 2026

eeeepie commented on May 3, 2026

presidenzo commented on May 7, 2026

ren1003497048-del commented on May 17, 2026

Super5280 commented on May 22, 2026

Super5280 commented on May 22, 2026

toxic2040 commented on May 22, 2026

bogdanbaciu21 commented on May 28, 2026

toxic2040 commented on May 31, 2026

mcfax-arch commented on May 31, 2026

Codex Desktop remote compaction failures on Windows

Summary

Environment

Reproduction pattern

Sanitized local evidence

Local checks

Related reports

Expected behavior

Privacy note

carltonawong commented on Jun 1, 2026

xiaocang commented on Jun 1, 2026

garyfpga commented on Jun 3, 2026

EugeniSegarra commented on Jun 6, 2026

garyfpga commented on Jun 6, 2026

garyfpga commented on Jun 6, 2026

essamgouda97 commented on Jun 8, 2026

etraut-openai commented on Jun 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions