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.

• #4824
• #4878
• #4584
• #1308
• #2607

Powered by Codex Action

Please use the /feedback command to upload your logs and session details, then post your thread ID here.

019bbd13-a821-7a93-abe2-d1afa5733ae7

Thanks for reporting. Looking at your logs, it appears that the compaction request exceeded a 30-second timeout. The CLI retried multiple times but hit the same timeout each time until it gave up.

So far, this is the only report of this that we've received. If you (or anyone else) sees it again, let us know.

it happened again, just for you to know thread ID 019bc34c-e247-7341-b2db-06f62d55bf57

@ECamposSoria, thanks for reporting. Are you on a corporate network/VPN/proxy that you know of? We don't set an explicit timeout ourselves, so trying to see what's terminating the connection.

reproduced with thread: 019c83e7-5d40-7331-8572-7dad7fe4cb3c. (vm, screen lock due to inactivity, with vpn)

reproduced too, thread 019ca5b7-aa9c-79d3-8866-a5fdf7bcd9dc

Hi everyone, I encountered the exact same Error running remote compact task: timeout waiting for child process to exit issue and managed to find a working workaround.

💡 The Workaround:
Delete the SQLite temporary files (-wal and -shm) in the .codex directory.

🛠️ Steps:

Open your terminal and navigate to the Codex data directory (usually ~/.codex).

Delete or rename state_5.sqlite-wal and state_5.sqlite-shm:

cd ~/.codex
rm state_5.sqlite-wal state_5.sqite-shm
Restart Codex. The auto-compact task should now proceed normally.

the workaround does not resolve this for me unfortunately.

Hi all, I'm experiencing the same issue and it only happens when connected to my VPN (Surfshark dedicated IP). Then it seems to always fail auto compacting on large sessions, resulting in "_Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)_". When disconnecting, or not connected to, the VPN, the auto compacting completes without any issues.

Just had it again: Large session going on while connected to VPN -> Fails (error message above) -> Disconnecting VPN -> "Yo try again and continue" -> [working working] -> "_Context compacted_" - and it proceeds with the session.

switching from xhigh bebore saying "continue" helps

Thread ID: 019cf7a8-8b68-7231-9743-7e6fdfdef9a1

Hitting it multiple times on longer tasks

Dealing with this bug every day.

Another thread ID: 019d01dd-ee72-72e1-bb3f-c785c8b3bed1

#14860

ID 019d0517-54f7-7bc0-b372-216a707baf6e

Having this issue on Windows 11:

codex --version
codex-cli 0.116.0

thread id = 019cfd9b-cdfd-7aa1-8ccc-e892831f2d0a

<img width="651" height="345" alt="Image" src="https://github.com/user-attachments/assets/5c5e6e06-7b2d-46d1-857a-71ca8c9b7475" /> How to solve this problem? It feels like waiting is meaningless and a waste of time.

一样的问题 每次报错5次 之后 才能回答问题。

@Beisheng8888 @it-zyf @kaiospitz @w0rk3r

The timeout seems network-related.

Routing egress traffic from my VP through a server in Europe/North America definitely helped.

Using Tailscale, I configured an Azure VM as an exit node through which internet-bound traffic was routed.

I am happy to help if need be.

I just got the same error, and I haven't found how to solve it yet

Same error

Wow.

I think the only option left is recompiling the codex-cli to use a much longer timeout.

It worked for me.

@bakhda777 @Enchanter-W .

See Issue 14860

<img width="368" height="348" alt="Image" src="https://github.com/user-attachments/assets/b88c460e-8468-413b-8cb5-17e169ec933c" />
When can I use codex desktop normally qwq

019dc3b1-687d-72a0-99cf-efc169d1e30f

019e02a3-e2fd-7e41-9997-c9968546709f

一样的问题 每次报错5次 之后 才能回答问题。

Me too. I'm running codex on WSL2

019ebd34-ce2f-7a23-aeec-79afd8d3a89a

Is this ever getting fixed? I'm kinda tired of compiling it with a higher timeout every release

cc @etraut-openai @tibo-openai

read this: https://maplememo.com/codex-timeout-waiting-for-child-process-to-exit-fix/#%E5%AE%9F%E9%9A%9B%E3%81%AB%E3%82%84%E3%82%8B%E5%88%87%E3%82%8A%E5%88%86%E3%81%91%E6%89%8B%E9%A0%86

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.