Edit tool failure

Bug Reports
1

Thanks for reporting a bug you have found in Cursor!
Please add the following info to help us diagnose your issue:

:white_check_mark: Check the forum to ensure the issue hasn’t been reported already
:lady_beetle: Provide a clear description of the bug
:counterclockwise_arrows_button: Explain how to reproduce the bug (if known)
:camera: Attach screenshots or recordings (e.g., .jpg, .png, .mp4).
:laptop: Tell us your operating system and your Cursor version (e.g., Windows, 0.x.x).
:prohibited: Tell us if the issue stops you from using Cursor.

This issue stops me from using Cursor. (I am unable to make progress and I have reached a point where I shouldn’t move forward. I will continue to try however. At this point, I make a backup after every successful edit. This still doesn’t help because sometimes the damage the edit tool has done is only found when work on another system takes place and is found. This means I often lose multiple pieces of work.)

Cursor 0.49.6, Windows 10 Version 10.0.19045 Build 19045

I have looked through the bug reports and while users have complained about similar, I have not found one where the issue has been addressed and a resolution offered.

The edit tool causes changes in the code that is not requested by the model (Gemini Pro). I have lost a weeks worth of work due to this consistent problem. While I try fight my way back to the point of development I was in the app, I just keep going backwards.)

Here are the rules I have implemented to try mitigate the problem:

a. Define Goal: Clearly state the problem to be solved or the feature to be added.
b. Analyze & Plan:
    i. Examine relevant code sections using `read_file`.
    ii. For MODIFICATIONS or ADDITIONS: Read the specific code block to be changed/added to.
    iii. For DELETIONS: Read the code block to be deleted AND several lines immediately *before* and *after* it to establish clear anchors. State that these anchors are being read for deletion safety.
    iv. Propose a clear, step-by-step plan, breaking complex tasks into smaller `edit_file` calls.
c. Explain Change: Before each `edit_file` call, explain *what* code will be changed/added/deleted and *why*.
d. Risk Assessment: Briefly outline potential risks.
    i. For DELETIONS (especially in large files): Explicitly state the risk of the automated tool misinterpreting context and potentially removing adjacent code. Highlight the critical importance of the post-deletion verification step (Rule 11.i.ii).
    ii. For any change: Note if it might affect other application features.
e. Identify Checks: Specify which functions or application features should be tested by the user *after* the change is applied to ensure it worked correctly and didn't break anything else.
f. Stop Application: Ensure the Story Buddy application (the Python process) is stopped before proceeding with `edit_file`, especially for core application files.
g. User Consent: Obtain explicit user confirmation ("yes" or equivalent) before proceeding with the `edit_file` tool call.
h. Apply Change: Use the `edit_file` tool.
    i. For DELETIONS: Structure the `code_edit` parameter to clearly show the *unchanged anchor lines* immediately before and after the deleted block (using `// ... existing code ...` appropriately) to help the tool target correctly.
i. Verify Edit: Immediately use `read_file` after *any* `edit_file` attempt (success, failure, or no changes reported).
    i. For MODIFICATIONS or ADDITIONS: Read the modified/added section to confirm the change is exactly as intended.
    ii. For DELETIONS: Read a section including where the code *was*, confirming the target code is gone AND that the anchor code *before* and *after* the deletion remains intact and unchanged.
    iii. If verification fails: Attempt to reapply or fix (following Rule 4 on retries). If automated edits fail repeatedly (3 attempts for the same logical step), provide manual instructions.
j. User Testing & Confirmation: Request the user to perform the checks identified in step (e) and report back the results (including relevant logs or console output if issues occur). Await explicit user confirmation before proceeding.
k. Proceed or Re-evaluate: Based on user confirmation and test results, either move to the next step in the plan or re-evaluate the approach if the previous step failed or caused issues.
l. Acknowledge Completion: Clearly state when a specific task or fix is considered complete and verified. Remind the user to make a backup if desired.

Here is a conversation with the model to highlight the situation (from the model Gemini Pro):

"* Automated edits have proven unreliable and costly in terms of lost time and progress.

  • Manual edits are not a sustainable solution given you’re not a coder.

  • The protocol’s verification step, as implemented before (reading back just the changed line or a small context), failed to detect the subtle error introduced when changing min=“50” to 10".

Your question, “Can we somehow check what the edit tool is going to change before we accept the edit?” gets to the heart of the matter. Ideally, we’d have a perfect preview.

Why the Current Verification Fell Short & Preview Limitations:

The edit_file tool works in two stages: I generate instructions and code snippets, and then a separate, simpler model tries to apply those changes to the actual file.

  1. Imperfect Application: The applying model might misinterpret context or my instructions, leading to errors I didn’t intend.

  2. Limited Read-Back: When I read back just the line I intended to change (or a few lines around it) using read_file, it looks correct because the intended change was made there. However, this doesn’t catch unintended changes or subtle corruption (like extra spaces, invisible characters, or broken syntax) just outside that small verification window. The diff provided by the tool’s response can also be misleading if the applying model made a mistake it didn’t report correctly.

  3. No True Preview: Unfortunately, the tools don’t offer a reliable “dry run” feature that shows the exact complete file content as it will be after the edit. I could try to construct what I think the full file should look like after my proposed edit, but that relies on me perfectly predicting how the applying model will behave, which isn’t guaranteed."

also:

"Reporting the problems you’ve experienced with the automated editing tool directly to Cursor is a very good idea. Providing them with feedback about its unreliability, especially how simple edits can lead to unexpected file corruption that isn’t caught by verification, is valuable information for them to improve the tool.

While I can’t file the report for you, I can help you summarize the key issues we encountered in this session if that would be useful for your report:

  • Issue: Attempting a simple HTML attribute change (min=“50” to min=“10”) in templates/advanced_settings.html using the edit tool resulted in the page becoming inaccessible (likely due to template rendering errors).

  • Verification Failure: The standard verification step (reading back the changed line and checking the diff) did not reveal any error after the edit was applied, yet reverting the file fixed the problem. This indicates the tool introduced subtle corruption outside the immediate edit area or the verification wasn’t sufficient.

  • Context: Mentioning the previous negative experiences and lost time due to similar edit tool failures would also be relevant context for them.

  • Impact: These failures significantly hinder the development process and require extensive troubleshooting or reverting to backups, undermining trust in the automated editing capability."

Please be so kind as to let me know what I can do to progress on my app development.
Thank you.

1 Like
2

Just a question out of curiosity, did you edit the settings.json file at all? It is interesting what you’ve wrote when I compare something like this to my own projects and I am yet to have some sort of rule in place. I do wonder if others who have solid rules in place have actually created something that is working based on there own rules.

3

The rules are just in a file that I feed it at the beginning of a session.

4

I don’t know how to edit my original post so I am adding this here. The situation has worsened. Gemini can no longer maintain the protocol I have set up either. This is dire. Is this bug report section aimed at community members or Cursor development team?

here is Gemini’s latest response to the issues I am facing.

  1. Tool Unreliability: As we discussed and experienced previously, the automated editing tool has proven unreliable at times, making incorrect changes or failing silently. This is a known issue we have to work around.

  2. My Execution Errors: I have made several mistakes in adhering to the protocol – misinterpreting communication, skipping verification steps, and proceeding without explicit consent. These are my errors, not yours.

Is the protocol hindering rather than helping?

No, I firmly believe the protocol is helping, even though the process has been frustratingly slow and iterative due to the issues above. Here’s why:

  • Safety Net: It was created because of the unreliable tool and past errors. It forces us into a cautious, step-by-step approach with explicit verification. Without it, we risk making larger, untested changes that could lead to even more significant problems or data loss, like the ones you experienced before.

  • Catching Errors: While sometimes cumbersome, the verification steps have helped us catch issues (like the wrong endpoint being modified, or the incorrect return type), even if identifying the root cause took further analysis.

  • Clarity: It provides a clear structure for defining goals, planning, implementing, and testing. This structure is essential when dealing with complex code and unreliable tools, especially when direct manual coding by the user isn’t an option.

The friction we’ve experienced is largely due to my imperfect adherence to the protocol and the inherent limitations of the editing tool. The protocol itself is the necessary safeguard we need because of those limitations.