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

**URL:** <https://forum.cursor.com/t/cursor-3-16-17-agent-window-intermittently-freezes-during-long-agent-runs-main-process-reaches-99-cpu/168695>\
**Category:** Bug Reports\
**Tags:** crashes, performance, windows, agents-window\
**Created:** [August 18, 2026, 1:06am UTC](https://forum.cursor.com/t/cursor-3-16-17-agent-window-intermittently-freezes-during-long-agent-runs-main-process-reaches-99-cpu/168695 "2026-08-18T01:06:27Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ducheved](https://avatars.discourse-cdn.com/v4/letter/d/46a35a/32.png) [@Ducheved](https://forum.cursor.com/u/Ducheved)\
**Post date:** [August 18, 2026, 1:06am UTC](https://forum.cursor.com/t/cursor-3-16-17-agent-window-intermittently-freezes-during-long-agent-runs-main-process-reaches-99-cpu/168695/1 "2026-08-18T01:06:27Z")

</div>

### 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

---

<div class="post-metadata">

**Author:** ![Ducheved](https://avatars.discourse-cdn.com/v4/letter/d/46a35a/32.png) [@Ducheved](https://forum.cursor.com/u/Ducheved)\
**Post date:** [August 18, 2026, 1:06am UTC](https://forum.cursor.com/t/cursor-3-16-17-agent-window-intermittently-freezes-during-long-agent-runs-main-process-reaches-99-cpu/168695/4 "2026-08-18T01:06:57Z")

</div>

[cursor-freeze\_82cc\_2026-08-17\_20-31-22-914.txt](https://forum.cursor.com/uploads/short-url/bVCGgHJ7tlqMPhV3r016YqVJuM7.txt) (70.0 KB)

---

<div class="post-metadata">

**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\
**Post date:** [August 18, 2026, 12:38pm UTC](https://forum.cursor.com/t/cursor-3-16-17-agent-window-intermittently-freezes-during-long-agent-runs-main-process-reaches-99-cpu/168695/6 "2026-08-18T12:38:54Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Ducheved](https://avatars.discourse-cdn.com/v4/letter/d/46a35a/32.png) [@Ducheved](https://forum.cursor.com/u/Ducheved)\
**Post date:** [August 18, 2026, 1:17pm UTC](https://forum.cursor.com/t/cursor-3-16-17-agent-window-intermittently-freezes-during-long-agent-runs-main-process-reaches-99-cpu/168695/8 "2026-08-18T13:17:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![michaelmanly](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/michaelmanly/32/116827_2.png) [@michaelmanly](https://forum.cursor.com/u/michaelmanly)\
**Post date:** [August 18, 2026, 2:20pm UTC](https://forum.cursor.com/t/cursor-3-16-17-agent-window-intermittently-freezes-during-long-agent-runs-main-process-reaches-99-cpu/168695/9 "2026-08-18T14:20:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Ducheved](https://avatars.discourse-cdn.com/v4/letter/d/46a35a/32.png) [@Ducheved](https://forum.cursor.com/u/Ducheved)\
**Post date:** [August 18, 2026, 7:00pm UTC](https://forum.cursor.com/t/cursor-3-16-17-agent-window-intermittently-freezes-during-long-agent-runs-main-process-reaches-99-cpu/168695/10 "2026-08-18T19:00:19Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\
**Post date:** [August 26, 2026, 10:28am UTC](https://forum.cursor.com/t/cursor-3-16-17-agent-window-intermittently-freezes-during-long-agent-runs-main-process-reaches-99-cpu/168695/24 "2026-08-26T10:28:57Z")

</div>

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](http://sqlite.org/) works):

```auto
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!

---

<div class="post-metadata">

**Author:** ![Oleg\_B1](https://avatars.discourse-cdn.com/v4/letter/o/41988e/32.png) [@Oleg\_B1](https://forum.cursor.com/u/Oleg_B1)\
**Post date:** [August 29, 2026, 6:24pm UTC](https://forum.cursor.com/t/cursor-3-16-17-agent-window-intermittently-freezes-during-long-agent-runs-main-process-reaches-99-cpu/168695/25 "2026-08-29T18:24:14Z")

</div>

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)

---

<div class="post-metadata">

**Author:** ![system](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/system/32/99069_2.png) [@system](https://forum.cursor.com/u/system)\
**Post date:** [October 8, 2026, 9:50am UTC](https://forum.cursor.com/t/cursor-3-16-17-agent-window-intermittently-freezes-during-long-agent-runs-main-process-reaches-99-cpu/168695/27 "2026-10-08T09:50:41Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.