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

Activity

1. binlin1973

   added

   bugSomething isn't workingSomething isn't working

   on Mar 13, 2026
2. github-actions commented on Mar 13, 2026

   

   github-actionsBot

   on Mar 13, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Repeated 'Error running remote compact task: timeout waiting for child process to exit' #14321
   • Error running remote compact task: timeout waiting for child process to exit #14292
   • Compaction hangs indefinitely at <16% #14425

   Powered by Codex Action
3. etraut-openai

   added

   contextIssues related to context management (including compaction)Issues related to context management (including compaction)

   on Mar 14, 2026
4. initpwn commented on Mar 19, 2026

   

   initpwn

   on Mar 19, 2026

   More actions

   #14860

   👀React with 👀1Reacted by Mina Nageh Salama
5. etraut-openai

   marked AlmaLinux 9 local VS Code: remote compact task times out waiting for child process to exit #16039 as a duplicate of this issue on Mar 27, 2026
6. minanagehsalalma commented on Apr 10, 2026

   

   minanagehsalalma

   on Apr 10, 2026

   Last edited by minanagehsalalma

   More actions

   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

   

   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.
7. minanagehsalalma commented on Apr 11, 2026

   

   minanagehsalalma

   on Apr 11, 2026

   Last edited by minanagehsalalma

   More actions

   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.
8. etraut-openai commented on Jun 29, 2026

   

   etraut-openai

   on Jun 29, 2026

   Contributor

   More actions

   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.
9. etraut-openai

   closed this as completedon Jun 29, 2026