"Taking longer than expected" when queueing messages

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When I queue messages while the agent is working and the agent moves to those queued message(s), I will often run into a “Taking longer than expected” error, from which the agent and/or client never recovers. My current work-around is to stop generation and resubmit as a normal (non-queued) message.

Steps to Reproduce

While an agent is working (before it finishes), queue more messages, then observe.

Expected Behavior

Queued messages should work (and in general, I think they should behave like normally sent messages).

Operating System

Linux

Version Information

Version: 3.18.9
VS Code Extension API: 1.128.0
Commit: 2ba48ff3f7514cc4643c52ca9f7b3173d9b66130
Date: 2026-08-27T01:42:22.092Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.6
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Linux x64 7.1.9-arch1-2

For AI issues: add Request ID with privacy disabled

This is happening across multiple projects, but here is an example: 5e57bef1-0ebe-48cc-9090-a21e53d9772b

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey @jsimonrichard, thanks for the report, and for the Request ID.

That ID belongs to the message you re-sent after stopping (it ran fine on our side). The queued messages that got stuck never actually left Cursor, which is why the agent sat on “Taking longer than expected” with nothing to recover from.

You’re on 3.18.9, and there have been several changes to how queued messages are sent since then. Could you update to the latest version (3.20) and try again?

Alright, I got the new version. Sometimes it works, but other times the queued message never gets sent (as far as I can tell). It looks like this:

Request ID: 6ee531a0-4b43-461f-b45b-18cdc07ab7be

Version

Version: 3.20.21
VS Code Extension API: 1.128.0
Commit: f09fca384ceca23f7bf21f9c23655b162641d740
Date: 2026-09-13T19:02:51.781Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.9.3
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Linux x64 7.2.5-3-omarchy

Hey @jsimonrichard, thanks for trying the update and for the screenshot, that was the missing piece.

I can see what is happening now. When the running task finishes, Cursor moves your queued message into the chat as a sent message, but in some cases the actual send behind it does not go through, so nothing starts and there is nothing to stop. It depends on timing at the very end of the previous task, which is why it sometimes works and sometimes does not.

Until it is fixed: if a queued message shows up in the chat but the agent does not start working within a few seconds, just send it again (copy the text and press Enter). No need to press Stop first. If you queue several messages at once, check that the first one actually got a response, since it is the one that can get skipped.

While I have filed this with the team, I also expect the issue to eventually be resolved on a newer version of the agent runtime we are gradually moving users to!

Hey @jsimonrichard,

Quick update: a fix for queued messages showing up as sent without the agent actually starting has landed, and it will be included in an upcoming version of Cursor (3.23).