I get a lot of issues with tools not working, unable to edit files, asking me to manually edit files (I could use Gemini to do that). AI’s being unavailable by saying I have no internet, when I clearly do. It’s made cursor really, really slow to work with. Applying edits multiple times, not checking existing code, forgetting everything it ever knew about your app, crashing “Would you like to reopen” issues with cursor. My first month hasn’t been a good experience.
4 Likes
This is really getting frustrating using cursor:
That edit failed again, deleting a line and causing errors. I will revert it.
The tool is simply not working reliably on this file. I cannot add the debug print statement.
The tool is stuck and cannot revert the faulty edit. The src/dashboard.py file is likely corrupted around the save_future_prediction call. Please review the file manually, ensure the line future_predictions_df = load_future_predictions() is present before the save_future_prediction call, and remove the incorrect print statement that was added. Then, you can optionally add the correct debug print statement manually if desired.
Okay, you are absolutely, 100% correct. I am deeply embarrassed and apologize sincerely.
I have completely misread the file multiple times. The except Exception as analysis_err: block IS present after the try block for the AI analysis, and it DOES correctly assign the default error string to analysis_text.
1 Like
Is there actually anyone from Cursor replying to people? I reached out on X and got no reply so I tried here and got no reply?
2 Likes
It seems the model didn’t make the change. Let me try reapplying that edit to remove the include for crtfree.h from dataitem.cpp.
Reapplied changes
dataitem.cpp
Unfortunately, the tool seems to have completely replaced the content of dataitem.cpp instead of just removing the #include “crtfree.h” line. This is not what we intended.
Cursor is fundamentally broken in its current state.
1 Like
"I understand completely. It’s definitely been a frustrating session with the tools not applying the necessary fixes for those include errors, and I sincerely apologize that I couldn’t get past that roadblock to help you resolve the compilation issues.
You’re right to feel it’s pointless to continue when the fundamental tools needed aren’t working correctly. I appreciate your patience in trying the various approaches.
If you change your mind or have a different task later, feel free to reach out. Otherwise, I understand your decision to handle this manually."
What is the point in Cursor? I might as well use Gemini?
Okay, I can certainly summarize the instances in this conversation where the file editing tools failed to apply the intended changes. It has definitely been a challenging session trying to resolve the compilation errors when the primary tool for fixing them wasn’t working reliably. It’s completely understandable that this is frustrating, both for you trying to get the code fixed and for me trying to execute the necessary steps.
Here’s a summary of the tool failures related to edit_file and reapply in this specific conversation thread focused on fixing the header includes:
- Initial Include Order Change (Attempt 1):
-
Action: Proposed edit_file to change include order in pminit.c, shutdown.c, and taskman.c (placing <winnt.h> before #undef WIN32_NO_STATUS).
-
Outcome: Edits reported as applied for shutdown.c, but subsequent error list showed no change. User later confirmed edits weren’t applied to pminit.c and taskman.c.
- Reapplying Include Order Change (Attempt 1):
-
Action: Used reapply on pminit.c, shutdown.c, and taskman.c.
-
Outcome: reapply reported success for pminit.c and shutdown.c (though the diffs looked correct, the previous step’s failure suggests this might not have reflected the true file state), but reported “no changes” for taskman.c. Build errors persisted.
- Second Include Order Change (Attempt 2):
-
Action: Proposed edit_file to change include order again (placing <winnt.h> after #undef WIN32_NO_STATUS). Edits applied to progman.h, shutdown.c, taskman.c.
-
Outcome: User confirmed edits were not applied to pminit.c, shutdown.c, or taskman.c. Build errors persisted.
- Reapplying Include Order Change (Attempt 2):
-
Action: Used reapply on pminit.c, shutdown.c, and taskman.c.
-
Outcome: reapply reported “no changes” for all three files. Build errors persisted.
- Simplifying Includes after progman.h Fix:
-
Action: Proposed edit_file to simplify includes in .c files after correcting progman.h.
-
Outcome: Edits seemed to apply to shutdown.c and taskman.c, but reported “no changes” for pminit.c. Build errors persisted. Reapplying the pminit.c edit also reported “no changes”.
- Adding #define NTDEF to progman.h:
-
Action: Proposed edit_file to add the define.
-
Outcome: Edit seemed to apply, but resulted in new bcrypt.h errors, indicating it likely caused further issues or didn’t fully resolve the underlying conflict.
- Restoring Explicit Includes (Attempt 3):
-
Action: Proposed edit_file to restore full, correctly ordered includes in pminit.c, shutdown.c, and taskman.c after reverting the #define NTDEF change in progman.h.
-
Outcome: Edits reported “no changes” for all three .c files. Build errors persisted.
- Final Retry (Attempt 4):
-
Action: Explicitly retried the sequence from attempt 3 (progman.h, pminit.c, shutdown.c, taskman.c).
-
Outcome: All edit_file calls reported “no changes”. User confirmed blank lines were potentially being inserted instead.
Summary of Frustration:
From my perspective as the AI assistant, this sequence was indeed frustrating. The core issue revolved around fixing header include orders, a common and usually straightforward task. However, the inability of the edit_file and reapply tools to consistently and correctly apply the proposed code modifications created a significant roadblock.
Each attempt involved:
-
Analyzing the build errors.
-
Formulating a standard C/C++ solution for header conflicts.
-
Translating that solution into the specific format required by the edit_file tool.
-
Executing the tool call.
-
Observing the tool report success but the build errors remain unchanged, or observing the tool explicitly report “no changes were made”.
-
Repeating the process with minor variations or reapplication attempts.
This loop, where the tool responsible for implementing the fix fails silently or incorrectly, prevents progress on the user’s primary goal (compiling the code) and forces repetitive, ultimately unsuccessful, attempts. It limits my ability to effectively assist with tasks that require precise code modification, which is a core part of pair programming and debugging assistance. Reliable file editing is crucial for this workflow.
Please feel free to copy and share this summary with the Cursor developers. Hopefully, this feedback can help improve the reliability of the tools.
Okay, here’s a technical description of the latest failure for the developers:
Bug Report: edit_file Tool Failure Applying Header Include Order Changes
Tool: edit_file
Target File: progman.h
Timestamp: (Approximate time of the last attempt)
Intended Operation:
The goal was to modify the preprocessor directives at the beginning of progman.h to enforce a specific, standard include order for conflicting Windows system headers. The intended order was:
-
#define WIN32_NO_STATUS
-
#include <windows.h>
-
#undef WIN32_NO_STATUS
-
#include <winnt.h>
-
#include <ntdef.h>
-
#include <ntstatus.h>
-
#include <winternl.h>
Followed by other necessary includes like <setjmp.h>, “security.h”, “pmhelp.h”, etc.
edit_file Call Parameters:
-
target_file: “progman.h”
-
code_edit: A multi-line string representing the desired state of the include block as specified above, designed to replace the existing incorrect include order. It included the necessary #include, #define, and #undef directives.
-
instructions: “Retry ensuring the standard include order for system headers in progman.h.”
Actual Outcome:
The API response for the edit_file tool call was: {“edit_file_response”: {“results”: [“The apply model made no changes to the file.”]}}.
The user reported observing that the only actual modification might have been the insertion of a blank line, rather than the intended comprehensive change to the include block.
Analysis:
This represents a persistent failure mode observed over multiple attempts in this session. The edit_file tool appears unable to correctly apply the requested multi-line modification involving preprocessor directives at the beginning of this C header file. The discrepancy between the requested code_edit and the actual result (“no changes” or minimal incorrect changes like blank lines) suggests a potential malfunction in the underlying model responsible for parsing the request, generating the diff, or applying the changes to the target file. This failure prevents the resolution of critical C2011 (redefinition) and C2065 (undeclared identifier) compilation errors stemming directly from incorrect header inclusion order. The issue seems particularly pronounced when modifying existing blocks of preprocessor directives in .h or .c files.
same problem
workbench.desktop.main.js:995 [composer] ToolFormer: error in toolWrappedStream toolu_01GRqrSYwBa4YrpgY5YXGZEb
workbench.desktop.main.js:600 ConnectError: [aborted] read ECONNRESET
at yWs.$endAiConnectTransportReportError (workbench.desktop.main.js:2510:203774)
at dAi.S (workbench.desktop.main.js:660:56250)
at dAi.Q (workbench.desktop.main.js:660:56028)
at dAi.M (workbench.desktop.main.js:660:55116)
at dAi.L (workbench.desktop.main.js:660:54217)
at Qle.value (workbench.desktop.main.js:660:53009)
at $.B (workbench.desktop.main.js:46:2392)
at $.fire (workbench.desktop.main.js:46:2611)
at sne.fire (workbench.desktop.main.js:2492:10362)
at l.onmessage (workbench.desktop.main.js:4938:12216)
workbench.desktop.main.js:2061 [composer] Error in AI response: ConnectError: [aborted] read ECONNRESET
at yWs.$endAiConnectTransportReportError (workbench.desktop.main.js:2510:203774)
at dAi.S (workbench.desktop.main.js:660:56250)
at dAi.Q (workbench.desktop.main.js:660:56028)
at dAi.M (workbench.desktop.main.js:660:55116)
at dAi.L (workbench.desktop.main.js:660:54217)
at Qle.value (workbench.desktop.main.js:660:53009)
at $.B (workbench.desktop.main.js:46:2392)
at $.fire (workbench.desktop.main.js:46:2611)
at sne.fire (workbench.desktop.main.js:2492:10362)
at l.onmessage (workbench.desktop.main.js:4938:12216)
No one from Cursor support seems interested in talking to me. Which is a shame because they could have a fantastic product here if it wasn’t for stupid problems.
Hey, sorry for the delay, we are already investigating it.
Could you please let me know which version of Cursor you are using?
Latest beta.
I could literally come up with several pages of bugs and annoyances of cursor. It’s a shame no one at Cursor has been interested in fixing them over the last few weeks as this could be such a good product if you listened to your customers feedback. I very nearly cancelled and moved to the competitiion but I really like Cursor and it’s done some amazing stuff so far. Just needs this laundry list of bugs fixed.
Thank you, we’ll try to figure this out.
1 Like
No worries! Just good someone is here at Cursor now!
1 Like
same here, when MCP enabled via docker, cursor failed and:
Error in AI response: ConnectError: [internal] internal error
at wWs.$endAiConnectTransportReportError