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.

• #13784
• #13815
• #12425
• #11954

Powered by Codex Action

I have been getting this issue for the last few days. I've reported multiple times in the feedback in the codex mac app. The latest one has reference 019d1fff-5705-7092-9468-30adf07dfbdc

I have been getting this issue for the last few days. I've reported multiple times in the feedback in the codex mac app. The latest one has reference 019d1fff-5705-7092-9468-30adf07dfbdc我这几天一直遇到这个问题。我在 Codex Mac 应用的反馈里多次举报过。最新的版本参考号为 019d1fff-5705-7092-9468-30adf07dfbdc

me too

me too

Adding another reproducible case from macOS + VS Code Codex.

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

Important additional detail:
after the compact-related hang, the UI can lose the latest visible turns, while those turns are still present in ~/.codex/sessions/...jsonl. So there may be a second bug in thread restore/history sync after compact failure.

Related report:

• #16413

This is affecting long-running threads and makes them unreliable to continue.

Adding another Codex Desktop repro with local log evidence.

Environment

• Codex app About version: 26.406.31014
• Logged app.version for the failing conversation: 0.119.0-alpha.11
• Platform: macOS 26.3.1 arm64
• Auth mode: ChatGPT
• Model: gpt-5.4

Observed behavior

• Auto-compaction shows:

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

• After this happens, the thread is effectively stuck / unrecoverable from the app side. There is no obvious recovery path when the auto-compaction attempt fails.

Concrete repro artifact

• Local conversation/thread id: 019d495f-c6c7-7240-9bd3-d32fe646277b
• Failing turn id: 019d7832-87a4-7c71-89da-7024af8e32fe

Relevant local log details

• Remote compaction failed after attempt=4
• Request duration was about 60622 ms
• last_api_response_total_tokens=647339
• all_history_items_model_visible_bytes=2699502
• failing_compaction_request_model_visible_bytes=2714195
• Failing endpoint: POST /backend-api/codex/responses/compact
• Logged error: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

This looks worse than a transient network blip because the failure leaves the session in a bad state instead of recovering cleanly or surfacing a usable fallback.

Is there a solution?or a way to avoid it?

me too

me too

codex is not usable at this point with getting these error all the time !!

It seems its related with vpn, the vpn is not stable.

I don't have VPN but have private cloud relay from iCloud. Which who knows maybe that's just a VPN from Apple. Doesn't cause me issues anywhere else though.

我解决了，通过在config.toml里面设置好压缩阈值（我采用的是240000，不要设置太大，否则压缩压力越大越容易失败），以及延长默认压缩时间（我采用的是60000ms）外加重试次数（我采用的是2次），这样下来我这个问题到现在为止还没发生过，希望能帮到你

我解决了，通过在config.toml里面设置好压缩阈值（我采用的是240000，不要设置太大，否则压缩压力越大越容易失败），以及延长默认压缩时间（我采用的是60000ms）外加重试次数（我采用的是2次），这样下来我这个问题到现在为止还没发生过，希望能帮到你

How to set compaction threshold?

我解决了，通过在config.toml里面设置好压缩阈值（我采用的是240000，不要设置太大，否则压缩压力越大越容易失败），以及延长默认压缩时间（我采用的是60000ms）外加重试次数（我采用的是2次），这样下来我这个问题到现在为止还没发生过，希望能帮到你

默认压缩阈值是245000，少5000能有那么大效果？

> 我解决了，通过在config.toml里面设置好压缩阈值（我采用的是240000，不要设置太大，否则压缩压力越大越容易失败），以及延长默认压缩时间（我采用的是60000ms）外加重试次数（我采用的是2次），这样下来我这个问题到现在为止还没发生过，希望能帮到你 默认压缩阈值是245000，少5000能有那么大效果？

可能是我默认压缩时间增加了，我之前写错了，我压缩时间增加到了1200000ms，即最大压缩20分钟一次，失败的话再重试一次。大大减少了压缩失败的可能。其实20分钟夸张了，10分钟也差不多了

> 我解决了，通过在config.toml里面设置好压缩阈值（我采用的是240000，不要设置太大，否则压缩压力越大越容易失败），以及延长默认压缩时间（我采用的是60000ms）外加重试次数（我采用的是2次），这样下来我这个问题到现在为止还没发生过，希望能帮到你 How to set compaction threshold?如何设置压缩阈值？

手动编辑config.toml，里面设置如下：
model_auto_compact_token_limit = 240000
stream_idle_timeout_ms = 1200000
stream_max_retries = 2
这样设置下来我的压缩错误大大减少

> > 我解决了，通过在config.toml里面设置好压缩阈值（我采用的是240000，不要设置太大，否则压缩压力越大越容易失败），以及延长默认压缩时间（我采用的是60000ms）外加重试次数（我采用的是2次），这样下来我这个问题到现在为止还没发生过，希望能帮到你 > > > How to set compaction threshold?如何设置压缩阈值？ 手动编辑config.toml，里面设置如下： model_auto_compact_token_limit = 240000 stream_idle_timeout_ms = 1200000 stream_max_retries = 2 这样设置下来我的压缩错误大大减少

感谢，我试试，这两天一直被这个问题困扰

Still having issues. honestly most frustrating thing ever. this is why i'm still subscribed to claude, no issues there. for this i leave codex for overnight and stops the workflow, lost hours. recovery is manual - spam /fork into local and run 10 sessions in parallel on compaction in hopes that one of them will compact. such a massive waste of time, pls fix!

Still having issues. honestly most frustrating thing ever. this is why i'm still subscribed to claude, no issues there. for this i leave codex for overnight and stops the workflow, lost hours. recovery is manual - spam /fork into local and run 10 sessions in parallel on compaction in hopes that one of them will compact. such a massive waste of time, pls fix!

Same! Shit, I was expecting CodeX to work overnight, but it turned out this error and I am fixing it at 1:30 am !!!

Решение ошибки Codex: remote compact task: stream disconnected

Столкнулся с ошибкой в Codex:

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

Сначала казалось, что проблема в самом Codex или в config.toml, но в моём случае причина оказалась в сети.

Codex CLI не использовал системный Windows Proxy, хотя в Windows был включён SOCKS-прокси:

socks=127.0.0.1:10808

Из-за этого браузер и часть приложений могли нормально работать через прокси/VPN, а сам Codex CLI шёл напрямую. В результате codex doctor показывал ошибки:

reachability one or more required provider endpoints are unreachable over HTTP
ChatGPT base URL https://chatgpt.com/backend-api/ connect failed

При этом после явного указания proxy через переменные окружения всё заработало: websocket подключился, reachability стал успешным, итог codex doctor стал 0 warn · 0 fail ok.

Что помогло

В PowerShell нужно указать прокси для Codex через переменные окружения:

$env:ALL_PROXY="socks5h://127.0.0.1:10808"
$env:HTTPS_PROXY="socks5h://127.0.0.1:10808"
$env:HTTP_PROXY="socks5h://127.0.0.1:10808"
$env:NO_PROXY="localhost,127.0.0.1,::1"

codex doctor

Если после этого codex doctor показывает:

✓ websocket connected
✓ reachability active provider endpoints are reachable over HTTP
0 warn · 0 fail ok

значит проблема была именно в том, что Codex не использовал ваш локальный прокси.

Как закрепить навсегда

[Environment]::SetEnvironmentVariable("ALL_PROXY", "socks5h://127.0.0.1:10808", "User")
[Environment]::SetEnvironmentVariable("HTTPS_PROXY", "socks5h://127.0.0.1:10808", "User")
[Environment]::SetEnvironmentVariable("HTTP_PROXY", "socks5h://127.0.0.1:10808", "User")
[Environment]::SetEnvironmentVariable("NO_PROXY", "localhost,127.0.0.1,::1", "User")

После этого нужно закрыть PowerShell, открыть заново и проверить:

codex doctor

Важно

127.0.0.1:10808 — это мой локальный SOCKS-порт. У вас он может быть другим. Например, в некоторых клиентах это может быть 1080, 10808, 7890, 7897, 10809 и т.д.

Проверить можно так:

curl.exe -v --proxy socks5h://127.0.0.1:10808 https://chatgpt.com/backend-api/codex/responses/compact

Нормальный результат — быстрый ответ вроде:

HTTP/1.1 405 Method Not Allowed

Это не ошибка сети. Это значит, что endpoint доступен, просто curl делает GET, а Codex использует POST.

Дополнительно

Для снижения ошибок compact я также добавил в:

C:\Users\<USER>\.codex\config.toml

такие настройки:

model_auto_compact_token_limit = 240000
stream_idle_timeout_ms = 1200000
stream_max_retries = 2

Но в моём случае ключевым решением оказался именно proxy через переменные окружения, а не только настройки compact.