Describe the Bug
Send a message when LLM is streaming, it queues the response regardless of the setting to not do so. If you press return a second time it will interrupt and send the queued message.
Steps to Reproduce
Send a message.
Expected Behavior
Immediate interrupt/stop and send.
Operating System
MacOS
Current Cursor Version (Menu → About Cursor → Copy)
Version: 1.4.0
VSCode Version: 1.99.3
Commit: 2cdf414b520ff31ee87dd841a04d8aa84009eae0
Date: 2025-08-05T23:10:54.574Z
Electron: 34.5.1
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.6.0
Does this stop you from using Cursor
No - Cursor works, but is incredibly frustrating.
Hi, you should be able to force send and interrupt the agent with cmd+enter
Okay will give that a try. Hopefully thats just a workaround, not the new solution tho.
(and I’ll again push for it would be great if cmd-enter and enter could be programmed to send messages in different modes. E.g. cmd-enter is in full agent mode, but enter is only read-only. So you can talk and plan and do what not with enter, and when you’re finally ready to say “yeah okay make the changes!” you enable the full agent mode. So that this overeager LLM’s dont get ahead of themselves. Using the pulldown is cumbersome for this kind of switching.
Hey Charles! You can configure the default behavior for new messages in Cursor Settings → Chat → Queue messages.
The new default behavior is Send, which will send the message at the next opportune time for the agent (e.g. after “Thinking” or editing a file) so you don’t interrupt it while it’s working. But if you prefer the CMD + Enter behavior as the default (which stops the agent, even if it’s mid-way through changing a file!), you can change to Stop & send.
Hope the new Send behavior feels good for you, would love to get your feedback 
Thanks Austin! I’ll switch it over to stop and send. I find with the send behavior Im just hitting enter twice. The only time Im finding I want to send the “next” message while its streaming is to say ‘Stop!” And then quickly follow up with another message to tell it where its gone wrong. Interestingly if there was a true “stop!” break-glass hot key (cmd-delete?) or maybe even better a pause/continue toggle hot-key (pause the thing, then either type a new message to re-direct, or unpause if I got it wrong) I might find the queuing more useful.
The thing is, Im not sure the use case for queuing future messages when basically virtually every sequence requires me to ensure it correctly completed the previous task before taking on the next one. Would love to see how someone sucessfully uses the queue as designed (as a mini todo list I suppose?)
Our “Stop!” hotkey is Ctrl+C which stops the agent and should work well for your use case! We’ll also then focus the input for the last message you sent which makes it easy to adjust the instructions you gave the agent.
The use case we’re trying to solve with the new Send behavior is when you want to update or add context to your previous message without stopping the agent (e.g. “Refactor this component” → “But don’t change function X”).
I agree on queueing future messages – it’s generally good if you want to load the agent up with a handful of tasks to do rather than dependent tasks (that depend on preceding implementations, like you mention).
We switched from Stop & send as the default because it sometimes interrupts the agent at unideal times (like in the middle of a tool call) that can result in degraded output since the agent didn’t get what it expected.
Ah thats super interesting. I just was about to suggest you show that in the input window and see it there already. Go figure. Okay thats very cool, let me switch the queue mode back and see if it makes sense within that context! Thanks Austin! (and see cmd-enter request again up there :nudge: :nudge: 
)
Just got bit by a queued message style UX gotcha.. Im typing my little message, the Agent decides to run a command and pops up the authorization menu. I press enter at the end of my message, however it is intercepted by the pop up and the command runs (that I didnt want to run). Luckily it was non-destructive.
You might want to say “If there is message text in the input box or input box is focused, do NOT move focus/intercept enter for the approval”. It’s too easy to accidentally approve bot actions…
1 Like
@charles great feedback! Just fixed this internally, will be out in our next patch release
2 Likes