codex - 💡(How to fix) Fix functions.apply_patch fails with No such file or directory after patch approval even though apply_patch works via shell [1 comments, 2 participants]

*** Begin Patch
*** Add File: /tmp/codex-apply-patch-probe.txt
+probe
*** End Patch

Observed behavior:

- patch approval is requested
- approval is accepted
- the tool fails with:

codex_core::exec: exec error: No such file or directory (os error 2)
codex_core::tools::router: error=execution error: Io(Os { code: 2, kind: NotFound, message: "No such file or
directory" })

Relevant log excerpt from ~/.codex/log/codex-tui.log:

2026-04-14T11:11:37.849437Z ... ToolCall: apply_patch *** Begin Patch
*** Add File: /tmp/codex-apply-patch-probe.txt
+probe
*** End Patch
...
2026-04-14T11:11:39.781642Z ... codex.op="patch_approval"
2026-04-14T11:11:39.785506Z ERROR codex_core::exec: exec error: No such file or directory (os error 2)
2026-04-14T11:11:39.793360Z ERROR codex_core::tools::router: error=execution error: Io(Os { code: 2, kind: NotFound,
message: "No such file or directory" })

Control test:

- The same apply_patch executable works correctly when invoked directly via shell with the same patch payload.
- It also works when invoking the vendor binary directly with argv0=apply_patch.

Example shell control:

/home/robertoh/.codex/tmp/arg0/codex-arg0ptO3zX/apply_patch <<EOF
*** Begin Patch
*** Add File: /tmp/codex-applypatch-shell-probe.txt
+probe
*** End Patch
EOF

That succeeds and creates the file correctly.

Why this seems like a Codex tool-runner issue:

- the patch parser itself is healthy
- the apply_patch binary itself is healthy
- the failure happens specifically in the built-in tool path after patch_approval
- this reproduced across multiple threads/projects, not just one repo
- this does not appear to be related to MCP wiring; in the active environment codex mcp list only showed playwright
  and supabase

Current hypothesis:

- the regression is in the internal runner path around functions.apply_patch / patch_approval / internal exec, not in
  the standalone patch binary

Things already ruled out:

- missing apply_patch symlink
- broken vendor binary
- broken shell execution of apply_patch
- missing common executables like git, patch, bash, sh, env, mktemp

Suggested upstream checks:

- log the exact program path and argv used after patch_approval
- check whether the tool path is launching a missing wrapper/helper distinct from the standalone apply_patch binary
- check whether this is a regression in 0.120.0