Agent is acting on queued messages before they are sent

Support Bug Reports
, ,
1

Describe the Bug

Agent is seeing and acting on follow up messages in the queue and working on them before finishing its current task.

Steps to Reproduce

Start the agent on a long task, and then queue some follow up message intended to be sent once the agent completes its current work.

As it works it seems to eventually decide to use the ‘check queue for follow up messages’ tool:

Cursor Cloud message queue (1 queued). The currently executing message is not queued.
{
  "hasQueuedMessages": true,
  "queuedMessageCount": 1,
  "queuedMessages": [
    {
      "followupId": "4797b8b9-f187-40da-96a8-8a4ef3ec383e",
      "createdAtMs": 1788994575404,
      "source": "GLASS",
      "text": "fonts on your generated screenshots are completely wrong. please compare before/after you'll see that all the fonts have changed now"
    }
  ]
}

It will then announce something like:

There's a follow-up queued about fonts, so I’ll revert the carousel change and freeze motion from the test harness now, then verify screenshots once both fixes are in.

and start working on it. Once the agent is finished, the queued message sends itself which really confuses the agent - since it effectively gets told to perform the same thing again.

Expected Behavior

Agent should not be aware of the queue whatsoever. Thats for me to pre-send some messages that I want the agent to work on after its finished its task. The agent should not pre-emptively look in the queue and start working on tasks before it has finished what its doing.

I understand an awareness of whats ‘coming up next’ might be useful when compacting context but this should not be exposed to the agent as its working. Why is this tool even exposed to the agent in its normal workflow?

Operating System

MacOS

Version Information

Cursor agents window 3.19.13 (Universal)

For AI issues: add Request ID with privacy disabled

bc-3fb6ebb6-f54d-4782-b99b-f54e7b8d25ff

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Was the followupId unchanged when that message was delivered at the end? The trace suggests it was acted on during the first turn but still left pending in the queue. Seeing the same ID at both points would make the duplicate handling much clearer.

8

If I reproduce this again today I will let the queued message run again and stop the chat to show you if that helps.

But yes, the flow is roughly:

  • agent working on task
  • i queue a message
  • some time later, the agent decides to look in the queue with that tool
  • it sees the follow up and says “Oh look, a follow up message, let me finish what I’m doing then do what it says”
  • the agent keeps working and finishes
  • the follow up message is sent from the queue as normal

I don’t think this is a harness bug, I think it’s just an alignment issue. It sees a tool called “get_follow_up_messages” and so tries to be helpful and periodically call it. If it finds a follow up message it will start working on it. The actual message isn’t inserted into the chat early - its just the agent ‘sees’ whats coming next and starts working on that too early.

10

Hey @walke,

You’ve got it right, and it isn’t anything on your end. The agent shouldn’t be peeking at your queued follow-ups or acting on them mid-task. We’ve let the team know and it’s an issue we’re tracking.

Two things that help in the meantime:

  1. Add a line to your project rules or AGENTS.md: “Do not check or act on the follow-up message queue. Queued messages arrive as new messages after the current task finishes.” It’s a nudge rather than a hard block, but it noticeably cuts down the peeking.
  2. If you want something picked up right away, use “Send now” on the queued message.

I’ll post here when there’s an update.

11

That clears it up, Ben—I’d read your first report as the queued message being delivered early. You’re describing the agent acting on a preview, then receiving the message normally later. I saw Mohit’s confirmation too. If you catch it again, whether that later delivery triggers the work a second time would be useful to know.

12

The boundary should be structural, not just a rule: while an item is pending, expose only queue length and opaque IDs, never its text. On dequeue, atomically transition the followupId from pending to leased or consumed before adding the payload to model context; that prevents both premature action and the same instruction being executed again after normal delivery.