Error running remote compact task: stream disconnected before completion BUG

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

• #14063
• #13906
• #13784

Powered by Codex Action

I confirm the issue :(

eventually find out it might be the internet issue, after use some reliable proxies this issue never happen again...
but still dont know why the session will be messed up and can not be recovered

Your on windows, so I'm not sure it still uses reqwest, and I don't know if the Windows version has the 30 default timeout that is ridiculously short for that many tokens. But I submitted a fix for a similar problem in linux: https://github.com/openai/codex/issues/14860

Same

I confirm the issue :(

Adjust the stream_idle_timeout_ms parameter in config.toml.
----------------------------demo---------------------------

model = "gpt-5.4"
model_reasoning_effort = "xhigh"
personality = "pragmatic"
sandbox_mode = "danger-full-access"
model_provider = "def"

[model_providers.def]
name = "OpenAI Data Residency"
stream_idle_timeout_ms = 600000

> I confirm the issue :( Adjust the stream_idle_timeout_ms parameter in config.toml. ----------------------------demo--------------------------- model = "gpt-5.4" model_reasoning_effort = "xhigh" personality = "pragmatic" sandbox_mode = "danger-full-access" model_provider = "def" [model_providers.def] name = "OpenAI Data Residency" # stream_max_retries = 10 stream_idle_timeout_ms = 600000

this may really help me !!!

> > I confirm the issue :( > > > Adjust the stream_idle_timeout_ms parameter in config.toml. ----------------------------demo--------------------------- > model = "gpt-5.4" model_reasoning_effort = "xhigh" personality = "pragmatic" sandbox_mode = "danger-full-access" model_provider = "def" > [model_providers.def] name = "OpenAI Data Residency" > # stream_max_retries = 10 > stream_idle_timeout_ms = 600000 this may really help me !!!

Please let us know if you still experience issues or not. I would be grateful to find out if there is an alternative path to modify the timeout that affects compact.

> > > I confirm the issue :( > > > > > > Adjust the stream_idle_timeout_ms parameter in config.toml. ----------------------------demo--------------------------- > > model = "gpt-5.4" model_reasoning_effort = "xhigh" personality = "pragmatic" sandbox_mode = "danger-full-access" model_provider = "def" > > [model_providers.def] name = "OpenAI Data Residency" > > # stream_max_retries = 10 > > stream_idle_timeout_ms = 600000 > > > this may really help me !!! Please let us know if you still experience issues or not. I would be grateful to find out if there is an alternative path to modify the timeout that affects compact.

It works on the Codex app.

> > > > I confirm the issue :( > > > > > > > > > Adjust the stream_idle_timeout_ms parameter in config.toml. ----------------------------demo--------------------------- > > > model = "gpt-5.4" model_reasoning_effort = "xhigh" personality = "pragmatic" sandbox_mode = "danger-full-access" model_provider = "def" > > > [model_providers.def] name = "OpenAI Data Residency" > > > # stream_max_retries = 10 > > > stream_idle_timeout_ms = 600000 > > > > > > this may really help me !!! > > > Please let us know if you still experience issues or not. I would be grateful to find out if there is an alternative path to modify the timeout that affects compact. It works on the Codex app.

I confirmed this solution works for me too. On Linux (Ubuntu).

Does not work!

<img width="1082" height="413" alt="Image" src="https://github.com/user-attachments/assets/35d48f0a-5b26-441b-a89c-58edbf082e35" />

Does not work!

Does not work! <img alt="Image" width="1082" height="413" src="https://private-user-images.githubusercontent.com/3739536/569557057-35d48f0a-5b26-441b-a89c-58edbf082e35.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzUxNTg2MzYsIm5iZiI6MTc3NTE1ODMzNiwicGF0aCI6Ii8zNzM5NTM2LzU2OTU1NzA1Ny0zNWQ0OGYwYS01YjI2LTQ0MWItYTg5Yy01OGVkYmYwODJlMzUucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDQwMiUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA0MDJUMTkzMjE2WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9MTFiZDNiOTU0ZjU0ZGI0YWE4ZTY5OWY1NjJjMDBiMjc3YjZiODk1YTVmNDFiMzA2ZmY1ZmM3Y2FiZjEzMDJlMSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.ar8nL2hTpP0-fYcqIKE5bRIKV0I7xPt6JBwNIWLPW-c">

@cihadturhan You need the model_provider = "def" in the top section. that bottom part is just defining the def model provider. Your settings currently define def, but not specify for the app to actually use it.

NOTE: for resuming sessions, sadly they are tied to provider. So you will not see past sessions for the default "openai" provider after the change. Though I just asked a new context to walk me through moving my old context to the new provider.

@cihadturhan You need the model_provider = "def" in the top section. that bottom part is just defining the def model provider. Your settings currently define def, but not specify for the app to actually use it. NOTE: for resuming sessions, sadly they are tied to provider. So you will not see past sessions for the default "openai" provider after the change. Though I just asked a new context to walk me through moving my old context to the new provider.

Just to tack on to your note for future users: If you were to edit the db you can set all of the current threads to use the new provider. It requires having a sqlite editor. sqlite3 is small and free.

1. temporarily remove the model_provider = "def" from the config file
2. quit codex
3. cd ~/.codex/ (or equivalent depending on OS)
4. run: sqlite3 state_5.sqlite "UPDATE threads SET model_provider = 'def';"
5. put back in the model_provider = "def" entry in the config file
6. restart codex

Once you change this entry it will view all current threads as being owned by the "def" provider. You will have your entire thread history now assigned to def with no need to manually copy them over.

> I confirm the issue :( Adjust the stream_idle_timeout_ms parameter in config.toml. ----------------------------demo--------------------------- model = "gpt-5.4" model_reasoning_effort = "xhigh" personality = "pragmatic" sandbox_mode = "danger-full-access" model_provider = "def" [model_providers.def] name = "OpenAI Data Residency" stream_idle_timeout_ms = 600000

What is the special meaning of def and OpenAI Data Residency? Can I just use another name? I don't understand the working principle of this configuration

I hit the same remote compaction failure again today, with concrete log metrics that may help narrow it down.

Environment:

• Codex macOS app: 26.422.62136 (2176)
• Platform: macOS 15.6.1, Darwin 24.6.0, arm64
• Model: gpt-5.5
• Auth/provider: ChatGPT / OpenAI
• Local latest Codex version cache: 0.125.0

Visible error:

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

Observed timestamps:

• 2026-04-30 17:22:56 Asia/Shanghai
• 2026-04-30 17:24:04 Asia/Shanghai

Relevant sanitized log details from codex-tui.log:

remote compaction failed
thread_id=019ddda4-855d-7000-99ac-586513c1b3b8
turn_id=019dddae-4b55-7a02-a892-57d875e578a3
last_api_response_total_tokens=240805
all_history_items_model_visible_bytes=892179
estimated_tokens_of_items_added_since_last_successful_api_response=2055
estimated_bytes_of_items_added_since_last_successful_api_response=8218
model_context_window_tokens=Some(258400)
failing_compaction_request_model_visible_bytes=913526
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

Immediately after the second failure:

codex_core::session::turn: Failed to run pre-sampling compact

Pattern:

• The thread was near the model context limit: 240805 / 258400 tokens.
• The failure occurred before sampling, during remote compaction.
• Retrying the same old thread hit the same failure again.
• Starting a new thread avoids the issue, which suggests this is tied to the remote compact path for long histories rather than local project code or local shell/tool execution.
• I also found older local occurrences of the same compact error on 2026-04-25, with compaction request sizes around ~1MB.

Expected behavior:

• Remote compaction should complete, or fail with a recovery path that keeps the old thread usable.
• If the compact request is too large or the stream is interrupted, Codex should ideally retry with a smaller compact payload or offer a manual resume/new-thread handoff instead of leaving the session blocked at pre-sampling compact.

Here is another potential workaround. You manually compact the thread yourself. Go to the folder that the thread is located in usually ~/.codex/sessions/(date thread was made). Then make a copy of the thread's jsonl file. Afterwards, you can start a new thread, hand this file directly to codex and tell it that it's a jsonl file in codex's format and inform it that it is too large to parse. Ask it to build a python script to compact the entries. Request for it to compact everything between but ignore the first 20 lines and last 100 or so. Once it is done you can replace the file and restart codex. Then the thread will compact.

In my case the issues was codex dealing with mcp servers that returned massive amounts of data that stay cached in the conversation but are too big to transfer for compacting. I was having codex generate my game graphics using comfyui and the results were being stored as base64 encoded images which bloated the token counts into the millions.

Here is the prompt (with reasoning) that I provided codex:
"I have a massive Codex .jsonl session file named rollout-b11c.jsonl. It is bloated to 34 million tokens because of massive ComfyUI MCP tool payloads.

Please write and execute a local Python script to perform a 'structural compaction' on this file. The script should read the file line-by-line, parse the JSON, and do the following:

If the line is a normal user or assistant message, keep it exactly as is.

If the line contains a function_call to mcp__comfyui__, modify the arguments string. Strip out any massive data but leave a summary like: {"control_type": "depth", "status": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII="}.

If the line is a function_call_output from comfyui, replace the massive output payload with a simple summary string: "[Tool execution successful. Image generated and saved. Detailed JSON output removed for context compaction.]"

Save the modified lines to a new file named compacted_rollout.jsonl.

Ensure the script maintains perfectly valid JSONL syntax for every line so it doesn't break the chat application."

Hope this helps. It has worked for me twice now. Now I can just run the python file it made and I can skip the AI for this step entirely.

这是来自QQ邮箱的假期自动回复邮件。

您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。

Additional reproduction details and temporary workaround that may help isolate the failure:

The user initially suspected VPN / network configuration, but reproduced the same remote compaction failure across multiple environments:

• Codex App on Windows, Linux, and macOS
• dorm network, faculty network, and cellular network
• after increasing local idle/request timeout settings to roughly 15 minutes

The notable pattern is that the failing remote compaction path appears to cut out at about 5m01s. This suggests the remaining failure may be tied to a fixed deadline / timeout on the special remote compact path rather than a general network/VPN problem.

Error:

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

Temporary workaround tested by the user:

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

This is not a real alternate provider. The apparent effect is that Codex no longer detects the provider as exactly OpenAI, so it avoids the special /responses/compact remote compaction path and falls back to normal/local compaction through the regular Responses/WebSocket path.

Observed result:

• Several sessions that previously failed remote compaction started compacting successfully with this workaround.
• Compaction completed in under ~10 seconds in cases that previously failed.
• Early testing across Ubuntu and macOS showed multiple successful compactions over longer-running tasks.
• Downside: because the provider name differs, previous Codex history/resume filtering may not show the same sessions normally.

This seems consistent with #19400: Codex currently decides remote compaction by provider identity, not by whether the active model / endpoint combination can reliably use /responses/compact.

Possible fix directions:

• Add an explicit user config option to disable remote compaction, e.g. remote_compaction = "never" or use_remote_compaction = false.
• Make remote compaction model/endpoint aware, and fall back to local compaction when /responses/compact fails or times out.
• If the remote compact endpoint has a fixed timeout around 5 minutes, expose/document it or make the client retry/fallback gracefully.

This workaround should probably be treated only as temporary, but it strongly suggests the normal Responses path is healthy while the special remote compact endpoint is the brittle part.

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

No VPN.

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

Remote compact needs a resumable receipt, not just a longer timeout.

Record compact task id, source thread id, request size/token estimate, started_at, last_stream_event_at, timeout source, retry count, partial summary checkpoint, and recovery action. Then a stream disconnect can resume or fall back to local/manual compaction instead of poisoning the session into repeating the same error forever.

Generated with ax - https://github.com/Necmttn/ax

这是来自QQ邮箱的假期自动回复邮件。

您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。

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.