[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?

  1. Start Codex
  2. Ask Codex to apply a tiny patch (e.g., change the single line in .apply_patch_test from patched_twice to patched_test).
  3. apply_patch hangs and times out (~60s).
  4. Press Esc to return to the conversation prompt.
  5. Press Ctrl+C once: footer appears

Token usage: ...
To continue this session, run codex resume <session-id>
but the process remains.

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

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 9 months ago

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

  • #6417
  • #6959
  • #5931
  • #5905

Powered by Codex Action

amitbcp · 9 months ago

Facing the same issue after the 0.63 update. apply_patch hangs for hours with no way forward

amitbcp · 9 months ago

I am using on both a Linux and MacOS

amitbcp · 9 months ago

Other steps of codex works but only apply_patch gets hanged for hours on Linux/RHEL

denismaciel · 9 months ago

this bug is madening

vborza · 9 months ago

can you fix this?

maha0525 · 8 months ago

v0.65.0
still hanging...

etraut-openai contributor · 5 months ago

Are you still seeing this behavior? I think it may have been fixed but would like to get a confirmation.

jbellis · 15 days ago

I didn't see this for months, but it's back now (codex-cli 0.147.0)

jbellis · 15 days ago

Still reproducible on Codex CLI 0.147.0 under WSL2:

  • Kernel: Linux 6.18.33.2-microsoft-standard-WSL2 x86_64
  • The generated apply_patch command is a symlink to the Codex multicall binary:

.../.codex/tmp/arg0/.../apply_patch -> .../@openai/codex-linux-x64/.../bin/codex

  • A functions.apply_patch call with a tiny patch remained running indefinitely with no output or filesystem change.
  • Reproduced through the shell shim as well when patch text was expected to be delivered over stdin.
  • While hung, ps -eo pid,ppid,stat,wchan,cmd showed the patch/Codex process sleeping in do_epoll_wait, consistent with waiting for input.
  • Sending EOF caused it to exit immediately with:

``
Usage: apply_patch 'PATCH'
echo 'PATCH' | apply_patch
``

  • Invoking the same shim with the complete patch as an explicit argv argument completed immediately and applied the patch successfully.

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_patch payload into stdin/argv, especially lifecycle handling around stdin close. A timeout/fail-fast when no patch body arrives would also prevent the indefinite hang.