Gemini 2.5 pro 06-05 always says that the model did not make the changes or apply them according to its requirements. And Gemini 2.5 pro 06-05 will keep tring to make it works but it never works.
Steps to Reproduce
Here is the issue description by Gemini 2.5 pro:
Description:
I am experiencing an issue where the edit_file tool, even when followed by reapply, is failing to correctly execute a refactoring task on a Python file.
My goal is to refactor the file by replacing three existing methods and completely deleting a fourth one, based on a detailed pseudocode I have.
How I’m using the tools:
Initial Attempt (Bulk Edit): I first used edit_file with instructions to replace the three methods and delete the fourth in a single command.
Expected behavior: The target methods should be cleanly overwritten with the new code, and the specified method should be removed.
Actual result: The tool did not perform a replacement. Instead, it incorrectly merged the new code with the old code inside the methods, creating a syntactically invalid result. It also failed to delete the fourth method.
Second Attempt (reapply): As per standard procedure, I used the reapply tool immediately after the failed edit, hoping the more advanced model would apply the changes correctly.
Actual result: reapply produced the exact same incorrect merge as the initial attempt, offering no improvement.
Third Attempt (Atomic Edit): I then simplified the task by issuing a new edit_file command to replace just one of the methods.
Actual result: The tool failed again, this time corrupting the file’s syntax by introducing Unexpected indentation and Try statement must have at least one except or finally clause errors.
Summary of the problem:
The edit_file tool seems unable to reliably handle the replacement of entire method blocks. Instead of overwriting them, it attempts to merge them, leading to broken code. This issue persists even when using reapply or when breaking the task into smaller, atomic steps.
Operating System
Windows 10/11
Current Cursor Version (Menu → About Cursor → Copy)
I just created account just to support this bug report.
This new model is absolutely failing on editing some files and then keeps changing them. It seems to have big problem with @codebase and context, where it started to create functionality it was using for before that without problem.
This ended up DELETING my data/ folder with critical files.
I explained the situation and it just then rearranged and moved data/ content and DELETED more files.
But, I do support this bug report, because it started with the behavior mentioned here, with edit_file tool. Now I lost 2 days worth of work.
I suspect the new pricing and MAX mode. The Gemini and Sonnet have lower context window (1M cut down to 120k) so it has problem with editing bigger files or multiple parts of a long file.
Model's stuck. I'll force a full file replacement; incremental edits are failing. It's a gamble, but I've rebuilt the file with the necessary changes and hope for the best
I’ve experienced similar issues with the edit_file tool, especially when using Gemini 2.5 pro in the Cursor editor. To address these problems, I’ve summarized a set of specific guidelines that I found very helpful. These rules are tailored for Gemini 2.5 pro and can significantly improve the reliability and predictability of your file edits.
Special edit_file Guide for Gemini 2.5 pro in Cursor
Golden Rule: Treat every edit as a “surgical, precise replacement,” not a “fuzzy adjustment.”
Principle 1: Replace, Don’t Modify
Action Guideline: Target the smallest, complete logical block and provide a brand new block to completely replace it.
DO:
Replace entire lines or whole methods/logical blocks.
Example:
// ... existing code ...
public int CalculateTotalPrice() { /* new, improved logic */ }
// ... existing code ...
DON’T:
Try to only change part of a line or just rename a method in place.
Example:
// ... existing code ...
CalculateNewTotalPrice() // Only changing the method name—very risky
// ... existing code ...
Principle 2: Anchors Must Be Unique
Action Guideline: The context you use as anchors (e.g., // ... existing code ...) must be unique within the file, just like a fingerprint.
DO:
Include enough surrounding context to ensure uniqueness.
Example:
// ... existing code ...
var result = await _service.GetSpecificData(id);
return View(result); // <--- This context combination is likely unique
// ... existing code ...
DON’T:
Use generic or potentially repeated code as an anchor (e.g., just a closing bracket).
Example:
// ... existing code ...
} // <--- Highly likely to be a repeated anchor
// ... existing code ...
Principle 3: Code Must Be Complete
Action Guideline: The submitted code_edit must be a syntactically correct, logically self-contained unit. Don’t make the model guess.
DO:
Make sure the code you submit can be copy-pasted into the IDE without syntax errors.
DON’T:
Submit incomplete statements.
Example:
// ... existing code ...
var user = new User { Name = // <--- Incomplete code
// ... existing code ...
Principle 4: Decompose Complex Tasks
Action Guideline: Large refactors = multiple consecutive, simple, and safe small replacements.
DO:
First edit_file: Add a new helper method.
Second edit_file: Replace the old logic block with code that calls the new method.
DON’T:
Define a new method and change all its usages in multiple places within a single edit_file operation.
Principle 5: Instructions Must Accurately Describe
Action Guideline: The instructions parameter should be a one-sentence, precise summary of the code_edit.
DO:
Example: instructions: "I will replace the user validation logic with a call to the new AuthService."
DON’T:
Use vague instructions like instructions: "Fix bug" or instructions: "Update code" (too broad and not helpful).
Summary:
These guidelines are specifically for Gemini 2.5 pro in the Cursor editor. By following them, I’ve seen a significant improvement in the reliability of edit_file operations. Breaking down complex changes, providing clear and unique context, and making sure each edit is a full, valid code block really helps avoid the common issues mentioned in this thread.
Hope this helps others who are struggling with similar problems using Gemini 2.5 pro in Cursor!
Hmm yeah not for me… Gemini continues to struggle with tool usage. And now it seems that Sonnet is also struggling “The specified string was not found in the file (even after relaxing whitespace). If you are unsure of the exact string to replace or the current file contents, read the file and try again.”
Thanks for the really great info there @yulin0629 , and apologies we didn’t jump in on this yet (this issue landed just before the weekend!).
I’ve just merged a second thread on this issue here, so all the details are in one place.
Would anyone who is not on privacy mode be willing to share the Request ID of one of these failing Gemini conversations to help us fix the issue?
We have very little visibility (as you’d expect!) with privacy mode enabled, which can make it difficult for us to diagnose and fix the LLMs behaviours.
