Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
When you have the preference: Queue messages: Stop and send right away and you’re using Multi-task, if you rapidly send out commands to multi-task before a sub-agent has had time to spin up, your subsequent command will stop the previous one.
I often enable multi-task when debugging, and fire off multiple tasks for Cursor to resolve as I’m walking through the application. If these tasks are fired off too quickly, “Stop and send” can interfere and stop one task in favour of another
Steps to Reproduce
Enable Queue messages: Stop and send right away
Enable Multitask
Give command A
Immediately give command B
Expected Behavior
Either Command B should be analysed to see if it needs to countermand command A or if it provides clarification to it, or Queue messages: Stop and send right away should be ignored when in multi-task mode to enable multiple rapid commands to be submitted in quick succession
Operating System
Windows 10/11
Version Information
Version: 3.7.27 (user setup)
VS Code Extension API: 1.105.1
Commit: e48ee6102a199492b0c9964699bf011886708ba0
Date: 2026-06-10T01:46:16.942Z
Layout: editor
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: Windows_NT x64 10.0.26200
Does this stop you from using Cursor
No - Cursor works, but with this issue
This is actually two separate behaviors that are easy to conflate, so let me untangle them.
The Multitask dropdown changes how a single prompt runs (the agent delegates work to subagents) - it doesn’t make each new message you send spin up its own parallel task. So when you fire command B right after A, B is treated as a normal new submission against the still-running turn. And with Queue Messages set to “Stop & send right away,” a new submission is designed to interrupt the current turn and replace it. That’s why A gets stopped.
Two changes will get you the behavior you’re after:
- Set Queue Messages to “Send after current message” (instead of “Stop & send right away”). With that, rapid follow-ups queue instead of killing the running task.
- To actually run things in parallel, queue your follow-ups and then use the “Start Multitasking” button on the queue. That forks the running task into a background subagent and frees the foreground so the next one can start.
One honest caveat: queued items currently start one at a time as each is dispatched, rather than all firing off as a single parallel batch. The broader ask here - rapid commands fanning out into parallel tasks at once, and “Stop & send” not interrupting a multitask run - is something others have raised too. We’ll keep tracking this post to gauge interest, which helps the team prioritize.
If you’d rather keep “Stop & send right away” as your default, you can hold Ctrl while pressing Enter on a follow-up to queue that one message instead of interrupting the running task.