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.
Hey, thanks for keeping the thread alive, and sorry for the silence.
Status update: the bug made it to the team. We can reproduce it on our side, and it’s logged along with your Request ID and the repro steps. So it’s not a case where the report got stuck after linking the ID. I can’t share an exact ETA for a fix yet, but I’ll post an update right here as soon as I have one.
Also shared your point and @Jason_Luo1’s point that /summarize feels like a safe checkpoint, but it actually changes the execution state. I agree the UI should at least warn you before running it.
For now, the workaround is still:
Wait for the current turn to finish before calling /summarize.
If you already interrupted it, send a short “continue” so the agent keeps going.
Cursor will also auto-summarize long chats when it hits the context limit, so you usually don’t need to run /summarize manually in the middle of a task.
Off course - Researchs shows context decay when reaching high amounts of filled context so it is producing worse results when first doing the auto summarization at 100% then suddenly you end up with worse quality results as well so i guess this thread is about two important questions. Is it recorded as so?
/summarize stops the run instead of queueing it up, and it doesn’t resume after the summary. This is a known bug and it’s being tracked internally with your Request ID and repro steps. It didn’t get stuck after linking the ID. I can’t share an ETA yet, but I’ll post an update here as soon as I have one.
About context decay and auto-summary kicking in too late, close to the context limit, which hurts quality. That’s a separate issue from the queue bug. Your reasoning makes sense: you want to run /summarize manually earlier as a checkpoint, before the context fills up, and right now that breaks the current run. I noted it, but it shouldn’t live inside the queue bug thread. If you want this tracked separately, it’s better to start a new thread focused on summary timing and quality so it doesn’t get lost in the queue bug discussion.
Current workaround is the same:
Wait for the current turn to finish before running /summarize.
If it already got interrupted, send a short continue and the agent will keep going.