After choosing “apply all changes”, if continuing to modify the (same) code in the same agent window, the summary, for some reason, includes all the previous history that was already accepted. Clicking “apply all” for this new summary creates merge conflicts in some cases. This possibly happens only in multi-agent chats, where the agents’ workspaces are separate from the main workspace.
Steps to Reproduce
(IIRC)
Start a multi-agent session in Ask mode. (I used Opus 4.5, Gemini, and a couple of OAI GPTs)
Switch to agent mode for one of the chats (I chose Opus 4.5) and ask to make the changes based on the answer. (From now on only interact with this chat window.)
Choose to apply all the changes.
Continue chatting in the same (Opus) chat window and ask for more changes for the same files (possibly something that changes the previously-applied changes).
First problem: The summary lines (+ and -) also includes all the changes you’ve already applied (even for files you haven’t edited in this second change).
Second problem: Clicking “apply all” for the second batch of modifications can create “merge conflicts”, popping up a window that asks how you want to resolve them. Where in fact, there shouldn’t be any merge conflicts, because you had a single agent working sequentially on the same code.
Expected Behavior
Summary should include only the last changes that were not applied yet.
Applying the second batch of edits after applying the first batch should not cause any merge conflicts, as it’s the same agent working on the same (updated) code, sequentially.
Operating System
Windows 10/11
Current Cursor Version (Menu → About Cursor → Copy)
Hey, thanks for the report. This is a known issue. The team is already working on a fix for the bug where the summary includes already applied changes when working with multi-agent chats.
Could you share a bit more info for the engineering team:
The Request ID from the problematic session (chat top-right context menu > Copy Request ID)
A screenshot of the summary that shows duplicated already applied changes
Confirmation: does this only happen when agents run in separate workspaces from the main one?
Temporary workaround: try creating a new agent chat after applying the first batch of changes instead of continuing in the same window.
An example request ID is this: 1ea387e2-3230-4115-b6a3-7ad4796241bb
For example, I got there a merge conflict on progress.md, where the second “apply all” tried to change some of the text that was (supposed to be) inserted by the first “apply all”.
Unfortunately, I can’t provide any screenshots of the summaries (where the “apply all” button is shown), since it doesn’t show it anymore, after applying the changes. (I’m talking about the summary where it shows one line for each file, with the counts.)
I started a new mock project and made a simple test trying to reproduce both erroneous behaviors with a single agent, but everything was ok. I suspect that’s because it works directly on the actual workdir with the original files, and not on copied files in a per-agent workspace.
The workaround you suggested is indeed what I use. The problem with that is the loss of the entire context, which could’ve been valuable for finding the correct solution.
Another workaround I use (when context is critical) is to not apply the changes, but continue asking the agent to modify the code without applying anything, and only apply the changes at the end. This has its own drawbacks (like, what if you want to revert only the last changes?)