When Cursor deletes a file and then rewrites it, there is often a chance that duplicate content gets inserted.
What that means is that, at the very bottom, there is the new state being written to the file, while at the very top there is still leftover content from the old file.
You can definitely observe this with an example like the following:
We delete a file with 1,000 lines and replace it with two new lines.
In the Edit_File_Tool or Write_File, whatever it is called, you can see that only those two lines are written and that the operation completes immediately.
However, when you open the file, you can see that the old 1,000 lines are still above them.
So there seems to be an internal error somewhere.
I think the Cursor developers can reproduce this very quickly if they try to recreate it a few times.
I’ve been having this problem for several months now, but it only happens sporadically.
Hey, thanks for the report. It looks like a race condition in how the editor syncs the file contents after a “delete + recreate” operation. The in-memory model keeps the old contents while the new contents are being written.
To help the team investigate, could you next time it happens share:
Request ID: right-click the chat message header (top right of the reply) and select “Copy Request ID”.
This will let us trace the exact tool calls and file operations that led to the duplication.
Also, when you notice the duplication, does a simple undo Ctrl+Z or reverting the file fix it, or does the duplicated content remain even after reopening the file?
The team is aware of similar file sync issues. Your report helps us prioritize, and we’ll update here if there’s progress.
What I noticed is that the Git diff view was definitely present. When there was new content, it was shown in green. The old file content at the top, which should no longer have been there because the file had been deleted, was also shown in green, as if it had been newly added.
If I run into the problem again, I will try to pay attention to that. I do not remember the details exactly from memory right now, and I also did not try it with Control-z.
What I did do was tell my LLM to edit the file again because there had been an editing error, and then it worked.
I can definitely remember similar moments in the past, a few weeks or months ago, when I had the same problem. At that time, I told the LLM that the edit had failed because the content was duplicated and that it should do it again. It then tried to edit the file again and had the same error.
This time, it looked like it was able to edit the file after the error, so that has definitely improved.
It is not a fixed behavior that can always be reproduced. However, if it happens again, I will definitely try to test it with Control-Z.
Sometimes, when editing files, it just stops completely and nothing gets processed. In the chat window on the right, I then only see “end patch” at the end, but nothing has actually happened.
Also, the “duplicated data” issue from that article seems to occur quite normally when editing files as well, even without them having been deleted beforehand.
That means it appears to be a fundamental single-source-of-truth problem, independent of whether the files were deleted beforehand or are simply being edited.
I see the screenshot. It looks like the patch for directory-names.contracts.ts got cut off at “End Patch” and didn’t apply. Also, your note that duplication happens during normal editing too (without deleting) is a really helpful detail, it helps narrow this down.
Can you send the Request ID for this specific “End Patch” case? Same way as before: right click the message header in chat, then Copy Request ID. We already have the previous ID for the duplication issue, but we’d like a separate one for this case.
