Cursor 3.16.17 Agent Window intermittently freezes during long Agent runs; main process reaches ~99% CPU

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

During long-running Agent sessions, Cursor intermittently becomes completely unresponsive.

When the freeze occurs:

  • the Agent Window stops responding to mouse and keyboard input;
  • Windows reports the main Cursor.exe process as Responding=False;
  • the main Cursor process consumes approximately one logical CPU core (~99%);
  • other Cursor processes remain alive.

In one captured occurrence:

  • main Cursor process: ~99% CPU, Responding=False, ~1.0 GiB working set
  • renderer: ~20% CPU
  • GPU process: ~5% CPU

The issue has reproduced multiple times during long autonomous Agent workloads.

Steps to Reproduce

  1. Open Cursor using the Agent Window layout on Windows.
  2. Start a long-running autonomous Agent task on a large repository.
  3. Let the Agent perform normal repository work for an extended period: file search/grep, reads and edits, terminal commands, builds, tests, Git operations, etc.
  4. Continue the same Agent session for a substantial amount of time.
  5. Eventually the Cursor UI may become completely unresponsive.
  6. During the freeze, the main Cursor.exe process becomes Responding=False while consuming approximately one logical CPU core.

The issue is intermittent; I do not currently have a short deterministic reproduction.

Expected Behavior

The Cursor UI should remain responsive while an Agent performs long-running or heavy work.

Agent execution should not block the main application window or prevent it from processing user input.

Operating System

Windows 10/11

Version Information

Version: 3.16.17 (user setup)
VS Code Extension API: 1.128.0
Commit: 6b2afae0257df2bb5e1835f15165dc2f0de056b0
Date: 2026-08-14T01:41:12.803Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Cursor Grok 4.6
Reasoning effort: Extra High

Additional Information

I ruled out several external causes before reporting this:

  • Microsoft Defender real-time, behavior, IOAV, and on-access scanning were disabled.
  • Windows Search indexing was stopped.
  • Physical disk latency and queue length were normal.
  • WSL2/Docker initially held ~11.7 GiB in reclaimable Linux filesystem cache, leaving Windows with ~1.42 GiB free RAM.
  • After reclaiming that cache, Windows free RAM increased to ~8.85 GiB and vmmemWSL working set dropped from ~10.3 GiB to ~3.54 GiB.
  • The same Cursor freeze continued to reproduce after memory pressure was removed.

During an actual freeze, Windows performance counters showed:

Main Cursor.exe:

  • ~99% processor time
  • Responding=False
  • ~1.0 GiB working set

Other Cursor processes:

  • renderer: ~20% CPU
  • GPU process: ~5% CPU

I also captured the main process with WinDbg while it was already unresponsive.

!runaway showed:

  • CrBrowserMain: 0:04:40.171 user CPU
  • V8Worker: 0:01:05.500
  • V8Worker: 0:01:03.078
  • V8Worker: 0:00:58.453
  • Chrome_IOThread: 0:00:35.250

CrBrowserMain was the dominant user-mode CPU consumer. Its captured stack contains Cursor/Electron V8, Node and libuv frames. Most other threads were waiting or idle.

The stack snapshot caught CrBrowserMain in a wait state, so I am not claiming that it identifies the exact hot function or root cause.

I have the full WinDbg !runaway + ~* kp output available if needed.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

4

cursor-freeze_82cc_2026-08-17_20-31-22-914.txt (70.0 KB)

6

Hi @Ducheved

Thanks a lot for the report, and sorry you’re running into this.

This might match a known issue that we’re already working. Could you confirm the size of the %APPDATA%\\Cursor\\User\\globalStorage\\state.vscdb file on your machine?

8

Hi! Yes it’s quite large: ~2.75 GB

Let me know if you’d like me to provide any additional diagnostics or inspect what is taking up space inside the database.

9

This is interesting because the agent work itself sounds fine right up until the Cursor process locks up.

Have you tried running the same long task outside the Cursor window, or is the whole run tied to that session?

Been working on remote agent execution so this kind of failure caught my eye.

10

I haven’t yet reproduced the same long-running task outside of Cursor, so I can’t make a direct comparison there.

What I can confirm is that the agent work appears to continue normally until the Cursor process itself starts locking up. During one of the freezes I attached WinDbg and saw the main Cursor process become Responding=Fals with roughly ~99% CPU usage. The dominant CPU thread was CrBrowserMain, with activity in the Electron/V8/Node/libuv path.

I also tried ruling out system resource pressure: reclaimed WSL memory (~11.7 GiB → ~606 MiB cache, Windows free RAM ~1.4 GiB → ~8.9 GiB), checked disk/Defender/Search activity, etc. The freeze still reproduced.

There were also many anysphere.cursor-agent-exec extension-host/workbench instances in the Cursor logs.

And, as mentioned above, my state.vscdb is unusually large at ~2.75 GB.

So at least from what I’ve observed, this looks more like the Cursor/Electron side locking up under a long agent session rather than the agent execution itself failing.

24

Hey @Ducheved, thanks for confirming. Since you offered, this would pin it down.

With Cursor fully closed, copy %APPDATA%\Cursor\User\globalStorage\state.vscdb somewhere else and run these two queries against the copy (the sqlite3.exe command-line tool from sqlite.org works):

sqlite3 state-copy.vscdb "SELECT key, ROUND(LENGTH(value)/1048576.0,1) AS mb FROM ItemTable ORDER BY LENGTH(value) DESC LIMIT 15;"
sqlite3 state-copy.vscdb "SELECT CASE WHEN INSTR(key,':')>0 THEN SUBSTR(key,1,INSTR(key,':')-1) ELSE key END AS prefix, COUNT(*) AS n, ROUND(SUM(LENGTH(value))/1048576.0,1) AS mb FROM cursorDiskKV GROUP BY prefix ORDER BY SUM(LENGTH(value)) DESC LIMIT 15;"

Paste the output here — it only includes key names and sizes, no chat content!

25

getting similar experience with cloud agent run.

Version: 3.18.9
VS Code Extension API: 1.128.0
Commit: 2ba48ff3f7514cc4643c52ca9f7b3173d9b66130
Date: 2026-08-27T01:42:22.092Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.6.0

both web version and desktop version are on high CPU load and unresponsive when looking at the long running /goal chat. I let it running overnight.

(the goal decided to open 1000+ PRs as well, they kept opening inside the side padel as well, which may have added to the issue)