[Performance] Cursor IDE causes severe system lag and high memory usage

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Describe the bug:
I am experiencing significant performance issues with Cursor. The application consumes an excessive amount of RAM, which leads to severe system lag and freezing, making it difficult to use

Steps to Reproduce

Open Cursor and load a medium-sized project (e.g., “midscene-ai-test-platform”).
Start using the Agent feature (Cmd+I) to generate or modify code.
Observe that after a few interactions, the system memory usage spikes significantly.
The entire computer becomes laggy, and typing in the editor has high latency.
Attempting to run diagnostics results in a “Could not collect diagnostics” error because Shell calls return no exit status.

“The screenshot shows the state after I already took action. The memory usage only dropped after I closed the IDE.”

Expected Behavior

Screenshots / Screen Recordings

image_178541752183321.png
image_178541752183321.png1234×214 27.3 KB

Operating System

MacOS

Version Information

OS: macOS Sequoia 15.6
RAM: 16GB
Cursor Version: 3.13.10

For AI issues: which model did you use?

=== Cursor Node Process Performance Sample (Simplified) ===

Process: node [PID 871]
Parent: Cursor Helper (Plugin) [PID 732]
Path: /Applications/Cursor.app/Contents/Resources/app/resources/helpers/node
OS: macOS 15.7.3 (Apple Silicon / ARM64)
Sample Time: 2026-07-30 20:41:53 (launched at 20:32:00)

— Memory Usage —
Physical footprint: 876.9M (peak: 959.8M)
This single Cursor helper process consumed ~877MB of physical RAM.

— Thread Status (All 2519 samples) —
Thread_9402 (Main): BLOCKED in kevent() — event loop not responding
Thread_9497 (DelayedTaskScheduler): BLOCKED in kevent() — no tasks being processed
Thread_9498-9501 (Worker threads x4): BLOCKED in __psynch_cvwait() — all waiting on condition variables, no work being executed
Thread_9561 (Inspector IO): BLOCKED in semaphore_wait_trap()
Thread_9576 (Work queue): BLOCKED in __workq_kernreturn() — idle, no work items

— Key Findings —

  1. ALL threads are blocked/idle — the process is in a “zombie” state, consuming ~877MB RAM but doing zero work.
  2. Main thread stuck in uv__io_poll → kevent: Node.js event loop is waiting for I/O events that never arrive.
  3. 4 worker threads stuck in __psynch_cvwait: Task queues are empty but threads are not terminating.
  4. This is a classic memory leak + thread leak pattern: the process allocates memory and spawns threads but never cleans them up.

— Top Blocked System Calls —
__psynch_cvwait: 10076 samples (worker threads waiting)
kevent: 5038 samples (event loop polling)
__workq_kernreturn: 2519 samples (idle work queue)
semaphore_wait_trap: 2519 samples (inspector thread)

=== End of Simplified Report ===

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report and the sample, it helps.

A couple clarifications on what you’re seeing. The node process at about 877MB, parent is Cursor Helper Plugin, is the TypeScript language server tsserver, not a zombie process. That memory size is normal for a medium-size project, and the blocked idle threads are just a normal idle event loop, not a leak. If you want, you can cap it via typescript.tsserver.maxTsServerMemory, but it likely won’t fix the main source of the lag.

The memory growth and overall system pressure, your screenshot shows 13,56GB out of 16GB with 5,6GB compressed, is a known issue we’re tracking. During long Agent sessions, chat state slowly builds up in memory. On a 16GB Mac it eventually hits the ceiling and causes lag. I can’t share an exact timeline yet, but I’ll post an update in the thread when we have one.

For now, this usually helps:

  • Clean the internal store, this is the biggest lever. Open Command Palette with Cmd+Shift+P, run Developer: Delete Old Chats… pick an age, then run GC Agent KV Blobs. This compacts the store and frees space. On a large store, GC can freeze the window for 1 to 2 minutes, that’s expected, don’t force close it.
  • Split long Agent work into multiple shorter chats instead of one endless session. The memory growth is tied to the accumulated state inside a single chat.
  • Quit Cursor with Cmd+Q, not the red window button. On macOS, closing the window doesn’t always stop background helper processes, and they can keep holding memory.
  • Restart Cursor when the system starts swapping.
  • Keep Cursor updated, improvements in this area ship gradually.

The error Could not collect diagnostics / Shell calls return no exit status happens because under load the backend for shell commands can hang. After a restart, once the pressure drops, diagnostics should work normally again.

Let me know if splitting into shorter sessions and cleaning the store helps in your case.