# Cursor-agent CLI 2026.05.16-0338208: internal rg --files --hidden --follow AGENTS/skills walker hangs indefinitely on workspaces with symlink

**URL:** <https://forum.cursor.com/t/cursor-agent-cli-2026-05-16-0338208-internal-rg-files-hidden-follow-agents-skills-walker-hangs-indefinitely-on-workspaces-with-symlink/160850>\
**Category:** Bug Reports\
**Tags:** cli, performance, indexing, linux, skills\
**Created:** [May 17, 2026, 3:58am UTC](https://forum.cursor.com/t/cursor-agent-cli-2026-05-16-0338208-internal-rg-files-hidden-follow-agents-skills-walker-hangs-indefinitely-on-workspaces-with-symlink/160850 "2026-05-17T03:58:41Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Praveen\_Ghanta](https://avatars.discourse-cdn.com/v4/letter/p/4bbf92/32.png) [@Praveen\_Ghanta](https://forum.cursor.com/u/Praveen_Ghanta)\
**Post date:** [May 17, 2026, 3:58am UTC](https://forum.cursor.com/t/cursor-agent-cli-2026-05-16-0338208-internal-rg-files-hidden-follow-agents-skills-walker-hangs-indefinitely-on-workspaces-with-symlink/160850/1 "2026-05-17T03:58:41Z")

</div>

### 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

1. 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):

2. Launch `cursor-agent` (build 2026.05.16-0338208 or newer).

3. Observe a child `rg` process via `ps -ef`:

4. The `rg` process 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 `--follow` unconditionally
- `.cursorignore` is 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 --files` still 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:

1. The Cursor docs only mention `.cursorignore`
2. The `.cursorignore` they already have does NOT cover this code path
3. 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):

```auto
# 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)

1. **Drop `--follow`** from the AGENTS/skills walker. Following symlinks  
across filesystem boundaries provides no benefit for skills/AGENTS  
discovery and creates this hazard. ripgrep’s own default for `rg --files`  
is to not follow symlinks; that default is correct for this use case.
2. **Honor `.cursorignore`** in the AGENTS/skills walker. There is no  
user-visible reason this code path should differ from the semantic-search  
indexer.
3. **Add `--max-depth`** (e.g. 10). Even a generous limit would tame  
pathological symlink chains.
4. **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.
5. **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 to `strace` the process.
6. **Document** that `.ignore` / `.rgignore` are 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`:

```auto
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.

---

<div class="post-metadata">

**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\
**Post date:** [May 18, 2026, 7:58am UTC](https://forum.cursor.com/t/cursor-agent-cli-2026-05-16-0338208-internal-rg-files-hidden-follow-agents-skills-walker-hangs-indefinitely-on-workspaces-with-symlink/160850/7 "2026-05-18T07:58:27Z")

</div>

This is a known bug.

Your report and root cause analysis are exceptional. The NFS symlink variant and the `.ignore`/`.rgignore` workaround (with the critical trailing-slash caveat for symlink matching) are valuable additions that we’ll make sure get captured in the tracking issue.

A few related threads from other enterprise users hitting the same root cause:

- [Cursor 2.5+ unusable, persistent rg processes with high CPU usage](https://forum.cursor.com/t/cursor-2-5-unusable-persistent-rg-processes-with-high-cpu-usage/153681)

Our team is aware and tracking this. Your suggested fix #1 (drop `--follow` from the walker) is the right call.