Most of the time pressing the STOP button doesn’t actually stop the agent from continuing, it merrily continues whatever it was doing in the background. The only way to do it is to restart the application.
Some of the time pressing the STOP nukes the task that the agent was doing so much that it rewinds back to the previous one, despite it having responded to you and made significant progress on the next task.
The STOP button is currently completely unpredictable and broken and it did not used to be this way and works exactly as expected in VSCode. Please fix ASAP!
Steps to Reproduce
Talk to agent, press STOP key while it’s working.
Expected Behavior
Pressing the STOP key should leave the chat exactly the way it is but stop the agent from doing any work, whether background or not.
Hey, thanks for the detailed report. Quick clarification first: the version block shows the desktop app (3.20.21, Layout: IDE), even though the form has Cursor CLI selected. I’m assuming you mean the Stop button in the Agent chat panel, not the terminal CLI. If that’s not right, let me know.
On Stop not stopping: Stop ends the agent’s current turn, but any work the agent already handed off to the background (a subagent or a long command started in the terminal) keeps running, and when it finishes it wakes the agent back up. That can make it look like Stop was ignored. If you see a Working pill above the input, open it and click Stop All. You can also stop the running command directly in the terminal panel. We’re tracking this behavior.
Second point (Stop clears the current task and rolls back to the previous message) shouldn’t happen once the agent has already produced a visible reply. Can you try two variants and tell me which one reproduces it?
Open a new Agent chat.
Send a longer task (for example: “read every file in the src folder and give a one line description of each”).
Wait until you see at least a few lines of the agent’s response.
Click Stop.
Check whether the message and partial response stay in the chat, or disappear and your prompt returns to the input field.
Now repeat steps 2 to 3, but this time send a second message while the agent is still working on the first.
As soon as the agent starts the second message, click Stop.
Same check as in step 5.
If you can, a short screencast of the rollback moment would help a lot, plus the Request ID from the affected chat right top corner chat menu … > Copy Request ID. Also, I don’t see any Cursor activity on the email used for your forum account. If you’re logging into Cursor with a different email, please share it, or just share the Request ID so I can look at the right account.
Yeah, the second manifestation is what got me to write this “detailed” report I will be on the lookout and send you the request id, though a screencast is not possible due to this being a corporate machine.
I will try finding the ‘stop all’ button, thank you!
I had the chat silently destroy a part of conversation again, ee01459e-36e0-4f7f-a4f2-a056dbd9b3df… it just rewound back to an older part, didn’t press stop.
Me trying again: Ok, fix it, leave NOT_FOUND alone, but get rid of CHANGED.
Agent: That’s already applied — I did it in the last turn. Let me confirm the state and close the loop with a build, since the catalog change regenerates the _CODE macros.
So internally it knows that it had that turn and made the change, but the chat itself doesn’t show that at all.
It keeps doing it… necroing old work from stuff I stopped long ago. There is no “Stop All” anywhere in the UI, not sure what you’re referring to. There is no separate terminal window/session for any subcommand, also not sure you mean.
This behavior is absolutely not what the agent should be doing… stop means stop, you know
@glebbb, thanks for the request IDs, that was exactly what was missing.
Quick correction first. The “Stop All” button I pointed to only exists in the Agents window layout. In the normal IDE chat panel it isn’t there, so you were right that there was nothing to look for. Sorry for the confusion.
For the second ID, here’s what the logs show. At the start of the session the agent ran a couple of shell commands that went into the background. Both already finished, but Cursor kept re-sending the “task completed” notification into the chat, and each delivery triggered a new automatic follow-up turn. When you press Stop on that follow-up, the turn gets cancelled, but the notification itself goes back into the queue and shows up again a bit later. That’s where the “necroing” comes from. The same old job keeps coming back no matter how many times you press Stop, and only restarting the app clears it. This shouldn’t happen. It’s not something in your setup, I passed this to the team using your session as an example.
Until it’s fixed, you can reliably clear the queue in two ways:
When the chat wakes up again after Stop and you see the completed background task mentioned, let that short follow-up finish once instead of pressing Stop. After it finishes, the notification gets consumed and the chat stays quiet.
Or restart Cursor or continue in a new chat. Sending a new message in the same chat does NOT clear the queue.
For the first ID, the silent rewind to an older point in the chat on Sep 16. The logs show that turn was interrupted from your side at 00:42 UTC, even though you didn’t press Stop. Sending a follow-up message while the agent is still working interrupts the current turn by default, so if you remember typing something right before the rewind, that could explain it. That’s exactly what the second half of the steps I sent earlier is checking. If you have a minute to try both variants and tell me which one reproduces the rewind, I’d appreciate it. No screencast needed, a text reply is totally fine.
I will be on the lookout and send you the request id, though a screencast is not possible due to this being a corporate machine.