Rg/grep issue in sandbox

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Running rg (ripgrep recursive directory search) through the Shell tool never completes. The tool reports the command was “sent to background” after the 30-second timeout, but the terminal output file shows zero output and the command appears to hang indefinitely. The rg process itself exits correctly in under 1 second — this is a process-exit detection bug in the Shell tool infrastructure, not an AI model issue.

Steps to Reproduce

Open any git repo with source files
In Agent mode, have the agent run a bare ripgrep command: rg -i somepattern
Observe: the Shell tool times out after 30s and backgrounds the command
Check the terminal output file — it shows zero output and no exit code, even though rg finished instantly

Expected Behavior

Command completes in under 1 second (as it does in a real terminal or when wrapped in sh -c).

Operating System

Linux

Version Information

Version: 3.3 (latest)
VSCode Version: 1.105.1
Commit: 224838f96445be37e3db643a163a817c15b36060
Date: 2026-03-12T04:07:27.435Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

composer 2, opus 4.7

Additional Information

i have found that the issue is sometimes fixed when adding this cursor rule:

description: Always run grep/rg/find shell commands with elevated permissions to bypass sandbox throttling
alwaysApply: true

Shell grep / rg / find permissions

Sandboxed grep, rg, find, unzip, strings, and similar
filesystem-traversal commands often get killed at ~100–200 ms before they
produce useful output (especially when scanning Foglight install dirs,
class files, jar contents, or other binary blobs).

Rule: When invoking the Shell tool with grep, rg, find,
strings, unzip, or any command that traverses many files / scans binary
content, ALWAYS pass required_permissions: ["all"] so the command runs
outside the sandbox. This applies to:

  • grep -r / grep -R / grep --binary-files=text
  • rg (any invocation)
  • find over ~/Quest/Foglight/, node_modules/, cartridge/, state/,
    or other large trees
  • strings <file> on binary class/jar files
  • unzip -p ... | grep ... patterns
  • for jar in $(find ...); do unzip -p ... | grep ...; done loops

This is a workspace-local convenience rule — the workspace is a private
dev environment so running these read-only inspection commands unsandboxed
is safe.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

**actually it is specifying file path that fixed it. here is the cursor rule that solved the issue:
**

description: Sandbox + ripgrep path rules so Shell traversal does not stall

alwaysApply: true

-–

**Sandbox:** When invoking the `Shell` tool with `grep`, `rg`, `find`,

`strings`, `unzip`, or anything that traverses many files / scans binary

content, ALWAYS pass `required_permissions: [“all”]` so the command runs

outside the sandbox.

**Ripgrep PATH:** Cursor’s Shell is not an interactive TTY. For `rg`, if you

omit file/directory arguments after the pattern (`rg PAT` with nothing else),

ripgrep can treat stdin as input and block until stdin closes—indefinitely

with an empty pipe. When you intend to search a tree from the **current working

directory**, always pass an explicit root, e.g. `rg PAT .`, `rg PAT ./src`, or

`rg PAT “$DIR”`.

9

This is a known bug with the Shell tool’s process-exit detection. When rg runs without an explicit path argument (e.g., rg -i pattern instead of rg -i pattern .), the Shell tool never detects that the process has exited.

You’ve already found the right workaround in your updated rule: always pass an explicit directory to rg, like rg PAT . or rg PAT ./src. That’s the confirmed fix on the user side until we ship a permanent resolution.

One note: the required_permissions: ["all"] part of your original rule isn’t a real Shell tool parameter, so it wouldn’t have an effect. The explicit path is what actually resolves the hang.

Our team is aware of this and working on a fix. In the meantime, you can also use Cursor’s built-in Grep tool (which handles rg differently and doesn’t hit this issue) instead of running rg through the Shell tool directly.

12

Hey @HEMgreen,

Quick update, the underlying bug here (bare rg with no path argument hanging the Shell tool) has been fixed on our end and is now live for everyone.

Let me know if you still hit it.