Whenever the Agent makes multiple edits on a file within a request, by the time it’s done, it would have accepted some of it’s own changes, so I don’t see them as changes, and I don’t get the chance to reject or accept it. In fact, I’d easily miss the changes unless I do a git diff. And a git diff would be useless to detect it if I already had other uncommitted changes.
This issues has previously plagued me around May 2025, however I managed to stop it by disabling the “Should Auto Accept Diffs” setting (see screenshot). Now, just yesterday (17th February) Cursor made a release and that setting was removed from the new version (I can see it in the changelog). And just like that, the problem has come back but now there is no setting to disable it.
Steps to Reproduce
Open a workspace with multiple root folders. Ask the agent to make any set of changes on multiple files where one of the files gets edited multiple times by the agent. By the time the agent is done, some of the changes it made to the file would have been automatically accepted.
Expected Behavior
Once the agent is done editing files, no changes should be auto-accepted. I should accept them myself.
This is a known tricky area. When the agent makes several edits in the same file, some changes can get silently auto accepted before you have a chance to review them.
For now, could you check the Developer Tools console (Help > Toggle Developer Tools) right after the agent finishes editing a file with multiple changes? Please look for any errors that start with [composer]. That will help us narrow down the cause.
Also, can you confirm if this only happens in multi root workspaces, or have you been able to reproduce it in a single root workspace too?
I’m seeing the same issue: some edits get applied and effectively accepted implicitly, without being shown for explicit review/approval.
This is absolutely critical for my workflow. The primary reason I use Cursor is to review and explicitly accept every change it makes. That review step is the only guarantee that all code is inspected during development—not pushed down to the commit stage.
Implicit acceptance of code breaks that guarantee and severely undermines trust in the IDE as a trust anchor. Cursor’s review/accept flow must be reliable and complete.
NOTE: Since the time I posted the issue, I have reverted to the previous version of cursor (Version: 2.4.37) to be able to sanely use the App. However, I can still reproduce the issue anytime I want by enabling the “Should Auto Accept Diffs“ setting.
After the issue occurred here’s the log I’m seeing:
workbench.desktop.main.js:34226 [composer] Could not find old HEAD SHA in current history
getFilesCommittedSince @ workbench.desktop.main.js:34226
workbench.desktop.main.js:34226 [composer] Could not determine files committed since last seen HEAD, clearing git tracking state
workbench.desktop.main.js:674 [composer] updateReactiveCodeBlock called for codeblockId that does not exist
Xot
tool_3a408986-9517-4ccc-b2a5-355a230b889
updateComposerCodeBlock @ workbench.desktop.main.js:674
(anonymous) @ workbench.desktop.main.js:55
aRo @ workbench.desktop.main.js:55
Cme @ workbench.desktop.main.js:55
i.value @ workbench.desktop.main.js:55
_storePartialInlineDiffFates @ workbench.desktop.main.js:674
In this case, it didn’t even have to edit multiple files. It just had to edit the same file multiple times within one request, and by the time it was done, all of its changes were already auto-accepted.
I can also see some [otel.error] logs but I don’t know if those would be relevant to your investigation. Please let me know if you need them as well.
Also, I don’t know if it happens in single root workspaces because I don’t use single root. I just know it has been hard for me to find other people who experience this issue, and most people I’ve asked use single root workspaces, so I thought it might be relevant for me to mention that my workspace is multi-root just in case that’s the isolating difference.
I’ve noticed this regression too within the last 1 or 2 releases, super annoying, first bug that’s stood in my way for a long time.
I’m on linux, and using only one workspace.
Actually a similar issue I’ve seen for a long time is the “Review Next File” button going off to a diff from long-times past, long since accepted and not actually outstanding.
i’ve had this happen where i go to review and half the changes are already applied. the part that gets me is there’s no way to tell after the fact which ones were auto-accepted vs which ones you actually clicked through. i end up doing a git diff after every agent run now just to make sure i didn’t miss something.
Should not have to do this, but I am just going to move on and get back to work. When my subscription renewal comes up, I will test out some cursor alternatives before committing to Cursor again. For all I know, all the alternatives break stuff like this too.
Edit:
Be sure to make this setting change after downgrading
Honestly, this was the last straw for me with Cursor. If EASY to find things like this are making it through QA I don’t think I can trust the underlying stuff that isn’t so obvious to be right.
Not only that but this specific bug should’ve been an immediate rollback for Cursor if they couldn’t get a fix out. Without code highlighting and now having forced auto accept the entire purpose of the Cursor app is moot.
sigh… at least I’ll save the $60 a month. CoPilot is free with my work login.
I have the same problem, only worse: AI (e.g., Sonnet 4.6) makes changes, and Cursor doesn’t show what has been changed in the editor. Cursor team, please fix this bug soon because we need to see and accept or reject the changes that are made!
Thanks everyone. The errors [composer] Could not find old HEAD SHA and updateReactiveCodeBlock called for codeblockId that does not exist directly point to a change tracking issue.
Confirmed: the bug also reproduces in single-root workspaces (as others noted in the thread), so it’s not specific to multi-root.
It’s the same issue as in this thread. The team is aware.
Until a fix is released, rolling back to 2.4.x and turning off “Should Auto Accept Diffs” is a solid workaround, like you already did.
