Apply Patch Bug

What version of Codex CLI is running?

codex-cli 0.120.0

What subscription do you have?

Business

Which model were you using?

5.3

What platform is your computer?

Ubuntu

What terminal emulator and version are you using (if applicable)?

kitty

What issue are you seeing?

• Subject: functions.apply_patch fails with ENOENT while shell apply_patch works

Hi Codex Technical Team,

I’m reporting a reproducible issue with the MCP functions.apply_patch tool.

## Summary

functions.apply_patch fails immediately with:

Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })

However, the underlying apply_patch executable exists and works correctly when invoked directly from shell with the same patch content.

## Environment

• Repo path: /opt/bot_last_version
• Date observed: 2026-04-12
• Shell: bash
• Sandbox mode in session: danger-full-access
• Approval policy: never

## Reproduction

1. Call functions.apply_patch with minimal payload:

• *** Begin Patch
• *** Add File: .apply_patch_probe
• +probe
• *** End Patch

1. Observe immediate failure:

• Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })

1. In shell, run equivalent patch:

cat <<'PATCH' | apply_patch
* Begin Patch
* Add File: .apply_patch_probe_shell
+probe
*** End Patch
PATCH

1. Observe success:

• File created successfully.

## Additional verification

• command -v apply_patch resolves to:

/home/utente3/.codex/tmp/arg0/codex-arg0wFKksz/apply_patch

• That path is a symlink to:

/opt/npm-global/lib/node_modules/@openai/codex/node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/codex/codex

• Binary exists and is executable.
• Other write operations in session work (file edits, lint/format checks).

## Expected behavior

functions.apply_patch should apply valid patches exactly as shell apply_patch does.

## Actual behavior

Only the MCP functions.apply_patch call fails with ENOENT; shell invocation succeeds.

## Impact

• Breaks standard patch-edit workflow via tool API.
• Forces fallback to shell editing, reducing reliability and traceability of expected tool usage.

Please investigate the MCP tool bridge/runtime wrapper path handling for functions.apply_patch in this environment.

Thanks.

What steps can reproduce the bug?

Uploaded thread: 019d6bc2-859e-7350-a509-feaab54c57b9

Use this exact repro sequence:

1. Confirm Codex version:

• codex --version
• Expected in our case: codex-cli 0.120.0

1. Trigger functions.apply_patch with a minimal patch:

• Payload:
• *** Begin Patch
• *** Add File: .apply_patch_probe
• +probe
• *** End Patch
• Result: fails with

Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })

1. Verify binary exists:

• command -v apply_patch
• ls -l "$(command -v apply_patch)"
• (In our run it resolved to /home/utente3/.codex/tmp/arg0/.../apply_patch symlinked to Codex binary)

1. Run equivalent patch directly in shell:

cat <<'PATCH' | apply_patch
* Begin Patch
* Add File: .apply_patch_probe_shell
+probe
*** End Patch
PATCH

• Result: succeeds, file is created.

1. (Optional cleanup)

• rm -f .apply_patch_probe .apply_patch_probe_shell

This reproduces the mismatch: MCP tool path fails, shell invocation works.

What is the expected behavior?

• Expected behavior:

• functions.apply_patch should successfully apply any valid patch payload (same grammar accepted by the CLI apply_patch command).
• Behavior should be equivalent to shell apply_patch for the same patch text:
• file create/update/delete should succeed,
• return success with affected file list,
• fail only for invalid patch syntax/content (not with ENOENT when binary/path exists).

In short: MCP functions.apply_patch and shell apply_patch should be functionally identical for valid input.

Additional information

_No response_