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

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

• #14913
• #14063
• #13906
• #14559
• #13784

Powered by Codex Action

+1

Turned off my wifi anf turned it on again. Also set model to low and fast and its olved the issue

Thanks! Yeah there is this trick that can unblock this error but I want to run my sessions for really long (hours of long running task) with continued context and this error interrupts it and make it impossible...

You can also run the /compact command manually and then, ask the agent to continue. But still, it interferes with long-running agents.

i turned off and on VPN and the problem is solved

i switch model from gpt5.4 to 5.3codex solved

hey, this is a relatively new occurrence.
I hope you fix it.
thread ID 019dd23f-4f50-73d0-9f18-bb1101f6c3ae

Reproducing on Codex CLI v0.125.0, macOS (Apple Silicon), ChatGPT Pro subscription, model gpt-5.5.

Symptom

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

Failure happens consistently at the 5-minute mark (300s), which exactly matches the documented default of stream_idle_timeout_ms = 300000 for SSE streams. The compact endpoint stays silent during server-side compute on long sessions, so the client-side idle timeout fires before any response bytes arrive.

No working override path exists for ChatGPT subscription users

1. [model_providers.openai] block is rejected — built-in provider IDs (openai, ollama, lmstudio) are reserved per the advanced config docs.
2. Top-level stream_idle_timeout_ms is documented as accepted in older releases but ignored in current ones.
3. Defining a custom provider (e.g. [model_providers.my-openai]) requires env_key = "OPENAI_API_KEY". ChatGPT subscription users only have auth.json from codex login — no API key, so this path is blocked.
4. openai_base_url only changes the base URL, not the timeout.

Net result: a config knob exists, the default is the exact value causing the bug, but the knob is unreachable for the largest segment of paying users. Existing workarounds in this thread (toggle VPN / switch model / pre-emptive /compact) are all narrow side-effects that don't address the root cause.

Things tried that did NOT help (network-layer fixes — confirming the bug is HTTP-level, not network)

• macOS net.inet.tcp.always_keepalive=1, keepidle=60s, keepintvl=30s (persisted via LaunchDaemon)
• Proxy VPS (Linux): net.ipv4.tcp_keepalive_time=60, BBR + fq qdisc, tcp_rmem/wmem ceiling raised to 64 MB
• All confirmed effective for SSH long-idle and other TCP-level idle scenarios; irrelevant to this bug as expected — TCP keepalive packets aren't visible to the HTTP-stream idle policy at the chatgpt.com edge.

Asks (any one would unblock)

1. Allow stream_idle_timeout_ms override for the built-in openai provider — either via a top-level key (openai_stream_idle_timeout_ms?) symmetric to openai_base_url, or by accepting non-conflicting fields like timeouts inside [model_providers.openai].
2. Server-side SSE heartbeat from /backend-api/codex/responses/compact during compute, so the stream is never silent for >300s.
3. Client-side: bump the default for the compact code path specifically. Compact computation reasonably takes minutes on long sessions; 5-minute default is too aggressive for this endpoint.

Happy to provide upload thread IDs from any reproduction if useful.

I’m also seeing this in Codex.

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

Environment:

• Codex CLI: 0.131.0-alpha.9
• Platform: macOS 26.4.1, build 25E253
• Kernel/arch: Darwin 25.4.0, arm64
• Surface: Codex desktop app / local Codex session
• Date observed: 2026-05-16
• Timezone: Europe/Madrid
• Privacy preference: minimal details, no thread IDs shared publicly

Impact:
Compaction fails when the conversation gets large, leaving the session hard or impossible to continue without starting a fresh thread.

Expected:
Automatic context compaction should complete successfully, or retry/fallback gracefully without breaking the session.

Actual:
The remote /backend-api/codex/responses/compact request disconnects before completion.

I am still facing this error... have been building some tools to help me rescue this programatically but those tools are brittle... Any update on this team? it is really frustrating to deal with this compaction error....

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.