Extension host rg uses --no-ignore --follow and walks symlinks excluded by .cursorignore

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The extension host starts ripgrep with --no-ignore and --follow. .cursorignore is not applied. A symlink whose name matches the ignore pattern is followed out of the workspace. The process used about 800% CPU until it was killed.

Observed command. The working directory was the workspace root. The parent process was “Cursor Helper (Plugin): extension-host”.

rg --files --hidden --case-sensitive --no-require-git -g '**/package.json' -g '!**/.git' -g '!**/.svn' -g '!**/.hg' -g '!**/.DS_Store' -g '!**/Thumbs.db' -g '!**/node_modules/**' --no-ignore --follow --no-config --no-ignore-global

.cursorignore contained only:

**/_*

The workspace has a symlink named _home whose target is the home directory. That name matches **/_*. lsof showed rg had a file open under the symlink target, outside the workspace.

Activity Monitor showed about 836% CPU and about 49 minutes of CPU time after roughly 6 minutes of wall time. A later sample was about 782% CPU at 7 minutes elapsed. The process did not exit on its own.

The -g list did not include the .cursorignore pattern. --no-ignore means rg will not read .cursorignore, .gitignore, or .ignore.

Steps to Reproduce

  1. In a git repo, add a symlink whose name starts with an underscore and points at a large directory such as the home directory. The name used here was _home.
  2. Add a root .cursorignore containing **/_*
  3. Open the folder in Cursor 3.27.6 on macOS.
  4. In Activity Monitor or ps, find rg launched by the Cursor extension host.

Expected Behavior

.cursorignore should exclude that symlink before it is followed. This scan should not drop .cursorignore via --no-ignore, and it should not walk the symlink target. search.followSymlinks and Ignore Symlinks in Cursor Ignore Search should apply to this walk.

Operating System

MacOS

Version Information

Version: 3.27.6
Commit: f7119520544accb8dcf6d27119b9f1963d8ee5a0
Architecture: arm64
OS: macOS 27.0.1 (Build 26A434)

For AI issues: which model did you use?

Not model-specific. The process was started by the extension host, not by an agent tool call.

For AI issues: add Request ID with privacy disabled

None. This was an extension-host rg process, not a chat request.

Additional Information

Related reports of --follow on other walks:

A third thread, “Cursor 2.5+ project rules discovery causes infinite CPU usage in repos with circular symlinks”, describes the same hardcoded --follow on rules discovery.

The Cursor ignore-file docs say .cursorignore blocks Agent, Tab, Inline Edit, and @ mentions. This extension-host file search does not honor it.

This invocation is different. It searches for **/package.json, passes --no-ignore rather than only --no-ignore-parent, and uses a short exclude list: .git, .svn, .hg, .DS_Store, Thumbs.db, node_modules.

A workspace settings.json file had a search.exclude entry for _*, but the file did not parse because of a stray byte after the closing brace. This report does not claim that a valid search.exclude was ignored. The failure shown here is that .cursorignore was not passed to rg, and --follow walked the symlink.

Cursor staff have said on the related threads that search.exclude patterns are appended as -g globs, which rg still honors with --no-ignore. search.followSymlinks set to false does not stop walks that hardcode --follow.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hey @rovrevik,

That rg command line is the extension host’s standard workspace file search, the one extensions use to look for files (here, every package.json). Two things shape what you saw.

  • --no-ignore is built into how that extension file search works (it behaves the same in VS Code): it never reads .gitignore, .ignore or .cursorignore. .cursorignore controls what Agent, Tab, Inline Edit and @ mentions can access (ignore file docs), and “Ignore Symlinks in Cursor Ignore Search” only affects how Cursor looks for .cursorignore files themselves. Neither one applies to extension scans today.
  • --follow isn’t fixed, though. It comes from search.followSymlinks, which defaults to true, and this scan uses your value. Since your workspace settings file currently doesn’t parse, put this in your User settings (Command Palette, then Preferences: Open User Settings (JSON)):
"search.followSymlinks": false,
"files.exclude": { "**/_home": true }

Either line on its own keeps this scan out of _home. files.exclude is the exclude list extension file searches respect (search.exclude doesn’t apply to them), but it also hides _home from the Explorer, so search.followSymlinks alone may suit you better. If you already had search.followSymlinks set to false in your User settings and this scan still ran with --follow, please let us know, since that shouldn’t happen.