codex - 💡(How to fix) Fix apply_patch Add File silently overwrites existing files

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

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.

Fix Action

Fix / Workaround

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

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.

Code Example

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

---

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

---

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

---

new content
RAW_BUFFERClick to expand / collapse

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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix apply_patch Add File silently overwrites existing files