Prevent ripgrep from consuming all laptop resources?

Support Bug Reports
,
1

Describe the Bug

See the image attached. Every cursor chat very frequently kicks off numerous ripgrep calls which end up consuming all CPUs making laptop performance significantly degraded. And I can see that there are sensible !-based exclusions being used with these ripgrep calls like !.git/, !.DS_Store and similar. How can I examine the logs at least to figure out which directories or particular ripgrep searches are causing this degradation? Laptop is robust: M4, 48GB, 14 Core.

Steps to Reproduce

  1. Version: 3.8.11 (Universal)
    VS Code Extension API: 1.105.1
    Commit: e56ad3440df06d22ca7501e65fd518e905486ef0
    Date: 2026-06-18T01:40:18.333Z (3 days ago)
    Layout: glass
    Build Type: Stable
    Release Track: Default
    Electron: 40.10.3
    Chromium: 144.0.7559.236
    Node.js: 24.15.0
    V8: 14.4.258.32-electron.0
    xterm.js: 6.1.0-beta.256
    OS: Darwin arm64 25.5.0

  2. run concurrent cursor threads on the versions above.

  3. monitor w/ htop.

  4. observe ripgrep commands like in the image I have attached

Screenshots / Screen Recordings

Screenshot 2026-06-20 at 2.13.25 PM.png
Screenshot 2026-06-20 at 2.13.25 PM.png3456×666 897 KB

Operating System

MacOS

Version Information

Version: 3.8.11 (Universal)
VS Code Extension API: 1.105.1
Commit: e56ad3440df06d22ca7501e65fd518e905486ef0
Date: 2026-06-18T01:40:18.333Z (3 days ago)
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

Does this stop you from using Cursor

Yes - Cursor is unusable

7

Hey there!

Those rg processes with --files and no search term aren’t content searches, they’re Cursor listing every file in your open workspace root(s). Cursor runs several of these full-tree walks in parallel (capped at about half your CPU cores, so up to 8 on your 14-core M4), and each running agent thread kicks off its own batch. On a large repo each walk takes a while, so they stack up and peg every core. So there isn’t a single “bad” subdirectory to hunt down in logs, it’s the whole open root being re-listed, multiplied by how many threads you’re running. This is a known issue and the team is actively working on making Cursor call ripgrep far less often.

A few things that should bring the CPU back down right away:

  1. Open the specific project folder as your workspace, not a broad root. If you have your home directory or a giant monorepo root open, every walk traverses the entire tree. Opening just the project you’re working in is the biggest lever.
  2. Exclude heavy/generated directories in your settings.json so the file walk skips them:
{
"search.exclude": {
"**/node_modules": true,
"**/dist": true,
"**/build": true,
"**/.venv": true
},
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true
}
}

(swap in whatever large/vendored/data dirs apply to your repo)

  1. Turn off symlink following, that’s the --follow flag you see, which can balloon the walk through linked directories:
{ "search.followSymlinks": false }
  1. Add those same heavy directories to a .cursorignore / .cursorindexingignore in your repo root to keep the agent’s search and indexing off them too: Ignore files docs.
  2. Run fewer agent threads at once against a very large repo, each concurrent thread fans out its own batch of walks, which is what takes you from “busy” to “all cores pegged.”
  3. If you have Settings → Indexing → “Index Repositories for Instant Grep (BETA)” enabled, try toggling it off, it’s been the trigger for some users.

If you want to see which process is spawning them, Cmd+Shift+P → Developer: Open Process Explorer shows the helper behind each rg.

Give the workspace-scoping and excludes a try and let me know if your CPU settles. If it’s still pegging after that, grab a Process Explorer export while it’s hot and I’ll dig in further.