Any other message you try to send while some work is being done, just queues that message to be sent afterwards. But when you call /summarize, it stops the current work on its tracks. And after summarized, it also does not continue the work from where it stopped, unless you send a new message asking it continue.
Steps to Reproduce
Send some long work to start working on…
Then while that is running, call /summarize
The current work stops
Send some long work to start working on…
Then while that is running, send a message with some more follow-up details.
Expected Behavior
The message gets queued, and the current works continues normally
My expectation would be that /summarize works like any other message/command. That it should get queued. And you could still choose to manually “send now”, to stop the current work more intentionally if you need.
Hey, thanks for the detailed report. This looks familiar. A similar bug with /summarize and the queue showed up before and was fixed, so this looks like a regression. I can confirm the difference: a normal follow-up message while the agent is working does not interrupt the current turn, but /summarize interrupts immediately and does not resume after summarizing. You need to send a new message like “continue”.
One thing: your version info shows the desktop client Electron, glass layout, but you selected Cursor CLI as the product. Can you confirm which one you’re using, the desktop app agents window or the terminal cursor-agent? That affects how we can get the Request ID.
If it’s desktop: reproduce the bug again, then in the chat menu top right > Copy Request ID and send it here. If it’s terminal CLI: let me know and I’ll tell you how to pull the ID from the output.
Workaround for now:
Wait for the current turn to finish before running /summarize.
If you already interrupted it with /summarize, send a short “continue” so the agent keeps going.
Cursor will auto-summarize long chats when it hits the context limit, so you usually don’t need to call /summarize manually mid-task.
Also, can you confirm if this only happens with /summarize, or if other slash commands break the queue too? Also note that queue behavior for normal messages depends on the Queue messages setting Stop & send right away vs Send after current message. Once you share the Request ID, I’ll pass it to the team.
I agree that summarize should behave like a queued control action, not an interrupt.
The dangerous part is that “summarize” feels observational, but the current behavior changes execution state. If it has to interrupt, the UI should make that explicit before it runs. Otherwise people will use it as a safe checkpoint and accidentally stop a long task.
@deanrie - I don’t want to push, but I can see a trend with some issues where they just stall as soon as they get a request ID attached. So please just give me a heads up if this actually reach you.
In great hopes of getting this solved.
Thanks for the Request ID and for confirming this is the desktop agents window. That clears up the confusion with the CLI tag. And the fact that only /summarize breaks while other slash commands queue normally is a helpful detail.
We can confirm the behavior on our side. /summarize interrupts the current turn instead of queueing, and it doesn’t resume work after the summary. I’ve reported this internally to the team with your Request ID and repro steps. I can’t share an ETA for a fix yet, but I’ll post an update in the thread when I have one.
Good point from @Jason_Luo1. If /summarize can interrupt work, the UI should make that clear before you run it, otherwise it’s easy to assume it’s a safe checkpoint. I’ll pass that along too.
For now, the workaround is the same: wait for the current turn to finish before running /summarize, or if it gets interrupted, send a short “continue” so the agent keeps going. Cursor also auto-summarizes long chats once they hit the context limit.