Cursor Runaway memory usage

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The last couple of days I’ve had cases where the Cursor IDE has just runaway with massive amounts of memory usage (twice today I killed it at 100GB and 89GB, yesterday it ran up to 94GB) - needless to say my system became sluggish and unusable.

This only seemed to recently start happening recently.

Steps to Reproduce

Using Cursor IDE (primarily Agent window) for ~4-5 hours, switching between multiple local agents working on different projects. Eventually the memory usage is so much it becomes sluggish.

Other things I’m typically doing:

  • using embedded terminal to run things like lint or unit test coverage.
  • typical day would be 5-10 agents each working on epics, resulting in ~3-6k of code per epic (including unit tests, etc)

Expected Behavior

Not use 100GB of memory. :smiley:

Operating System

MacOS

Version Information

Version: 3.5.38
VSCode Version: 1.105.1
Commit: 009bb5a3600dd98fe1c1f25798f767f686e14750
Date: 2026-05-26T21:32:06.537Z (2 days ago)
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

Auto or Composer

Does this stop you from using Cursor

Yes - Cursor is unusable

6

This is a known issue with the Glass (Agents Window) layout during long sessions with heavy agent use. Running 5-10 agents over 4-5 hours is exactly the usage pattern where memory grows unboundedly. Our team is aware and actively tracking this.

One note on the 89-100GB numbers: macOS Activity Monitor rolls all child processes (including subagents) into the parent “Cursor” entry, so the actual renderer memory may be lower than it appears. That said, the growth is real and shouldn’t happen.

Workarounds that should help:

  1. Reload the window periodically – Cmd+Shift+P > “Developer: Reload Window” every couple of hours. This resets the Glass renderer and reclaims memory without fully restarting.

  2. Fully quit Cursor with Cmd+Q (not just closing windows) every few hours during heavy sessions. This cleans up all child processes.

  3. Cap concurrent agents – if you’re running 5-10 agents simultaneously, try keeping it to 3-4 at a time. Each agent spawns child processes that compound memory usage.

  4. Switch to Editor layout temporarily if the growth is too disruptive: Cmd+Shift+P > “Toggle Editor Layout.” This uses a different rendering architecture.

  5. Monitor with Process Explorer (Cmd+Shift+P > “Developer: Open Process Explorer”) to catch growth before it reaches system-affecting levels.

Could you share what Process Explorer shows when the memory spikes? Specifically, which process type is consuming the most (renderer, extensionHost, ptyHost)? That would help narrow down whether this is the renderer leak pattern or subagent fan-out.

No ETA on the fix yet, but this is being tracked given the severity for power users.