[WSL2] apply_patch hangs; Esc + two Ctrl+C required to exit session
Open 💬 10 comments Opened Nov 21, 2025 by maha0525
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of Codex is running?
0.61.0 and 0.62.0-alpha.3
What subscription do you have?
plus
Which model were you using?
gpt-5.1-codex-max
What platform is your computer?
Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64
What issue are you seeing?
- apply_patch hangs consistently on WSL2.
- After Esc, Ctrl+C once just prints the footer; a second Ctrl+C is needed to exit.
Summary
On WSL2, apply_patch hangs. To break out, I must press Esc to return to the conversation prompt. After that, pressing Ctrl+C once shows the “Token usage … To continue this session, run codex resume …” footer, but the Codex process stays alive; I must press Ctrl+C a second time to exit to the shell.
Please investigate the WSL bridge / IPC for apply_patch and its SIGINT handling.
What steps can reproduce the bug?
- Start Codex
- Ask Codex to apply a tiny patch (e.g., change the single line in .apply_patch_test from patched_twice to patched_test).
- apply_patch hangs and times out (~60s).
- Press Esc to return to the conversation prompt.
- Press Ctrl+C once: footer appears
Token usage: ...
To continue this session, run codex resume <session-id>
but the process remains.
- Press Ctrl+C again: only then does the process exit to the shell.
What is the expected behavior?
- apply_patch should complete quickly.
- If Esc + Ctrl+C is used, the session should terminate after the first Ctrl+C; no second Ctrl+C should be necessary.
Additional information
- Regular edits via patch/sed/python - <<'PY' are instant; only apply_patch hangs.
- VS Code closed during repro.
10 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Facing the same issue after the 0.63 update. apply_patch hangs for hours with no way forward
I am using on both a Linux and MacOS
Other steps of codex works but only apply_patch gets hanged for hours on Linux/RHEL
this bug is madening
can you fix this?
v0.65.0
still hanging...
Are you still seeing this behavior? I think it may have been fixed but would like to get a confirmation.
I didn't see this for months, but it's back now (
codex-cli 0.147.0)Still reproducible on Codex CLI 0.147.0 under WSL2:
Linux 6.18.33.2-microsoft-standard-WSL2 x86_64apply_patchcommand is a symlink to the Codex multicall binary:.../.codex/tmp/arg0/.../apply_patch -> .../@openai/codex-linux-x64/.../bin/codexfunctions.apply_patchcall with a tiny patch remained running indefinitely with no output or filesystem change.ps -eo pid,ppid,stat,wchan,cmdshowed the patch/Codex process sleeping indo_epoll_wait, consistent with waiting for input.``
``Usage: apply_patch 'PATCH'
echo 'PATCH' | apply_patch
This suggests the patch shim itself works, but in the failing path the tool/command transport launches it without delivering the patch body or closing stdin. A useful place to inspect may be the code-mode-host/custom-tool bridge that maps the
functions.apply_patchpayload into stdin/argv, especially lifecycle handling around stdin close. A timeout/fail-fast when no patch body arrives would also prevent the indefinite hang.