Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
This is not the Grok “Taking longer than expected” issue
I originally posted this as a reply in Taking longer than expected in almost every Grok run, but it belongs on its own. The staff explanations in that thread — model slow to start under Grok capacity load, and a provider incident plus long-conversation re-upload — describe a different mechanism than what I measured.
What I’m reporting is overhead on tool call execution, not model start latency:
queueWait spans are ~0 ms, so nothing is queueing.
The overhead lands on commands that do literally nothing (Write-Output “s1”).
It scales with session uptime, not with time of day, model, or conversation length.
The overhead grows with session age — measured across two independent sessions
This is the core finding. Same trivial command (Write-Output), nothing else running:
Session started 21:39 (after reinstall)
uptime ~2 min → 2.2 s
uptime ~5 min → 5.89 / 5.23 / 5.57 / 6.98 s (median 5.7 s)
Session started 07:53 (next morning, fresh launch)
uptime ~8 min → 4.54 / 5.10 / 6.43 / 6.43 s (median 5.8 s)
uptime ~68 min → 11.19 / 10.92 / 11.29 / 11.29 s (median 11.2 s)
Two separate sessions, roughly 10 hours apart, hit the same ~5.7–5.8 s at comparable session age. That controls for time-of-day and backend load, which would otherwise be the obvious confound. Within the morning session, held constant, the cost then doubled to 11.2 s by 68 minutes — roughly +5 s per hour.
Before I reinstalled, a session left to run through an afternoon reached 21–36 s per call, with some calls never returning at all.
The overhead is not the command
Measured by stopwatch inside each command versus the tool call’s wall time:
Command Work inside Wall time Overhead
Stopwatch echo 115 ms never returned hung
Resolve 4 $PROFILE paths ~10 ms 23.4 s ~23 s
3x process launch + scan ~2.5 s 27.4 s ~25 s
Directory size scan ~3 s 36.1 s ~33 s
Network + TLS probes ~1 s 21.4 s ~20 s
The hung case is the clearest: the command wrote its output within the first second, the executor never returned control, and the call was reported as errored minutes later. I saw that exact pattern three times — full output produced, no exit status.
Cursor’s own spans agree
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
exec.handle averaging 21 s across 1,535 calls matches my externally measured overhead almost exactly.
Three shell executor spans ran 55,933 s (~15.5 hours) each, opening around 22:15 one night and not completing until 13:44 the next day.
At the time of inspection there was exactly one powershell.exe process running, age 0 minutes, and a fresh process spawns in ~800 ms. So those multi-hour spans are leaked state inside the executor’s bookkeeping, not stranded OS processes — there is nothing to clean up at the OS level, and only a full application restart clears it.
Reinstalling the same build lowers the floor but does not stop the climb
Both release tracks report 3.19.19 on identical commit SHAs, so there was nothing newer to move to. I reinstalled the same version over the top (confirmed applied — unins000.exe rewritten):
State Work inside Wall time
Degraded, pre-restart 10 ms – 3 s 21–36 s + hangs
Fresh session, restart only 107 ms 13.5 s
Fresh session, after reinstall ~0 ms ~5.7 s
68 min uptime, after reinstall ~0 ms ~11.2 s
Comparing fresh session to fresh session, restart alone gave 13.5 s while reinstall settles near 5.7 s. That suggests the auto-update path may leave a degraded install — worth checking whether the in-place updater can leave mismatched or partially written files on Windows user-scope installs. But the reinstall only lowered the starting point; the per-hour climb continued unchanged.
Ruled out
Rate limiting — exactly 1 rate-limit line in 24h of logs, and it was a GitHub MCP call hitting GitHub’s own API limit. (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. A 196 MB download from downloads.cursor.com pulled at ~20 MB/s.
TLS interception / proxy — cert issuer is Let’s Encrypt, not a corporate CA. WinHTTP direct, no PAC, ProxyEnable=0.
PowerShell profile — none exists at any of the four $PROFILE paths.
Process creation — powershell.exe -NoProfile launches in 571–830 ms.
Orphaned processes — only 1 PowerShell process running, age 0 min.
MCP server count / context size — disabling unused MCP servers changed nothing, and context size does not explain onset or the uptime correlation.
Machine load — nothing pathological; no reboot needed, uptime since Sep 3.
Time of day / backend load — controlled for by the two-session comparison above.
Not just my machine
Post #25 in that thread is another user on the identical build — 3.19.19, commit 6496ea8a…, Windows 11 + WSL2 — reporting stuck agents and “a really huge productivity killer.” Their post #24 also found restarting Cursor temporarily restored usability, matching my restart measurements, and by #25 restarting had stopped helping.
Environment
Cursor 3.19.19 (user setup)
Commit 6496ea8a068aebfcd21990e70ff522e9abf10c8c
OS Windows_NT x64 10.0.26100
Shell Windows PowerShell (powershell.exe)
Install user-scope Inno Setup (%LOCALAPPDATA%\Programs\cursor)
Workspaces 3 roots
Rollback is not available to me: updates are enforced in my environment, and there is no cursor-updater cache or cached installer locally.
Steps to Reproduce
Run Cursor over a period of time. Queue keeps growing, takes forever to do anything
Expected Behavior
Faster performance. This makes the product unusable and prevents me from doing my job
Operating System
Windows 10/11
Version Information
Version: 3.19.19 (user setup)
VS Code Extension API: 1.128.0
Commit: 6496ea8a068aebfcd21990e70ff522e9abf10c80
Date: 2026-09-08T16:25:33.352Z
Layout: Agent Window
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.26100
For AI issues: which model did you use?
Any of them
Does this stop you from using Cursor
Yes - Cursor is unusable