[BUG] File-history system auto-restores tracked files deleted by Bash mv command

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When Claude edits a file using the Edit tool, the file becomes tracked by the file-history/checkpointing system. If a subsequent Bash mv command renames/moves that file, the source file is automatically restored from backup within ~60 seconds, resulting in both the original and destination files existing simultaneously.

This is unexpected behavior that:

1. Causes confusion when the user sees both files
2. Requires a manual rm command to actually delete the original file
3. Contradicts the documented behavior that "Bash command changes are not tracked"

What Should Happen?

When a Bash mv command successfully moves/renames a file, the source file should remain deleted. The file-history system should either:

• Not auto-restore files deleted by Bash commands, OR
• Update its tracking to recognize the file was renamed (not deleted)

Error Messages/Logs

No error messages - the `mv` command reports success:


$ mv -fv /path/to/write-new-issues.txt /path/to/verify-draft-issues-prompt.txt
/path/to/write-new-issues.txt -> /path/to/verify-draft-issues-prompt.txt


But ~60 seconds later, both files exist:


$ ls -la *.txt
-rw-r--r--@ 1 user  staff  2606 Jan 24 13:42 verify-draft-issues-prompt.txt
-rw-r--r--@ 1 user  staff  2606 Jan 24 13:43 write-new-issues.txt


Note the 1-minute difference in timestamps - the original file was recreated.

Steps to Reproduce

1. Start a Claude Code session in a directory with a text file (e.g., original.txt)
2. Ask Claude to edit the file using the Edit tool (this causes Claude Code to track the file in file-history)
3. Ask Claude to rename the file using Bash: mv original.txt newname.txt
4. The mv command reports success
5. Wait ~60 seconds
6. Run ls -la - both original.txt AND newname.txt exist
7. The original file was auto-restored from file-history backup

Observed in session: 4189638e-c99d-427e-9448-70eac7964bba

Timeline from session transcript:

• 21:42:48 UTC - Edit tool modified write-new-issues.txt (file tracked, v3 backup created)
• 21:42:54 UTC - mv -fv command executed successfully
• 21:42:59 UTC - Grep confirmed file was gone ("No matches found")
• 21:43:xx UTC - File auto-restored (timestamp shows 13:43 = 21:43 UTC)
• 21:44:14 UTC - User noticed both files exist, asked "why do i see 2 files then?"
• 21:44:14 UTC - File-history recorded v4 backup of the restored file

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.19

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

File-history backup evidence

The file-history backups show the file was tracked and backed up multiple times:

$ ls -la ~/.claude/file-history/4189638e-c99d-427e-9448-70eac7964bba/456bdc92d4463e15@*
-rw-r--r--@ 1 user  staff  2479 Jan 24 13:39 456bdc92d4463e15@v1
-rw-r--r--@ 1 user  staff  2507 Jan 24 13:40 456bdc92d4463e15@v2
-rw-r--r--@ 1 user  staff  2471 Jan 24 13:42 456bdc92d4463e15@v3  <- backup before mv
-rw-r--r--@ 1 user  staff  2606 Jan 24 13:44 456bdc92d4463e15@v4  <- backup of restored file

Documentation conflict

The checkpointing documentation states:

Bash command changes not tracked Checkpointing does not track files modified by bash commands. For example, if Claude Code runs mv old.txt new.txt - These file modifications cannot be undone through rewind.

This suggests Bash changes shouldn't affect tracked files, but auto-restoration appears to be a separate mechanism from manual rewind.

Workaround

Run rm after mv to delete the auto-restored file:

mv original.txt newname.txt && sleep 90 && rm -f original.txt