Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Latest Nightly Cursor often stuck after command run. I did not notice this behavior on 2.7.0 pre 92
this was stuck for an hour or so.
Steps to Reproduce
NA
Expected Behavior
Cursor should not stuck. There should be some watchdog/healthcheck. If it sees no changes/actions, then it should send “revive” command.
Operating System
MacOS
Version Information
2.7.0 pre 127
Does this stop you from using Cursor
No - Cursor works, but with this issue
This what happened when I clicked “STOP” button.
Here I expect that Cursor will ask and wait some content. I do not know why it decided, that I rejected something.
Hi Eugen,
Two issues here. A couple of clarifying questions first to help diagnose the right path:
-
Which agent mode are you using? When you look at the bottom of the chat panel, does it show “∞ Agent” (the newer mode) or just “Agent”? This matters because terminal command handling works differently between modes.
-
What exactly was the stuck state? Was the agent showing the command as “running” with a spinning indicator, or was it frozen entirely (no UI response)? And was it showing a “Run” / “Reject” approval prompt that wasn’t responding, or had the command already been approved and executed?
About the “Rejected: Review cancelled or failed” when clicking STOP: This is the expected behavior of the current STOP button — it cancels the active tool call and the agent treats the cancellation as a rejection rather than a pause. A fix for a related issue in the newer agent mode was recently shipped, so updating to the latest nightly may improve this behavior. But to confirm: is your expectation that STOP should let you add more context and resume, rather than cancel the current operation?
For the stuck state itself: As a workaround worth trying (if you’re in the standard agent mode, not ∞ Agent):
Note: one user in a related thread reported a crash on first use of Legacy Terminal, but it worked after a second restart. Also, next time this happens, could you share a Request ID?
-
Which agent mode are you using?
As you can see from the screenshot this is “∞ Agent”
2. These answers should be visible from the first screenshot too:
a. What exactly was the stuck state? It shows nothing. I do not know the state.
b. Was the agent showing the command as “running” with a spinning indicator, or was it frozen entirely (no UI response)? No indicators, just frozen.
c. And was it showing a “Run” / “Reject” approval prompt that wasn’t responding? No any prompts
d. or had the command already been approved and executed? Command was approved and executed. The result is “No output”.
so updating to the latest nightly may improve this behavior.
No updates available.
But to confirm: is your expectation that STOP should let you add more context and resume, rather than cancel the current operation?
Yes, stop should stop and let me to add more context and resume, rather then cancel the current operation. I suppose this should be 2 step button: The first step should be “Pause and add context”, The second step (click) should be “Cancel current operation”.
(if you’re in the standard agent mode, not ∞ Agent)
I am in ∞ Agent mode.
Since you’re in ∞ Agent mode, the Legacy Terminal workaround I mentioned won’t apply – that’s only for the standard Agent mode. And since you’re already on the latest nightly with no further updates available, both of my initial suggestions are off the table. Apologies for the runaround.
For the stuck state: the fact that it’s a complete freeze with no indicators (no spinner, no prompts) after an approved command with “No output” points to the agent losing track of the command’s lifecycle in ∞ Agent mode.
To help our team dig into this, could you grab a Request ID from the chat the next time this happens? That will let us trace exactly where the hang occurs on our end.
bc6e3ac0-1217-4273-b76f-6455bd5c0c98
I suppose that this happen when Agent asked me to “Approve” but I did not clicked it in time.
This happens again on 2.7.0 pre 162
Thanks for the Request ID — I was able to trace it on our end.
Your hypothesis is correct. The shell tool (git add) was waiting for approval, and when the approval wasn’t acted on in time, the agent lost track of the approval state and hung for about 8 minutes until the connection timed out on its own.
This is a confirmed gap in how terminal commands handle approvals. Other tool types (like mode switches) have a built-in timeout so the agent can recover gracefully if the prompt isn’t acted on. Terminal commands don’t have that timeout yet, so if the approval prompt goes stale, the agent blocks indefinitely.
I’ve flagged this with our engineering team. No workaround is available in ∞ Agent mode for this specific issue.
One thing I’d suggest: if your chat conversations grow very long (hundreds of messages), consider starting a fresh chat periodically. Very large conversations can contribute to slower agent responsiveness in general.
The issue is I can leave Agent to work for 30-40 mins. So 8 mins timeout does not work here. If we have timeout and wanna to close the connection, then it is acceptible. But please show “Retry” button, so I can continue exactly at the place when Agent asked me to “Approve” the action.
btw sometimes request ID is not available:
