Remote compact task consistently times out on CLI (author login), while API-compatible provider path works

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

• #18462
• #18450
• #19740
• #19660

Powered by Codex Action

Thanks for taking a look, but this appears to be a different failure mode than the referenced issue.

The referenced issue involves timeouts when creating a new thread / resuming a session.
In contrast, this issue occurs specifically during the compaction path.

Failure characteristics:

• Trigger condition:
• Context reaches compaction threshold (auto) or manual /compact

• Failing operation:
• POST /backend-api/codex/responses/compact

• Observed error:
• "Error running remote compact task: timeout waiting for child process to exit"

• Result:
• The current session becomes unusable immediately after compaction fails

This indicates the failure happens in the compaction RPC lifecycle (request → backend task → response),
not in thread/session creation.

Repro details (consistent, 100%):

1. codex-cli (Linux, SSH TTY)
2. ChatGPT (author) login
3. Long-running session (multi-file code analysis)
4. Context approaches limit
5. Auto-compact triggers
6. Remote compact task does not return before timeout → CLI aborts

Diagnostics:

• Network connectivity is healthy:
• curl to https://chatgpt.com/backend-api/codex/responses/compact returns quickly (HTTP 405 without auth)
• No DNS/TLS/connectivity issues observed

• Local environment verified:
• codex-cli 0.125.0
• node v20.x
• clean reinstall does not change behavior

• Backend path difference (important):

Using ChatGPT (author) login:
→ /backend-api/codex/responses/compact
→ timeout → session dead

Using an OpenAI-compatible API provider (API key via proxy):
→ /v1/responses (and compatible compact handling)
→ "Context compacted"
→ session continues normally

This suggests:

• The compaction backend path for ChatGPT sessions behaves differently from API-compatible paths
• The failure is specific to the remote compact task execution or response handling in the ChatGPT backend
• CLI currently treats compaction failure as fatal (no retry / fallback / degraded continuation)

This is distinct from thread/session creation issues, and likely belongs to the compaction subsystem specifically.

Could this be tracked separately under compaction-related failures?

Happy to provide additional logs or run targeted tests if needed.

Confirming the same Codex 0.125.0 / ChatGPT-login auth repro on NixOS. Manual /compact triggered early in a session succeeds reliably; auto-compact at its trigger threshold consistently fails with the stream-disconnect error.

Concrete measurements from 4 sessions in ~/.codex/sessions/: failures take 93 to 756 seconds before the stream drops, depending on rollout size (3.8 MB to 81.3 MB). Not a fixed 60s timeout. The auth-path observation in this issue matches what I see — failures are on chatgpt.com/backend-api/codex/responses/compact.

Posted longer details with the full duration table at #18450.

If i may: for me, on 0.128.0, compaction near threshold reliably fails.
Thread ID 019df409-814b-7be2-8406-82bae49638f8.
I use Chatgpt auth login.
The session cannot continue after compaction failure.
Platform: Ubuntu 24.04.4 LTS
Error message: "Error running remote compact task: timeout waiting for child process to exit"

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

@zengxq Hey — this issue felt painfully familiar. It is very close to the trust/drift problem I’m trying to solve.

I’m building AgaveCore, and I’d like to let a few early people use it for free while I shape it into something stronger.

It helps when a coding agent starts to drift, forget important progress, or gives you an output you do not fully trust.

In practice, it works through two habits:

• tell the agent to remember-progress or remember-this when something important should not be lost
• use consult-brain when the current task needs more grounded feedback on what to do next

Over time, as useful journals, decisions, and failures pile up, the product should help the agent make sharper decisions and take better actions with less drift.

If this sounds relevant, reply here and I’ll send the exact steps. You can also use the email or Telegram on my profile.

Cheers,
Mads.

Hello,

Confirming that I had the same problem in a similar environment.

What version of Codex CLI is running?

codex-cli 0.125.0

What subscription do you have?

ChatGPT Business

Which model were you using?
gpt-5.5 (tested with high and xhigh)

What platform is your computer?

Ubuntu Linux 22.04.01

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

SSH terminal (temux)

What issue are you seeing?

Error running remote compact task: timeout waiting for child process to exit
After this error, the session becomes unusable and cannot continue.

What steps can reproduce the bug?

Start a long-running task (e.g., multi-file code analysis)

Let the context approach the token limit

Trigger:

Automatic compaction, or
Manual /compact
Result:

Compaction fails 100% of the time and the session becomes unusable

What is the expected behavior?

Compaction triggers a remote task
→ the task does not return in time (or stalls)
→ CLI throws:
"timeout waiting for child process to exit"
→ session is effectively broken

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

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.