Guys it’s been many months and this is still persistently an issue.
I’ll just be using the editor as normal, agent making code updates and a file will suddenly appear altered with lines of diffs that were previously committed.
As an OCD person I then have to check line for line in my git repo to ensure these were actually already committed, and it’s safe for me to “keep file” or keep each line.
Trouble is if I were to accidentally hit “undo”, those lines would go away and my code wouldn’t compile. Then I’d be totally screwed and have to unwind the mistakes. I cannot remember when each line was added and whether it’s current.
This is a serious flaw in the product right now. It also got much worse after the new Agents window came about, i started using that and then I’d open the Editor window to a storm of old diffs.
PLEASE ADDRESS THIS.
Steps to Reproduce
Just use agents to alter code as normal.
Expected Behavior
Committed code should stay committed and not pop up again as a diff I have to accept or undo.
This has been happening for months. It’s a known issue. And seriously breaks workflow because it happens silently and then all of a sudden I’m confused which code we were actually editing.
Also, it seems the Agent can’t see the diffs (see screenshot).
If I “Keep File” it jumps me to other files with stale diffs, and in one case, no visible diffs on the code itself but a “1 of 124” with a keep file in the header.
I selected keep all files, and this popped up in the corner.
Lately I haven’t been accepting diffs because git commit seemed to auto-accept them. Perhaps that’s not the proper behavior in Cursor and causes them to come back erratically.
That popup confirms it: those green marks were Cursor’s inline-diff review layer, not git. Here’s the mental model:
When the agent edits a file, the change is written to disk immediately. The inline diff is just a review overlay on top of already-applied edits.
“Keep” doesn’t apply changes — it just clears that review overlay. That’s why some files showed “keep” with no visible diff: the edit was already on disk (and in your case already committed), so there was nothing to change, only review state to dismiss.
Git always operates on the on-disk file, which already contained the edits. So your commit captured everything correctly regardless of whether you’d “kept” anything. We verified this — git diff HEAD was empty.
So git commit was never auto-accepting in the git sense; it just didn’t need to. The edits were already there. The review markers lingering (and seeming to “come back” on reload) is independent of git — they stay until you Keep/Undo them.
Hey, thanks for the detailed report. The explanation the agent gave you in the last message is actually correct, and you should rely on it.
In short, those green markers are an inline-diff review layer (a visual overlay in the editor), not Git. The agent writes changes to disk right away, and the overlay just sits on top as a reminder that you still need to review something. So:
The agent can’t “see” those diffs. It reads the real file content and git status, and everything is clean there. There are no real pending changes.
Keep doesn’t apply changes. It only removes the overlay. For a file that’s already committed, this is safe. The content won’t change because it already matches what’s in Git.
One important note about your concern with Undo. On this kind of phantom diff, Undo can be risky because it may revert lines back to an older saved snapshot. So to clear these stuck markers, use Keep, not Undo.
As for the bug itself, yes, it’s a known issue. The persisted review state doesn’t always fully clear on accept or commit and can show up again after a reload or when switching windows. That’s why you see a storm of old diffs when moving from the Agents Window back to the editor. It’s being tracked, but I can’t share an exact fix timeline yet. When there’s an update, I’ll post it in the thread.
