Where does the bug appear (feature/product)?
Cursor CLI
Describe the Bug
The new AGENTS/skills discovery walker introduced in build 2026.05.16-0338208
spawns rg --files --hidden --no-require-git --no-config --follow --iglob '*/**/.cursor/**' ...
during CLI startup. On any workspace where top-level entries are symlinks into
a large remote tree (NFS, SMB, etc.), --follow causes the walker to descend
into the entire remote tree and never terminate. The agent never reaches its
first prompt; the CLI appears hung.
.cursorignore is not consulted by this code path. The semantic-search
indexer honors .cursorignore, but the AGENTS/skills walker is a separate
code path with hardcoded excludes that don’t cover this case.
Environment
| Cursor CLI build (broken) | 2026.05.16-0338208 |
| Cursor CLI build (also broken) | 2026.05.15-3f71873 |
| Last known good build | 2026.05.09-0afadcc (no AGENTS/skills walker) |
| OS | AlmaLinux 8.4 / RHEL 8 |
| Kernel | 4.18.0-553.22.1.el8_10.x86_64 |
| Workspace shape | enterprise SCM client view, ~75 top-level entries, ~70 of which are symlinks into a single large NFS-backed source tree |
Steps to Reproduce
-
On a Linux host with a workspace where most top-level entries are symlinks into a large remote NFS / SMB / network tree (an “umbrella” / “client view” / “fanout” layout common in large monorepos with selective sync):
workspace/ myproject/ <- real dir, want to work in this dep1 -> /remote/nfs/big-tree/dep1 dep2 -> /remote/nfs/big-tree/dep2 ... (many more symlinks) ... -
Launch
cursor-agent(build 2026.05.16-0338208 or newer). -
Observe a child
rgprocess viaps -ef:rg --files --hidden --no-require-git --no-config --color=never --follow \ --iglob '*/**/.cursor/**' --iglob '*/**/.agents/**' \ --iglob '*/**/AGENTS.md' --iglob '*/**/.claude/**' \ --iglob '*/**/.codex/**' --iglob '*/**/CLAUDE.md' \ --iglob '*/**/CLAUDE.local.md' \ --iglob '!**/node_modules/**' --iglob '!**/.git/**' \ --iglob '!**/.turbo/**' --iglob '!**/.next/**' \ --iglob '!**/.cache/**' --iglob '!**/.pnpm/**' \ --iglob '!**/.yarn/**' --iglob '!**/dist/**' \ --iglob '!**/build/**' --iglob '!**/out/**' \ --iglob '!**/target/**' --iglob '!**/.vscode/**' \ --iglob '!**/.idea/**' --iglob '!**/venv/**' \ --iglob '!**/__pycache__/**' --iglob '!**/logs/**' \ --iglob '!**/tmp/**' --iglob '!**/temp/**' -
The
rgprocess never exits. The agent never prompts. The CLI is unusable on this workspace.
Expected Behavior
Expected behavior
The walker completes quickly (seconds) and the agent reaches its first prompt.
At least one of the following should hold:
- Skip directories that match
.cursorignore(the documented mechanism users
already use to bound indexing), OR - Skip symlinks by default (do not pass
--follow), OR - Apply a depth limit, OR
- Apply a time budget and proceed without skills/AGENTS discovery if exceeded.
Actual behavior
- Walker uses
--followunconditionally .cursorignoreis not consulted (this is a different code path from the
semantic-search indexer)- Hardcoded excludes cover only the JS/web ecosystem
(node_modules,.git,dist,build,.next,.cache, …) — they do
not mention NFS mountpoints or generic large-tree patterns - No timeout, no depth limit
- The
--iglob '*/**/.cursor/**'etc. are include filters on the output;
they do NOT bound the walk.rg --filesstill descends every directory and
then filters which paths to print.
Result on the affected workspace: the walk is effectively unbounded.
Operating System
Linux
Version Information
| Cursor CLI build (broken) | 2026.05.16-0338208 |
| Cursor CLI build (also broken) | 2026.05.15-3f71873 |
| Last known good build | 2026.05.09-0afadcc (no AGENTS/skills walker) |
| OS | AlmaLinux 8.4 / RHEL 8 |
| Kernel | 4.18.0-553.22.1.el8_10.x86_64 |
| Workspace shape | enterprise SCM client view, ~75 top-level entries, ~70 of which are symlinks into a single large NFS-backed source tree |
Additional Information
Root cause analysis
ripgrep does honor .ignore and .rgignore files even with --no-config
(the upstream GUIDE.md confirms --no-config only disables ~/.ripgreprc).
Precedence is .gitignore < .ignore < .rgignore. So users can in
principle work around this by adding .ignore / .rgignore at the workspace
root — but they have no way to know that, because:
- The Cursor docs only mention
.cursorignore - The
.cursorignorethey already have does NOT cover this code path - There is no error message, log line, or warning from the CLI to indicate
what’s happening — it just hangs
There is also a critical gitignore-semantics gotcha that’s easy to get wrong:
per git-scm.com/docs/gitignore EXAMPLES, apf/ (trailing slash) matches a
directory but not a symbolic link named apf. So users who write
.ignore entries with trailing slashes will find their workaround doesn’t
work — patterns must be slashless to match symlinks.
Workaround (for users hitting this now)
Create both .ignore and .rgignore at the workspace root with identical
content (two files because .rgignore has highest precedence and .ignore is
the application-agnostic backstop):
# Block every top-level symlink. NO trailing slashes -- gitignore "foo/"
# does not match a symbolic link named foo.
dep1
dep2
... (every top-level symlink, one per line) ...
# Re-allow what you want indexed (no trailing slash either, for symmetry)
!myproject
!.cursor
After adding these, the same rg --files --follow invocation completes in
<3 seconds instead of hanging.
If you use .cursorignore with a tight /* !... allow-list policy, you also
need to add !.ignore and !.rgignore to that allow-list, otherwise the
Cursor file tools won’t be able to read/edit them.
Suggested fixes (in priority order)
- Drop
--followfrom the AGENTS/skills walker. Following symlinks
across filesystem boundaries provides no benefit for skills/AGENTS
discovery and creates this hazard. ripgrep’s own default forrg --files
is to not follow symlinks; that default is correct for this use case. - Honor
.cursorignorein the AGENTS/skills walker. There is no
user-visible reason this code path should differ from the semantic-search
indexer. - Add
--max-depth(e.g. 10). Even a generous limit would tame
pathological symlink chains. - Add a time budget. If the walker hasn’t returned in 30 seconds, log a
warning and proceed without skills/AGENTS discovery rather than blocking
startup. - Add a startup log line that says what the indexer is doing, so users
hitting this can see “indexing workspace…” and infer the cause without
having tostracethe process. - Document that
.ignore/.rgignoreare honored, until #1-#5 land.
Evidence: timings before and after the workaround
Same workspace, same model, same one-line headless prompt
(cursor-agent -p --model sonnet-4 "Reply DONE."):
| Setup | rg --files --follow runtime |
Agent total runtime |
|---|---|---|
| Build 2026.05.16, no workaround | hangs indefinitely (killed after ~14 min) | never returns |
Build 2026.05.16, with .ignore + .rgignore workaround |
< 3 seconds | 86 s |
Build 2026.05.16 + npm removed from PATH |
n/a (LSP also doesn’t spawn) | 83 s |
| Build 2026.05.09 (no AGENTS/skills walker) | n/a | 83 s |
Once the walker is bounded, the new build’s startup is within ~3 seconds of
the old build — so the fix is genuinely a fix, not a workaround that masks
some other regression.
Process tree at hang time
Observed via ps --ppid <agent-pid> -o pid,etime,stat,comm:
PID ETIME STAT COMM
<rg> <ever> SNl rg <- this is the hang
<git> 0:00 DN git <- short-lived, p4/git status probe
<node> 0:00 S worker-server
The rg child stays in state SNl (sleeping, low priority, multi-threaded)
indefinitely while doing NFS I/O.
Related
Forum search for “cursor agent rg follow symlinks hang” turns up multiple
prior reports going back to Feb 2026 with similar root cause but on
different workspace shapes (monorepos with vendored deps, etc.). This bug
report adds the NFS symlink case and the .ignore / .rgignore workaround
that I haven’t seen documented elsewhere.
Does this stop you from using Cursor
Yes, unless we use the WA .rgignore file.