The agent says it edited the file, but git diff shows nothing
Any AI coding tool Last checked 2026-10-24
The agent almost always wrote to a different path than the one git is tracking — a stale cwd, a symlink, a second checkout, or a gitignored copy — not a phantom edit. Diff the exact absolute path it reported, then check git status --ignored and pwd inside the agent's shell.
What you saw
The agent reports success — "Updated src/utils/auth.ts" — but git diff or git status shows the file as unmodified, or shows no file at all.
Sometimes the edit is visible in the editor for a few seconds and then disappears, or is there on disk but git diff is empty even though the bytes clearly changed.
Re-running the same instruction produces the same "success" message every time, with git still silent.
What it actually means
Git only reports changes to files inside the repo it is tracking, at the exact path it knows about. There are four common ways an agent's "successful" write ends up invisible to it:
- Working-directory drift. The agent's shell tool calls run from a different cwd than you think — a previous
cd in a dropped tool call, a sandboxed shell that resets between calls, or a monorepo with two packages of the same filename. It wrote packages/web/src/auth.ts while you were looking at apps/web/src/auth.ts. - A second, untracked copy. Build output, a
dist/ or .next/ cache, or an editor's autosave/backup file is what actually got edited, and it is gitignored or simply not part of the tree you are diffing. - Symlinks. If the path is a symlink into another checkout (common with workspace tools and some monorepo setups), the write lands in the real file's repo, not the one you are standing in.
- Something reverted it after the fact. A formatter, a file watcher with hot-reload, or an IDE's "revert on external change" setting can undo an edit within the same second it was written — this looks identical to "nothing happened" unless you catch it mid-flight.
The agent is not lying about writing bytes somewhere; the mismatch is between where it wrote and where you are checking.
The fix
Make it state the absolute path it wrote to, then diff that exact path — not the one you assumed:
Print the absolute path of the file you just edited (pwd + relative path), and the output of `git -C <that path's repo root> status` for it.
Check for untracked or ignored copies in case the real file is being shadowed:
git status --ignored
find . -name "auth.ts" -not -path "*/node_modules/*"
Rule out a symlink:
ls -la src/utils/auth.ts
readlink -f src/utils/auth.ts
Rule out a revert-after-write race from a watcher or formatter by diffing immediately after the write, before any save-triggered tooling runs:
git diff -- path/to/file.ts # run this yourself, right after the agent reports success, before anything else touches the file
If it is cwd drift in a monorepo, pin the working directory explicitly in every instruction rather than trusting it to remember:
Run all commands with cwd fixed to the repo root; before any edit, print `pwd` and confirm it matches /absolute/path/to/repo.
How to stop it happening again
Commit (or at least git add -N . to stage intent) before a multi-file agent task, so git status after the run shows every touched path, tracked or not.
Avoid symlinked paths inside the directory an agent is told to work in; point it at the real path instead.
Turn off "revert on external change" / auto-reload in your editor while an agent is actively editing — it is a frequent, silent source of this exact symptom.
In monorepos, have the agent print its resolved absolute path before every write, not just the relative path you gave it. The cost is one extra line of output; the payoff is catching cwd drift immediately instead of after the task is "done".
Related questions
Could the agent be fabricating the success message?
Rarely, and it is easy to rule out: ask it for the exact absolute path and the byte count or last-modified time of the file it wrote, then check that path yourself with stat. If that file really did change, the mismatch is in where you are looking, not whether a write happened.
What if `git status --ignored` shows nothing either?
Search the whole filesystem for the filename outside the repo — some sandboxed agent shells mount a separate scratch directory that looks identical to your project path but is not the same filesystem location.
A formatter or linter is auto-fixing the file right after the agent edits it — is that the same bug?
No, that is a real edit followed by a real second edit, and git will show both if you look right after each step. It only looks like "no change" if you diff after the formatter has already reverted the agent's change back to the original — check your format-on-save and lint-on-save rules for an auto-revert or auto-fix that undoes the specific thing the agent changed.