apply_patch deletes a file when Move to matches the source

Open
#34,210 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
rust
Domain
cli

Research direction

Start by reproducing the same-file move with the apply_patch command shown, then inspect the move branch in the codex-apply-patch package. Run just test -p codex-apply-patch and add or verify a CLI regression test; done means the command leaves foo.txt present with content after without regressing other move behavior.

Written by the indexing model from the issue text.

Description

bug CLI tool-calls
What version of Codex CLI is running?

Source build from main at 312caf176a8fd3a5897a3d1fd3ed0a283bd1b5ac.

What subscription do you have?

N/A — direct source-level reproduction.

Which model were you using?

N/A — the failure reproduces by invoking the apply_patch binary directly.

What platform is your computer?

Darwin 25.5.0 arm64 arm

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

VS Code integrated terminal.

Codex doctor report

Not applicable for this direct source build reproduction.

What issue are you seeing?

apply_patch reports a successful update and then deletes the file when *** Move to: names the same path as *** Update File:.

  • Observable sequence: start with foo.txt containing before, then update and move foo.txt to foo.txt.
  • Expected: foo.txt remains present with content after.
  • Actual: apply_patch reports success, then foo.txt is missing.
Actual screenshots

Before — upstream 312caf176a: success is reported, then both cat and ls show that foo.txt was deleted.

Upstream apply_patch reports success and deletes foo.txt

After — the same base revision with the focused local patch: success is reported, cat prints after, and ls confirms that foo.txt remains present.

Prepared apply_patch fix preserves foo.txt with updated contents

What steps can reproduce the bug?

Build the current source and run this in a temporary directory:

printf 'before\n' > foo.txt

/path/to/apply_patch '*** Begin Patch
*** Update File: foo.txt
*** Move to: foo.txt
@@
-before
+after
*** End Patch'

cat foo.txt
ls -l foo.txt

The command exits successfully and prints:

Success. Updated the following files:
M foo.txt

Both follow-up commands then report that foo.txt does not exist.

What is the expected behavior?

A same-file move should either apply as an in-place update, leaving foo.txt present with content after, or reject the patch before mutating the file.

Additional information

The move branch writes new_contents to the destination and then unconditionally removes the source. When the resolved source and destination are the same file, that removal deletes the file that was just updated.

The earlier report #6358 was closed because the bug was thought to be no longer relevant, with a request to open a new report if it reproduced on the latest version. It still reproduces on current main.

A focused patch is prepared that:

  • treats exact or canonical same-file moves as in-place updates;
  • skips source removal for that case;
  • adds a CLI regression test proving the file remains and contains after.

Validation completed:

  • just test -p codex-apply-patch: 87 passed;
  • just fix -p codex-apply-patch;
  • just fmt.

I have a focused patch prepared and can open it once given the green light.

Dominant language
Rust
Stars
125k
Forks
19.5k
Avg merge
1m
Merged PRs (30d)
1k

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.