Cursor Agent is acting uncontrollably after prompts are stopped, modifying files and even committing code

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I want to report a serious Agent safety issue that has made Cursor completely unusable for me.

This is no longer just a duplicated response or looping output issue. Cursor Agent is now behaving in a way that feels completely uncontrolled. Even after a prompt has already been stopped, the Agent may start running again on its own, continue modifying files, delete or rewrite files, and in some cases even commit code.

This has happened in my recent Agent conversation threads, not just once. It is becoming a recurring issue in almost every recent thread I use.

Previously, I reported a related issue where Cursor Agent sometimes returned duplicated responses:

Since then, the problem appears to have escalated. I have also experienced Cursor Agent recreating a file after I manually deleted it. I deleted the file again, and the Agent started again and added it back. Even after I archived the thread, it still recreated the file one more time.

Now the behavior is even more alarming: the Agent can continue acting after the prompt is stopped, making file changes and even committing code without me explicitly asking it to continue.

This is not just a model quality issue. This is an AI Agent safety and control issue.

Cursor Agent has significant permissions on my local machine. If it can continue running after a prompt is stopped, silently modify files, delete/rewrite code, or commit changes without explicit user intent, then I cannot trust it with access to my computer or codebase.

The official team should be able to inspect the recent cases using these request IDs:

  • b7a831c4-9290-4a7d-b038-2d6df6ce832a
  • 090ae7de-1fd7-4061-b4af-fd5aaad67a7c

Please investigate this urgently. From my perspective, Cursor Agent is currently in an unsafe and unusable state. I need a clear explanation of why this is happening, whether the Agent is still running after prompts are stopped, and what safeguards are in place to prevent it from modifying files or committing code without explicit user confirmation.

Even just opening Cursor to copy the version information earlier was stressful, because I was genuinely worried that the Agent might start running again and modify my code unexpectedly.

Steps to Reproduce

just prompt ， it happens every time

Operating System

MacOS

Version Information

Version: 3.7.19
VS Code Extension API: 1.105.1
Commit: 80c653c2c3528e65016a0d304b54486084b470b0
Date: 2026-06-07T01:42:56.126Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 24.6.0

For AI issues: add Request ID with privacy disabled

b7a831c4-9290-4a7d-b038-2d6df6ce832a
090ae7de-1fd7-4061-b4af-fd5aaad67a7c

Does this stop you from using Cursor

Yes - Cursor is unusable

4

I also want to add that my Cursor Ultra annual subscription is valid until February 22, 2027.

I have already submitted a refund request through Cursor support. Given the current state of Cursor Agent, the product is completely unusable for me. I do not feel safe opening Cursor or allowing the Agent to access my local codebase.

Please process my refund request for the unused portion of my Ultra subscription. Continuing to give me access until February 22, 2027 does not resolve the issue, because the reason for my request is that I cannot safely use the product at all.

7

Hi, thanks for the detailed write-up and for including the request IDs.

1. Require approval for every action. Open Cursor Settings, then Agents, then Run Mode, and switch to Allowlist (keep the Command Allowlist empty or minimal). In this mode the Agent cannot run a terminal command, including git commit, without your explicit approval. If you’re currently on Run Everything, that is the mode that lets commands run with no prompt at all, so moving off it is the single biggest change you can make. See Run Mode.

2. Keep File-Deletion Protection on. It is on the same Run Mode screen under Protection settings, and forces approval before the Agent can delete a file.

3. Recover anything that changed. Use Checkpoints in the chat timeline to roll your files back to a snapshot from before the Agent’s changes. For anything that was committed, git revert or git reset will get you back (back up first if you’re unsure).

On the behavior itself: pressing Stop ends the current turn, but a command that is already executing can keep running until it finishes, so with auto-run enabled an action that was already in flight can still land after you click Stop. Requiring approval (step 1) prevents that from happening at all. The two request IDs you shared completed normally on our side, so to dig into the “keeps acting after Stop” part specifically, a short screen recording of it happening would help a lot. That shows the client-side behavior the logs don’t capture.

This pattern has come up in other reports too, so you are not alone in seeing it, and a recording from your side helps us pin down the exact trigger.

On the refund: that is being handled through the support ticket you opened, and the team will follow up with you there directly.

8

Thanks for the detailed response.

I have prepared a screen recording and will attach it here so your team can review the client-side behavior directly.

I understand the mitigation steps you listed, especially switching Run Mode away from auto-run and requiring approval for every action. However, I want to be clear that this does not resolve the underlying issue for me.

If pressing Stop only ends the current turn, but actions already in flight can still continue modifying files or committing code afterward, then from a user’s perspective the Agent is not actually under control. At minimum, the UI should make that extremely clear, and there should be a reliable way to stop all ongoing Agent activity immediately. A user should not need to discover through unexpected file changes or commits that something was still running after Stop was pressed.

Also, regarding the request IDs: if the two requests “completed normally” on your side, but the problematic behavior is client-side and not captured by the logs, then that itself seems like an important gap. The issue is precisely about Agent actions continuing in a way the user does not expect or consent to. If server-side request logs cannot capture that, then I hope the team treats this as a serious observability and safety problem too.

On the refund point, I also want to clarify something. You mentioned that the refund is being handled through the support ticket. However, before your reply here, the support team had already rejected the refund request by saying:

“Once usage begins, the system can’t reverse those charges, as they directly cover the real compute costs incurred by our model providers.”

That explanation does not address my actual request. I am not asking Cursor to refund already-used compute. I am asking for a refund for the unused remaining months of my annual Ultra subscription, because Cursor is currently not usable for me in a safe or trustworthy way.

My subscription is valid until February 22, 2027. I have clearly explained that I no longer feel safe using Cursor Agent on my local machine. Continuing to give me access until the end of the billing period does not help when the product is in a state where I cannot safely use it.

So please do not treat this as a normal cancellation or a normal “used subscription” case. This is a product safety and trust issue. I would appreciate it if the forum/engineering side can also make sure the billing/support team understands that context when reviewing the refund request.