Hey, thanks for the report, and sorry this has been dragging on for so long. I know it really gets in the way of getting work done.
To figure out which part of Cursor is using the memory, we’ll need to capture a few things next time memory is already high:
With Cursor open and memory already high, press Cmd+Shift+P, type Process Explorer, then run Developer: Open Process Explorer. Take a screenshot of that window and attach it here. It shows memory per process window, extension host, language servers, etc, which is exactly what we need.
In the same session, press Cmd+Shift+P, run Capture and Send Debugging Data, keep the default boxes checked, and press Enter. Reply here once it finishes.
Roughly share how many Cursor windows were open, how big the largest repo is number of files or GB, and whether memory grows right after opening the repo or slowly over a few hours.
Two quick experiments can help narrow it down:
Fully quit Cursor with Cmd+Q, reopen it with only ONE large repo, and watch Activity Monitor for 10 to 15 minutes. Does memory still grow with just one window?
In that one window, press Cmd+Shift+P and run Extensions: Disable All Installed Extensions for this Workspace, then reload the window. Does memory growth stop with extensions disabled? If yes, re enable them one by one GitLens first to find the culprit.
As a temporary workaround, go to Cursor Settings > Indexing and turn off Index Repositories for Instant Grep. This stops the local search indexer, which can be heavy on very large repos.
Let me know how it goes. The Process Explorer screenshot will usually make it obvious where to look next.
Hey, thanks for sending the screenshot, and sorry this is getting in the way of your work. I can see the out of application memory dialog. Cursor is at 12.51 GB, but Docker Desktop is also at 10.58 GB and Chrome at 3.05 GB. So memory is basically maxed out by a few apps at the same time, which is why the system starts hanging.
I get that when it hangs you can’t open the command palette. There’s another way to grab info without it:
Open Activity Monitor, it’s a separate app and it usually still responds even when Cursor is stuck. Sort by the Memory column. When Cursor starts growing, expand the triangle next to the Cursor process to show child processes, then take a screenshot. I’m trying to see what’s actually blowing up, a window renderer, extension host, or a language server like GitLens or tsserver.
How do you open repositories, one repo per window, or do you open one parent folder like your home folder that contains lots of git repos inside? The second case makes Cursor scan all nested repos and it can be very memory heavy.
To reduce the load right now:
Cursor Settings (not VS Code settings) > Code Intelligence > turn off Index Repositories for Instant Grep. This stops the local search indexer, which can be heavy on big repos.
Open one large repo per window, not multiple windows at once.
While you’re working in Cursor, if you can, close Docker Desktop and extra Chrome tabs. Together they’re using over 13 GB and pushing the system to the limit.
Please send a screenshot from Activity Monitor with the Cursor process tree expanded. That usually makes it obvious where to dig next. Let me know how it goes.
