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.