Bug: Agent becomes unusable over Remote SSH due to ripgrep `.jj` filesystem walk despite `--no-ignore` (NFS / huge trees)

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hi Cursor Support/Engineering,

I’m seeing a repeatable issue where Cursor’s Agent becomes effectively unusable over Remote SSH when the remote machine has very large / slow storage (e.g., an NFS mount with millions of directories/files).

Summary
After connecting via SSH, the remote cursor-server spawns ripgrep (@vscode/ripgrep), which performs an extremely expensive directory walk. Even though Cursor passes --no-ignore, ripgrep still traverses directories and repeatedly stat()s for Jujutsu’s .jj marker in each directory. On slow storage / huge trees, this scan runs for a very long time and appears to prevent the Agent from functioning.

Environment
Cursor: 2.2.44
Remote: Linux host over Remote SSH
Storage: NFS mount and/or very large directory trees (millions of entries)
Cursor remote server path: ~/.cursor-server/…

What Cursor starts on connect
On the remote host, immediately after connecting, I see Cursor launching a ripgrep process similar to:
~/.cursor-server/…/node_modules/@vscode/ripgrep/bin/rg --files --hidden --no-ignore --no-config …
This ripgrep process then spawns many threads and does not complete in reasonable time.
Evidence (strace)
strace on the ripgrep process shows it repeatedly probing .jj in directories as it walks the tree, e.g.:
newfstatat(AT_FDCWD, “./projects/storage/…/.jj”, …) = -1 ENOENT
newfstatat(AT_FDCWD, “./projects/storage/…/raw/.jj”, …) = -1 ENOENT
…repeated across large directory trees.
This occurs even though the command line includes --no-ignore.
Why this matters
This directory walk causes Cursor to bog down severely on hosts with slow/large storage, and the Agent becomes unusable after connecting.

Upstream cause
This appears to match an upstream ripgrep issue that was recently patched (but not yet released in a stable ripgrep version):
PR: ignore: only stat .jj if we actually care by ianloic · Pull Request #3212 · BurntSushi/ripgrep · GitHub
The fix is also mentioned in the ripgrep changelog, but the release including it is still TBD.

Request
Could you please:

  • Confirm Cursor is affected by the ripgrep behavior described in PR #3212, and
  • Update the bundled ripgrep (@vscode/ripgrep) to a build that includes this fix (or otherwise prevent .jj probing / costly traversal on connect), and/or
  • Provide a Cursor-side mitigation (config or setting) to avoid this scan on very large/slow trees.

Steps to Reproduce

  • Set up a Linux host with a very large and/or slow filesystem under your home or workspace (e.g., an NFS mount) containing millions of directories/files. Example path: ~/projects/storage/…
  • From a client machine, open Cursor and connect to that host using Remote SSH.
  • Open a folder/workspace that includes (or is adjacent to) the large tree (e.g., ~/projects/project2 where storage/ exists beside it).
  • Immediately after the connection completes, observe remote processes (e.g., ps -ef --forest or top):
    cursor-server starts
    it launches ~/.cursor-server/…/node_modules/@vscode/ripgrep/bin/rg --files --hidden --no-ignore --no-config …
  • Optionally, attach strace to the rg PID and observe repeated stat/newfstatat calls for .jj in each directory.
  • While this is running, try to use Agent (or other features that rely on it). The Agent fails to respond / is unusable.

Expected Behavior

  • After connecting via Remote SSH, Cursor should not trigger an unbounded filesystem walk across large/slow directories (especially ones the user has excluded or ignored).
  • If Cursor passes --no-ignore, ripgrep should not perform extra VCS marker probing (e.g., .jj) that results in a full traversal of massive directory trees.
  • Agent should remain responsive and functional immediately after connecting, even when the remote host contains large NFS-backed directories unrelated to the active work.

Operating System

Linux

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.2.44
VSCode Version: 1.105.1
Commit: 20adc1003928b0f1b99305dbaf845656ff81f5d0
Date: 2025-12-24T21:41:47.598Z (1 wk ago)
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 25.2.0

Does this stop you from using Cursor

Yes - Cursor is unusable

3

For anyone else struggling, the shell script got me unstuck. Obviously change the glob to match your environment

run the script then:

  • pkill -f ‘\.cursor-server/.*node’ || true
  • pkill -f ‘/ripgrep/.*/rg’ || true

cursor will ask if you want to reconnect.

#!/bin/bash

DIR=`find ~/.cursor-server/ -name “rg” | xargs dirname`

mv $DIR/rg $DIR/rg.orig

cat > “$DIR/rg” <<‘EOF’

#!/bin/bash

./rg.orig --glob ‘!**/where/your/big/folder/is/**’ “$@”

EOF

chmod +x “$DIR/rg”
5

Hey, thanks for the report.

I’m passing it to the team. This is related to how the bundled ripgrep handles VCS markers, and the fix isn’t in the stable ripgrep release yet.

Thanks for the wrapper script workaround, it should help other users with a similar setup.

7

We are working on a fix for this – thanks for raising this issue.