Instant Grep Beta can peg CPU by indexing $HOME with multiple ripgrep processes following symlinks

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor version: 3.7.19
macOS: 26.5.x arm64
Feature involved: Settings → Indexing → “Index Repositories for Instant Grep (BETA)”
Impact: Severe CPU/load spike; machine becomes almost unusable.

Summary:
After opening a Cursor chat/window with /Users/<user> as the workspace folder, Cursor started multiple concurrent rg processes from its bundled ripgrep binary. Disabling “Index Repositories for Instant Grep (BETA)” made the machine return to normal.

Evidence:

  • Cursor app version: 3.7.19
  • Cursor app modified locally around 2026-06-07 02:08:56 +0800
  • Cursor workspace storage contained:
    • folder: file:///Users/<user>
    • workspace id: 7fa3caacd525fe6d7022c47f0ddcb4ab
  • CPU/load during incident:
    • load averages: 179.09 140.75 91.48
    • later still 104.13 194.30 140.82
  • Process tree showed 5 concurrent Cursor ripgrep processes:
    • parent: Cursor Helper (Plugin): extension-host
    • binary: /Applications/Cursor.app/Contents/Resources/app/node_modules/@vscode/ripgrep/bin/rg
    • command shape:
      rg --files --hidden --case-sensitive --no-require-git \
  -g '!**/.git' -g '!**/.svn' -g '!**/.hg' \
  -g '!**/.DS_Store' -g '!**/Thumbs.db' \
  -g '!**/node_modules' -g '!**/bower_components' \
  -g '!**/*.code-search' \
  --no-ignore-parent --follow --no-config --no-ignore-global
  • lsof showed each rg had cwd /Users/<user>.
  • Opened directories included large/non-project locations:
    • /Users/<user>/Library/Containers/...
    • /Users/<user>/.local/share/fnm/node-versions/...
    • /Users/<user>/.cocoapods/repos/cocoapods/Specs/...
  • System services such as syspolicyd and trustd also spiked, likely due to the huge file traversal.

Expected behavior:
Cursor should not aggressively index the user’s entire home directory just because it was opened as a workspace or used for a chat. If it does index, it should be bounded, cancellable, and safe by default.

Suggested fixes:

  1. Do not auto-enable Instant Grep indexing for $HOME, /Users/<user>, /, or similarly broad folders.
  2. Make the “fewer than 50,000 files” check robust against hidden folders and symlink traversal.
  3. Do not use --follow by default for background indexing.
  4. Add CPU/concurrency limits for Instant Grep indexing.
  5. Respect .cursorignore, .cursorindexingignore, search.exclude, and common heavy directories before spawning rg.
  6. Surface an indexing progress/cancel UI when a background indexer starts.
  7. If a workspace is too broad, show a warning: “This folder appears to be your home directory; indexing may scan millions of files.”

Workaround:
Turning off “Index Repositories for Instant Grep (BETA)” immediately stopped the problem.

Steps to Reproduce

enable the beta grep indexing feature and open a workspace in home folder

Operating System

MacOS

Version Information

Cursor version: 3.7.19

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. The process tree, the exact rg command, and the load averages are really helpful.

This is a known class of issue. If the workspace root is too broad like your home folder or /, indexing and file enumeration can spiral into scanning millions of files, including Library, caches, and symlinks. We don’t have a safeguard or warning for these root folders yet. We’re tracking it, but I can’t share an exact fix timeline right now.

You already found the right workaround, turning off Index Repositories for Instant Grep BETA. Also, to avoid this happening again:

  • Open a specific project as your workspace, not /Users/<user> as a whole.
  • If you need a broad root, add heavy directories to .cursorignore or search.exclude.

I noted your fix ideas like a warning for the home folder, limiting --follow, and concurrency limits, and I’ll attach them to the internal tracking item. If there’s an update, I’ll reply in the thread.