apply_patch Add File silently overwrites existing files

Hi, I’d like to work on this. I’ll submit a PR shortly.

I implemented a fix on a fork branch, but GitHub is blocking PR creation for me with nightcityblade does not have the correct permissions to execute CreatePullRequest. I do not want to leave this claimed, so I am unclaiming it. Branch for reference: https://github.com/nightcityblade/codex/tree/fix/issue-25399

I added a small external guard for this exact failure mode in case it helps people validate generated patches while the Codex-side semantics are being fixed.

It fails before applying a patch when:

• *** Add File targets a path that already exists, including symlinks
• *** Update File or *** Delete File targets a missing path
• *** Move to would overwrite an existing destination

Try it on a disposable patch file:

npx trace-to-skill@latest guard-patch ./change.patch --root . --format json

For this issue class, the expected result is a non-zero exit with JSON like:

{
  "status": "fail",
  "findings": [
    {
      "operation": "add",
      "target": "existing.txt",
      "message": "Add File target already exists; use Update File or remove the file first."
    }
  ]
}

Public fixture/demo for the report shape:

npx trace-to-skill@latest demo patch-overwrite --format json

Release notes: https://github.com/grnbtqdbyx-create/trace-to-skill/releases/tag/v0.1.53

I reproduced this against current main with the standalone codex-apply-patch binary.

Repro shape:

printf 'original line 1\noriginal line 2\n' > existing.txt
cargo run -q -p codex-apply-patch --bin apply_patch -- '*** Begin Patch
*** Add File: existing.txt
+new content
*** End Patch'

Observed result: the command succeeds, reports the path as A, and the previous file contents are replaced by new content.

I also found this behavior encoded in the existing fixture codex-rs/apply-patch/tests/fixtures/scenarios/011_add_overwrites_existing_file: the input has duplicate.txt with old content, the patch uses *** Add File: duplicate.txt, and the expected output is the new content.

Root cause in current code: codex-rs/apply-patch/src/lib.rs handles Hunk::AddFile by calling read_optional_file_text_for_delta, then write_file_with_missing_parent_retry, and records the change as AppliedPatchFileChange::Add { content, overwritten_content }. There is no existence guard before the write, and the summary path is still pushed into added, so the user-visible result says A even when an existing file was overwritten.

Why this seems P0/high severity: Add File is a tool contract that normally means fail-if-exists. Silent overwrite is data-loss risk, and the symlink case mentioned in #10037 makes it more dangerous because the affected target may not be the visible path the model/user expected to create.

Minimal fix shape: make Add File fail when the destination already exists or is a symlink. If overwrite is intentionally supported, it should require an explicit operation/flag and report as an overwrite/modify, not A. Regression coverage should include at least an existing regular file and a symlink path.

Per docs/contributing.md, I am not opening an unsolicited PR; I can submit a focused patch if a maintainer says this direction is welcome.

This is a dangerous semantic mismatch. Add File should be fail-if-exists; a destructive overwrite must require an explicit operation and be reported as a modification, never as A.

The current behavior can silently destroy unrelated data through symlinks, as in #10037, especially when the model does not recognize that the apparent path is a symlink.