apply_patch Add File silently overwrites existing files

Open 💬 4 comments Opened May 31, 2026 by Isoceth

What version of Codex CLI is running?

codex-cli 0.135.0

Which model were you using?

N/A. This reproduces through apply_patch directly and does not depend on model behaviour.

What platform is your computer?

Linux 7.0.10-2-cachyos x86_64

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

xterm-256color, shell /bin/fish

What issue are you seeing?

apply_patch treats *** Add File as an overwrite operation when the target path already exists.

This appears to contradict the Codex apply-patch tool contract. The tool instructions describe *** Add File: as creating a new file, but the current behaviour accepts an existing file path and replaces its contents without warning.

This matters because it appears to be the harness/tool-level cause behind #10037, where *** Add File was used on a .env path that already existed as a symlink. The tool followed the symlink and overwrote the target contents. That issue was discussed partly as model behaviour, but the dangerous part is reproducible without the model: Add File does not fail when the file already exists.

What steps can reproduce the bug?

Create a disposable file:

tmpdir="$(mktemp -d)"
printf 'original line 1\noriginal line 2\n' > "$tmpdir/existing.txt"
nl -ba "$tmpdir/existing.txt"

Apply an Add File patch to the same existing path:

*** Begin Patch
*** Add File: /tmp/.../existing.txt
+new content
*** End Patch

Observed result:

Success. Updated the following files:
A /tmp/.../existing.txt

The file is overwritten:

new content

There is no warning that the target already existed, and the summary reports it as added rather than overwritten.

What is the expected behavior?

*** Add File should fail if the target path already exists.

Suggested stricter semantics:

  • Add File / create should fail when the path exists.
  • Update File should fail when the path does not exist.
  • Overwrite should require an explicit operation or explicit flag.
  • If an overwrite is intentionally allowed, the success summary should say that an existing file was overwritten.

This is especially important for symlinked paths. A create operation should not silently follow a symlink and replace the linked target.

Additional information

Related issue: #10037

In that issue, a .env file in the workspace was a symlink to a file outside the workdir. Codex used *** Add File and the existing target contents were replaced. The reporter lost existing env vars and noted that this seemed like a harness issue rather than model training.

The current behaviour also makes audit trails misleading: A path suggests creation, while the actual operation can be destructive replacement.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗