apply_patch Add File silently overwrites existing files
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 Fileshould 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.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗