Cursor is killing my mac! (process: rg and host-extension)

I have been using Cursor for 2 months and had no problem but today! I’m on a M4 Mac Mini 16GB ram (the basic configuration) and macOS Sequoia 15.4

Cursor is eating my whole RAM and CPU until my mac freezes and crashes!

It just happened 4 times in a row, I can’t use Cursor more than 5 minutes!

The culprits seem to be the processes extension-host and rg from Cursor Helper.

I just uninstalled and reinstalled a fresh Cursor with nothing and I experienced the same!

When Cursor is iddle it’s okay, but the moment I start asking a question to an AI, it goes insane!

Attached pictures from my phone (my mac was freezing and crashing) about the processes getting all the ressources.


Hey, the extension-host indicates that the issue is with the extensions. To check this, try starting in safe mode: cursor --disable-extensions. If everything is okay, open Process Explorer to try to identify the problematic extension. Also, if you have the “Import Cost” extension installed, there have been complaints about it before, simply removing it should solve the problem. Additionally, please refer to our troubleshooting guide:

Thank you but it doesn’t resolve the issue!

As I said, I experienced crashes even after a fresh install of Cursor, so every settings are by default and I have 0 extension!

Let me show you in a video.

  • Machine: M4 Mac Mini 16 GB RAM
  • OS: macOS Sequoia 15.4
  • Fresh install of Cursor, default settings, no extension
  • No other apps opened, except activity monitor and iTerm (for htop)
  • AI request failling

Under normal usage and load, Cursor would make the mac crashes!

https://www.youtube.com/watch?v=fiu5LZ1A7yM

@danperks

Any news on that problem? Experiencing the same issue here on the same machine.
Some times it’s even crashing without using the ai part of the cursor. It will spike my kernel_status process above 100% of cpu use and the machine freeze, just while reading bigger json for example. Once cursor is killed everything is back to normal.
Cursor helper process doesn’t seems to be the problem for me.

1 Like

Hey, this is a weird one but I’ve escalated it to the team to take a look at!

try to total re install
delete cursor and vscode au usual and clean all temps and app folders using bash
(look my topic)
for me - help, connection restored and no hyper util in hardware

possible has a problem between cursor abstract layer and api func in vscode
some settings stands and conflict with update

Hi!

I found a workaround from KKonstantinov here: sometimes rgArm processes and 100% CPU usage! · Issue #1341 · getcursor/cursor · GitHub

So temporary solution is to ignore all possible big files and big folders by putting them in the settings.json

I tried also adding them in .cursorignore but it doesn’t work at all!

I understand that opening a big repo can lead to waiting time or slower process, but it’s still not a normal behavior.
Just opening the app shouldn’t lead to the Helper + ripgrep taking over the whole RAM and CPU!

Thanks for the report! I’m an engineer at Cursor looking into this issue. Out of curiosity, would you be willing to share what was in your .cursorignore?

1 Like

Sure!

I put everything that could be big, it’s same as my settings.json

.cursorignore

**/.cache/
**/.cargo/
**/.DS_Store
**/.foundry/
**/.git/
**/.local/
**/.npm/
**/.nvm/
**/.oh-my-zsh/
**/.rustup/
**/.wine/
**/Applications/
**/build/
**/Downloads/
**/Library/
**/node_modules/
**/Pictures/
**/Screenshots/
**/target/
**/VirtualBox VMs/
**/Virtual\ Machines.localized/

settings.json

{
    "search.followSymlinks": false,
    "files.exclude": {
        "**/.cache": true,
        "**/.cargo": true,
        "**/.DS_Store": true,
        "**/.foundry": true,
        "**/.git": true,
        "**/.local": true,
        "**/.npm": true,
        "**/.nvm": true,
        "**/.oh-my-zsh": true,
        "**/.rustup": true,
        "**/.wine": true,
        "**/Applications": true,
        "**/build": true,
        "**/Downloads": true,
        "**/Library": true,
        "**/node_modules": true,
        "**/Pictures": true,
        "**/Screenshots": true,
        "**/target": true,
        "**/VirtualBox VMs": true,
        "**/Virtual Machines.localized": true,
    },
    "files.watcherExclude": {
        "**/.cache/**": true,
        "**/.cargo/**": true,
        "**/.foundry/**": true,
        "**/.git/**": true,
        "**/.local/**": true,
        "**/.npm/**": true,
        "**/.nvm/**": true,
        "**/.oh-my-zsh/**": true,
        "**/.rustup/**": true,
        "**/.wine/**": true,
        "**/Applications/**": true,
        "**/build/**": true,
        "**/Downloads/**": true,
        "**/Library/**": true,
        "**/node_modules/**": true,
        "**/Pictures/**": true,
        "**/Screenshots/**": true,
        "**/target/**": true,
        "**/VirtualBox VMs/**": true,
        "**/Virtual Machines.localized/**": true
    },
    "search.exclude": {
        "**/.cache": true,
        "**/.cargo": true,
        "**/.foundry": true,
        "**/.git": true,
        "**/.local": true,
        "**/.npm": true,
        "**/.nvm": true,
        "**/.oh-my-zsh": true,
        "**/.rustup": true,
        "**/.wine": true,
        "**/Applications": true,
        "**/build": true,
        "**/Downloads": true,
        "**/Library": true,
        "**/node_modules": true,
        "**/Pictures": true,
        "**/Screenshots": true,
        "**/target": true,
        "**/VirtualBox VMs": true,
        "**/Virtual Machines.localized": true
    }
  }

By the way, do you have an idea when .cursorignore will be fully operational?
I saw this line in docs:

Cursor makes its best effort to block access to files listed in .cursorignore

Making its best effort is a bit too permissive :laughing:

By ‘best effort’ we just mean that we cannot 100% guarantee that a file you add won’t be sent (due to a very hidden bug we haven’t found).

Basically, if you are working on NSA-level stuff, don’t use Cursor haha!

cc @ygaitonde

1 Like

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