Excessive memory usage by Cursor Renderer

Support Bug Reports
1

Cursor performance in the last few days/ week is continuing to be terrible (captured in other posts) and now I see that the Cursor renderer is consistently taking up more than 5GB of memory (I am on Mac OS 26.3.1, Apple M4, 16GB). Nothing has changed with respect to the work I have been doing - same repo/ codebase/ workspace and similar fixes being made but a serious degradation lately. Wondering what others’ experience is in this regard. (Update: Chat response still basically frozen with ‘Reconnecting’ while memory usage has shot up to almost 8GB. Killing and restarting).

4

Hey, this looks like one of the known renderer memory leaks. We’ve got a few open issues in this area like listeners in review and diff panels, agent-exec handlers, and stream-buffer chunks. Over a long session, any of these can push the renderer to a few GB. We’re looking into it, but I can’t share an ETA yet.

To narrow it down, a couple questions and steps:

  • What Cursor version are you on? Cursor > About
  • Open Process Explorer when the renderer is already bloated and send a screenshot. Cmd+Shift+P then Developer: Open Process Explorer
    We want to see which process is holding the memory like renderer, extensionHost, or ptyHost.
  • Check Extension Monitor: Settings > Application > Experimental > Extension Monitor Enabled, then Developer: Open Extension Monitor
    If any extension is heavy on CPU or RAM, it should show up there.
  • Quick sanity check: run cursor --disable-extensions from the terminal on the same session and repo. If memory doesn’t grow as aggressively, it’s likely extension-related.

Temporary workarounds that help in similar reports:

  • Close review and diff panels after long agent runs, the leak often builds up there
  • Restart the window in long sessions with Developer: Reload Window
  • Don’t keep multiple agent sessions running in parallel in the same window

Once you’ve gathered the info, attach it here and we’ll dig into your specific case.

5

I am on latest version of Cursor (3.1.17). I could not run the diagnostics per your suggestion because I was able to avoid this problem by simply switching to Editor window instead of the new Agents window. Before switching, I tried killing/ restarting/ rebooting/ starting a new chat and so on, and nothing made a difference. That is when I decided to switch back and that worked. I am not running or don’t need to run parallel agents etc. and the Editors window is sufficient for my purpose.

7

Thanks, that’s a helpful data point. The fact that the Editor window stays clean while the Agents window grows to 5 to 8 GB without parallel sessions matches a known group of bugs around the new Agents window surface, where listeners and composer state can accumulate during long sessions. We’re tracking the issue, but there’s no ETA for a fix yet.

If you decide to try the Agents window again and notice memory creeping up, please grab a screenshot of Process Explorer before restarting Cmd+Shift+P → Developer: Open Process Explorer. Which process is growing renderer, extensionHost, or ptyHost and roughly how long it’s been since the session started will really help narrow down which leak path is getting triggered for you.

For now, using the Editor window as a workaround is the right call if it covers your flow.