functions.apply_patch fails with No such file or directory after patch approval even though apply_patch works via shell

functions.apply_patch is failing consistently in my local Codex environment after patch approval.

Environment:

• Codex CLI: 0.120.0
• Install source: global npm package @openai/codex@0.120.0
• OS: Linux x86_64, WSL2
• Bubblewrap: 0.9.0

What fails:

• A normal built-in apply_patch tool call
• Even a minimal patch that adds a one-line file in /tmp

Minimal repro:
```text
* 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