Error running remote compact task: timeout waiting for child process to exit

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

• #14321
• #14292
• #14425

Powered by Codex Action

#14860

I’m also hitting this on Linux with the latest stable CLI, and it is breaking resume/continuation of long-running threads.

Environment

• Codex CLI: 0.118.0
• Install method: global npm package @openai/codex
• OS: Ubuntu Linux
• Model: gpt-5.4

Problem
Long-running interactive sessions repeatedly fail with:

Error running remote compact task: timeout waiting for child process to exit

<img width="790" height="67" alt="Image" src="https://github.com/user-attachments/assets/26fd706f-78fb-4a64-ac87-6f3442ef828f" />

This is not isolated to one repo. It has happened across unrelated projects on the same machine and can leave the affected thread effectively unusable.

What I observed locally

• The exact error has occurred 24 times in ~/.codex/log/codex-tui.log.
• It reproduces across multiple sessions/projects.
• Example affected session id: 019d77ed-a71a-72a1-9a6f-7d2587adb2c4
• Resume is not a reliable recovery path once a thread gets into this state. The next turn can hit the same compaction failure again.

Representative log details
From ~/.codex/log/codex-tui.log:

codex_core::compact_remote: remote compaction failed ... compact_error=timeout waiting for child process to exit

One representative instance logged:

• last_api_response_total_tokens=238609
• all_history_items_model_visible_bytes=788672
• failing_compaction_request_model_visible_bytes=803365
• model_context_window_tokens=Some(258400)

Why this looks like a Codex bug rather than local corruption

• 0.118.0 is already the latest stable npm release here.
• The failure pattern is consistent across different projects.
• Resume does not consistently recover the thread.
• From upstream source, the compaction teardown path appears to have a 10-second shutdown timeout, which may be too aggressive for this case.

Impact

• Long threads become fragile or effectively unusable.
• codex resume <session-id> is not dependable once the thread is affected.
• This causes real work loss because the user cannot continue the same conversation even after restarting.

Partial workaround
I lowered model_auto_compact_token_limit in ~/.codex/config.toml so compaction happens earlier on future turns/threads. That may reduce recurrence, but it does not reliably recover already-affected
threads.

Requested improvement

• Fix the compaction-thread shutdown timeout path on Linux.
• Make resume more resilient for already-affected threads.
• If compaction shutdown times out, a degraded but resumable recovery path would be much better than leaving the thread stuck.

I have a ready fix for the compaction failure path reported here, but openai/codex is currently collaborators_only for PR creation, so I cannot open the PR directly from my account.

Branch: minanagehsalalma:fix/remote-compact-timeout-recovery
Commit: ea2504064
Compare: https://github.com/openai/codex/compare/main...minanagehsalalma:fix/remote-compact-timeout-recovery?expand=1

This patch addresses both the misleading timeout surfaced in this issue and the large-session remote compaction timeout path tracked in #14860.

What the patch does:

• maps API transport timeouts to CodexErr::RequestTimeout
• keeps the child-process timeout wording for actual child-process failures only
• applies compact-request timeout/compression behavior consistently
• falls back to local compaction on remote compact timeout
• skips obviously timeout-prone oversized remote compaction attempts up front

Validation I ran locally:

• targeted timeout fallback test passed
• targeted oversized preflight-skip test passed
• compact_remote: 25 passed, 1 ignored
• compact_resume_fork: 4 passed
• request_compression: 4 passed

Prebuilt binary handoff:

• release: https://github.com/minanagehsalalma/codex/releases/tag/remote-compact-timeout-recovery-ea2504064
• linux x64 binary: https://github.com/minanagehsalalma/codex/releases/download/remote-compact-timeout-recovery-ea2504064/codex-linux-x64
• sha256: https://github.com/minanagehsalalma/codex/releases/download/remote-compact-timeout-recovery-ea2504064/codex-linux-x64.sha256
• notes: https://github.com/minanagehsalalma/codex/releases/download/remote-compact-timeout-recovery-ea2504064/README.txt

Credit:

• branch and commit are authored from @minanagehsalalma's fork/profile

Routing note:

• recent ownership in the touched path points to @aibrahim-oai on core compaction work and @jif-oai on the compact API path

If a collaborator is willing, please open the PR from the compare link above so it can be reviewed and linked back to these issues.

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.