ENOENT for rg when using built-in grep tool

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Environment

  • Cursor 2.5.17 (Stable), commit ce54912c
  • macOS Darwin 25.2.0, ARM64 (Apple Silicon)

Error

Error running tool: spawn /Applications/Cursor.app/Contents/Resources/app/node_modules/@vscode/ripgrep/bin/rg ENOENT

Details

The built-in Grep tool (used by AI agents for codebase search) fails with ENOENT when spawning the bundled ripgrep binary. The binary exists at the expected path, is the correct architecture (Mach-O arm64), is properly code-signed (TeamIdentifier=VDXQ22DGB9, hardened runtime), and has correct permissions (rwxr-xr-x). Executing the same binary from a terminal works fine.

What I verified

  • Binary exists at the reported path and is executable
  • Correct architecture (arm64 on arm64 Mac)
  • Properly signed by Cursor’s team with hardened runtime
  • No macOS App Translocation — Cursor runs from /Applications/Cursor.app
  • No ASAR redirection (node_modules.asar is empty {"files":{}})
  • System-installed rg via Homebrew works fine from Shell
  • Bundled rg binary works fine when invoked from Shell

What I tried (unsuccessfully)

  1. Restarting Cursor
  2. Full reinstall (trash app, fresh download)
  3. Removing com.apple.quarantine from the binary
  4. Removing all xattrs from the entire .app bundle (xattr -cr)
  5. Replacing the binary with a copy of the Homebrew-installed rg
  6. Symlinking to the Homebrew/global rg

Notes

  • This appears to be the same issue reported in forum thread #149962 and GitHub issue #1770.
  • The ENOENT originates from Node.js child_process.spawn, not from a missing file — suggesting the issue is in how the extension host invokes the binary rather than the binary itself.

This is very frustrating because the agent gets stuck trying to find code, and then often tries far-from-ideal approaches instead. I have “caught” it multiple times writing python scripts to crawl and search the codebase. This wastes time and effort and slows down my work.

Steps to Reproduce

Not sure how to reproduce, it seems not everyone has this problem, but there are plenty of reports of it here. None of which seemed to come to a satisfying conclusion

Expected Behavior

the built-in tool should work, the rg executable should be callable by cursor

Operating System

MacOS

Version Information

Version: 2.5.17
VSCode Version: 1.105.1
Commit: 7b98dcb824ea96c9c62362a5e80dbf0d1aae4770
Date: 2026-02-17T05:58:33.110Z
Build Type: Stable
Release Track: Default
Electron: 39.3.0
Chromium: 142.0.7444.265
Node.js: 22.21.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.2.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

3

Hey, thanks for the detailed report and for troubleshooting this so carefully. It saves a lot of back and forth.

This is a known issue that affects some users. The binary is there and works fine from your shell, but Node.js child_process.spawn inside the Cursor extension host can’t find it. The ENOENT is coming from the spawn call, not from the file system.

A couple workarounds to try:

  1. Use a system ripgrep in PATH: Make sure rg is available in the PATH that the Cursor extension host sees. On macOS, the PATH in your shell and the PATH seen by an app can differ. Try launching Cursor from Terminal:

    open -a Cursor

    Or run it directly:

    /Applications/Cursor.app/Contents/MacOS/Cursor

    That way it inherits your shell PATH where the Homebrew rg is installed.

  2. Grab logs from the DevTools console: If the above doesn’t help, can you capture the console output at the time of the error? Press CMD+Shift+I, go to the Console tab, reproduce the error, then copy the relevant lines. The stack trace might hint at why spawn fails specifically in the extension host context.

Since you mentioned the agent falls back to generating Python scripts for searching, that’s expected, even if it’s annoying, when grep isn’t available. The workaround above should bring grep back to normal if Cursor picks up the system rg.

Let me know how it goes.

4

Apologies for the delay here.

I tried open -a Cursor and it worked. Then tried without, and that also worked. Not sure if the first step fixed something, or if a newer version of cursor has fixed in the interim.

Thanks!