Cursor IDE
Local agent, Grok 4.6, it happens I would say since 3 days ago, very annoying.
Open a new chat and just prompt anything.
MacOS
3.17.21 (Universal)
Cursor Grok 4.6
No - Cursor works, but with this issue
+1 from me. I was raving about the speed and balance of the cursor-grok models. Then all of a sudden several days ago the speed slowed by like 5x. Seems to be the case regardless of 4.5 vs 4.6, and any thinking level.
Hey @angel-luis, thanks for the report, and thanks @Jonnoh for the extra confirmation.
The “Taking longer than expected” message appears when the model takes a while to start responding. Grok 4.5 and 4.6 have been under very heavy demand recently, and during busy hours responses can take noticeably longer to start. This is on our side, not related to your setup or account.
We have been rolling out capacity and routing improvements over the past few days, and response times have been improving steadily today!
Thank you, have to note that “Continue Working” is the most used thing now in Cursor, is really annoying this situation, it doesn’t even notifies, as UX I would put it automatically in those situations, you can’t rely now in put a task and do other things meanwhile.
Well this is a different issue, this is the issue for this error: Failed to move agent root
+1 I am experiencing this as well. Very annoying.
I’ve been experiencing the exact same problem for the past 6 hours. Whenever a conversation has even a slightly substantial context (around 150K or so), it ends up like this—trapped in an infinite “Taking longer than expected…” loop. If you wait long enough, you’ll eventually get a 503 error.
Hey @thibauld and @q1438998005, thanks for the extra reports.
@thibauld, what you hit this afternoon lines up with a provider issue affecting all Grok models that started around 13:20 UTC today. You can follow the status at status.cursor.com.
@q1438998005, a few things are stacking up for you:
Thank you @Colin . It got better but then lately it started coming back… it’s very frustrating because it’s totally unclear how to fix it (besides rebooting the machine 
).
Here is the ID of the latest request that did that for me: 61a55519-9e50-494a-8ad7-2e79a7677668 
Update: still stuck after writing this message… I think my chat is bricked 
If I stop everything and ask something else in the chat… it is just dead
Update 2: Restarting Cursor restored the usability of the chat
Here we go again… it just happens way too frequently
I have 3 agents running:
2 out of 3 are stuck…2 out of 3 are stuck:
Request ID bfc26b5f-197d-40ca-8f31-c7d99294d52b 
Request ID f6e8f89b-f0dd-46f2-a6e1-ea1d435eb1d9
It’s a really a huge productivity killer…
My setup: Windows 11 + WSL2 (all 100% up-to-date)
Version: 3.19.19 (user setup)
VS Code Extension API: 1.128.0
Commit: 6496ea8a068aebfcd21990e70ff522e9abf10c80
Date: 2026-09-08T16:25:33.352Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
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: Windows_NT x64 10.0.26200
EDIT: This time restarting Cursor didn’t help… both bricked chats before restart are still bricked 
Title: 3.19.19 — every agent tool call has ~13–35s of fixed overhead (terminal executor spans leaking for hours, Windows)
Since 3.19.19 auto-installed, every agent tool call carries 20–35 seconds of overhead that has nothing to do with the work being done. Commands that finish in ~100ms return to the agent 20–35 seconds later. Turns that used to take 30 seconds now take 10–15 minutes.
I measured this fairly carefully, so here’s the evidence rather than just “it’s slow.”
I timed the work inside each command with a stopwatch and compared it to the tool call’s wall time:
Command
Work inside
Wall time
Overhead
Stopwatch echo
115 ms
never returned (errored)
hung
Resolve 4 $PROFILE paths
~10 ms
23.4 s
~23 s
3Ă— process launch + scan
~2.5 s
27.4 s
~25 s
Directory size scan
~3 s
36.1 s
~33 s
The hung one is the clearest case: the command wrote its output within the first second, then the executor never returned control and the call was reported as errored minutes later. I’ve now seen that exact pattern three times — full output produced, no exit status.
Parsed from cursor.requestTraces.log (13,997 spans, 24h):
Span
Count
Avg
Max
PowerShellState.execute
82
2,093 s
55,933 s
LazyTerminalExecutor.execute
82
2,093 s
55,933 s
ShellCoreExecutor.execute
82
2,094 s
55,933 s
agent.request
47
260 s
4,598 s
exec.handle
1,535
21 s
923 s
queueWait
—
~0 s
14 ms
Two things stand out. exec.handle averaging 21s across 1,535 calls matches my externally measured overhead almost exactly. And three shell executor spans ran 55,933 s (~15.5 hours) each — they opened around 22:15 one night and weren’t released until 13:44 the next day.
Critically, there was only one powershell.exe process running at the time, age 0 minutes, and a fresh process spawns in ~800ms. So those multi-hour spans are leaked state inside the terminal executor’s bookkeeping, not stranded OS processes. Nothing to clean up at the OS level.
queueWait is ~0, so this isn’t client-side queueing.
Rate limiting — exactly 1 rate-limit line in 24h of logs, and it was a GitHub MCP call hitting GitHub’s own API limit. (Heads up for anyone else grepping: naive 429 matching gives ~1,000 false positives from hex span IDs like spanId=4299570092aab6b5.)
Network — TCP 443 to api2.cursor.sh 112 ms, cursor.com 124 ms, TLS handshake 94 ms.
TLS interception / proxy — cert issuer is Let’s Encrypt, not a corporate CA. WinHTTP direct, no PAC.
PowerShell profile — none exists at any $PROFILE path.
Process creation — powershell.exe -NoProfile launches in 714–830 ms.
MCP server count / context size — disabling unused MCP servers changed nothing, and context size doesn’t explain overnight onset.
Machine load — nothing pathological.
Measurement
Before restart
After restart
Trivial echo (107 ms of work)
never returned
13.5 s
Span-stats query (~1.2 s of work)
21–36 s
13.2 s
ShellCoreExecutor avg / max
2,093 s / 55,933 s
60 s / 106 s
A full restart clears the multi-hour leaked spans and stops the outright hangs, but ~13 s of per-call overhead remains on a 100ms command. It then degrades again as state re-accumulates.
Cursor 3.19.19 (Cursor.exe written 2026-09-08 17:15, auto-update — symptoms began that evening), Windows 10.0.26100, Windows PowerShell, 3 workspace roots.
Rollback isn’t an option for me: updates are enforced in my environment, there’s no cursor-updater cache or cached installer locally, so a downgrade would be overwritten anyway.
Did the terminal executor change in 3.19.19?
Why do ShellCoreExecutor / LazyTerminalExecutor / PowerShellState spans stay open for hours with no live process behind them?
Is there a later patch that already fixes this?
Any client-side setting that reduces per-call executor overhead in the meantime?
