Critical Regression: Task Queues No Longer Work — New Messages Cancel Previous Tasks

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

What happened to the task queues in my IDE? What did you change? Honestly, it is extremely frustrating to see a feature that worked so well get broken by an update.

Previously, I could assign 30 sequential tasks to my agent. It would execute them one by one, successfully, and I could simply step away from my desk and come back later to find everything completed. That is the entire point of having an agent: it should work autonomously without requiring me to supervise every single step.

Now, if I send one message and then send another shortly afterward, the previous task gets canceled or interrupted, and the agent moves on to the second one. In other words, the task queue is no longer reliable.

This is seriously damaging to my workflow. I cannot sit in front of my computer waiting for every task to finish before I am allowed to send the next one. If that is how the agent is expected to work, it defeats a major part of its purpose.

You have broken a critical functionality. The expected behavior is for tasks to be queued and executed sequentially, without a new message improperly canceling or interrupting the previous one.

Please treat this as a critical regression and fix it. We need the previous behavior restored—the ability to send multiple tasks and trust that the agent will execute all of them, in order, until completion.

Steps to Reproduce

  1. Open a project in the Cursor IDE and start an agent task.
  2. Send a detailed instruction to the agent, asking it to perform a task that takes some time to complete.
  3. Before the first task finishes, send a second instruction/message to the same agent.
  4. Observe that the first task is interrupted, canceled, or abandoned, and the agent starts working on the second instruction instead of completing the first one.
  5. Repeat the process with multiple sequential instructions. The agent does not reliably maintain the queue or execute the tasks in the order they were submitted.

Expected behavior:
New messages should be added to a task queue and executed sequentially after the previous task is completed. Sending a new instruction should not cancel or interrupt an already-running task unless the user explicitly requests cancellation.

Actual behavior:
Sending a new message while a task is running causes the previous task to be interrupted or abandoned, preventing reliable sequential execution of multiple tasks.

Operating System

MacOS

Version Information

last version MacOs M4

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey @gugaroto, thanks for the report! Good news, the queue isn’t broken. Your New Messages setting just got switched to Steer, which hands a new message to the agent mid-task instead of queuing it, so it changes course and the first task looks dropped.

To restore the old behavior: Cursor Settings → Agents → Conversation → New Messages, change Steer back to Queue. After that, messages you send while the agent is running will wait in line and run in order.

Let me know if it still interrupts after that.

7

@mohitjain you claim it is not broken. Yet it is far from perfect either.

Cursor and it’s models can’t seem to grasp the concept of interception and interruption fully. I have caught it on multiple occasions, where when a task that was added onto the the pile, the previous task was simply not performed. (in steer mode) When confronting the model about it, it doesn’t try to deny it either.

I am not sure if it’s the stupidy of the model, or a bug in Cursor, but it sure is a regression to me. I would expect any addition to still be performed on top of the current objective, and the agent to not drop the current task because something slightly different came up.

I believe steer mode can be powerful, but can’t we have an option to let the user decide on what to do with the next message (either enqueue or steer).

image
image355×149 2.92 KB

8

What you’re hitting is Steer working as designed plus a rough edge in how the model handles it: a mid-run message gets handed into the current turn, so the agent has two instructions and often runs with the newer one, dropping the earlier task. Not something you misconfigured, and an area we’re improving.

The per-message choice you’re asking for already exists:

  • Default to reliable queueing: Settings > Agents > Conversation > New Messages > Queue. Everything you send while the agent runs then waits and runs in order.
  • Override per message: ⌘Enter (Ctrl+Enter on Windows/Linux) does the opposite of your default for that one message. On Steer, plain Enter steers and ⌘/Ctrl+Enter queues just that one; on Queue it’s reversed. Send Now on a queued message also pushes it in on demand.

If you’re on Queue and a message still steers instead of waiting, that’s not expected. Reply with your version and a screenshot and I’ll look closer.