Repeated Compact-related ERROR & Stuck in Working

Resolved 💬 6 comments Opened Apr 30, 2026 by qlagrangian Closed Jun 29, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.125.0

What subscription do you have?

Plus

Which model were you using?

GPT-5.5

What platform is your computer?

Darwin 25.3.0 x86_64 i386

What terminal emulator and version are you using (if applicable)?

VSCode

What issue are you seeing?

This issue happens frequently when the remaining context capacity drops to around 10%. The following error keeps appearing repeatedly:

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

In short, no matter how many times I retry, the session stays stuck on Working... and nothing moves at all. Just to double-check, I ran the Nettop command and confirmed there is zero communication with the server.

It looks like there is a bug in the automatic Compact function.

Restarting the session or clearing the cache does not fix the problem. With no other options, I had to create a new Session, pass the ID of the stuck session, and instruct it to continue from there. However, getting completely stuck in a state where I have no idea what caused it was an extremely unproductive and frustrating development experience.

Please fix this urgently.

What steps can reproduce the bug?

Uploaded thread: 019dd7d4-365e-7fa0-a4bd-1b1a8dd09eb0

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

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

#20160
#19558
#19329
#19547
#19660

Powered by Codex Action

qlagrangian · 2 months ago

chore: note NordVPN 300s timeout limit on Codex requests

Confirmed that Codex "Remote Compact" fails consistently at exactly
300s when NordVPN is active. This is independent of the Codex server's
actual response time and is enforced by the VPN layer.

[Problem]
Users accessing Codex via VPN encounter excessive wait times during
"Remote Compact" operations when the context is large, leading to
connection timeouts.

[Cause]

The VPN server (specifically NordVPN) has a strict 300-second (5-minute)

timeout threshold.

If the server-side processing exceeds this limit, the VPN terminates

the connection regardless of the actual server status.

[Workaround]

Temporarily pause the VPN and trigger a "continue" instruction.
This allows the process to recover and complete the server response.

presidenzo · 2 months ago

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

qlagrangian · 2 months ago

@codex Please fix this issue (Auto compact problem through VPN) ASAP.

mshumski · 2 months ago

Hit the same error.

Looks like NordVPN / some proxy path kills the long silent `/responses/compact` HTTPS request after ~5 minutes:


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

Workaround that has been working fine for me:

model_provider = "openai-chatgpt-stable"
model_auto_compact_token_limit = 230000

[model_providers.openai-chatgpt-stable]
name = "OpenAI ChatGPT Stable"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = true
request_max_retries = 20
stream_max_retries = 20

This keeps ChatGPT auth, but avoids the remote compact endpoint because the provider name is not exactly OpenAI, so Codex falls back to local/model-streaming compaction instead of POST /responses/compact.

Would be good if Codex fell back to local compaction automatically when remote compact fails with a transport/network timeout.

etraut-openai contributor · 21 days ago

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.