# Windows Agent recursive file search inconsistently honors ".cursorignore" **URL:** \ **Category:** Bug Reports\ **Tags:** performance, indexing\ **Created:** [September 8, 2026, 4:48pm UTC](https://forum.cursor.com/t/windows-agent-recursive-file-search-inconsistently-honors-cursorignore/171062 "2026-09-08T16:48:02Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Arnav\_Vatsal](https://avatars.discourse-cdn.com/v4/letter/a/97f17d/32.png) [@Arnav\_Vatsal](https://forum.cursor.com/u/Arnav_Vatsal)\ **Post date:** [September 8, 2026, 4:48pm UTC](https://forum.cursor.com/t/windows-agent-recursive-file-search-inconsistently-honors-cursorignore/171062/1 "2026-09-08T16:48:02Z")
### Where does the bug appear (feature/product)? Cursor IDE ### Describe the Bug Cursor Agent intermittently remains on a recursive file search for 3–5+ minutes: ```plaintext component/backend/**/* ``` The target subtree contains approximately 5,480 files. About 5,334 files are inside an ignored Python `.venv` directory, leaving approximately 61 relevant source and configuration files. A direct local filesystem traversal of the complete subtree takes approximately 553 ms. Narrow Cursor searches against individual source directories complete promptly. Only the broad recursive Agent search becomes stuck or unusually slow. The behavior is inconsistent. Some searches remain active for more than five minutes. After adding nested ignore files and reloading Cursor, one equivalent search completed in under one minute. This suggests that recursive Agent file search may enumerate ignored directories before pruning them, or that ignore-file discovery/caching is inconsistent in a non-Git workspace. ### Steps to Reproduce The following uses synthetic names and does not require access to the enterprise repository: 1. On Windows, open a non-Git workspace containing multiple application components. 2. Create or use a target subtree with this representative shape: 3. Add these entries to the workspace-root `.cursorignore`: 4. Reload Cursor using: 5. Start a fresh Agent chat and ask it to explore the target backend thoroughly, causing a broad search equivalent to: 6. Observe that the Agent may remain on the recursive search for 3–5+ minutes. 7. Compare with scoped searches: 8. As a diagnostic workaround, add a nested `component/backend/.cursorignore` and a ripgrep-compatible `component/backend/.ignore` containing: 9. Reload Cursor and repeat. The broad search may improve substantially, but the behavior is not consistently predictable. ### Expected Behavior Cursor should discover and apply workspace-root `.cursorignore` rules before descending into directories. The ignored `.venv` and cache directories should be pruned before recursive enumeration. The search should process only approximately 61 relevant files and complete consistently within seconds. Performance should not depend on adding undocumented nested `.cursorignore` or `.ignore` files, and ignore handling should remain reliable when the workspace root is not a Git repository. ### Operating System Windows 10/11 ### Version Information Version: 3.19.13 (user setup) VS Code Extension API: 1.128.0 Commit: dd066f332fcea7382764400fde902f61920648d0 Date: 2026-09-04T17:41:16.065Z Layout: IDE Build Type: Stable Release Track: Default Electron: 42.10.0 Chromium: 148.0.7778.280 Node.js: 24.18.1 V8: 14.8.178.38-electron.0 xterm.js: 6.1.0-beta.291 OS: Windows\_NT x64 10.0.26200 ### For AI issues: which model did you use? Auto (Cursor automatic model selection). ### Additional Information Key measurements: - Target subtree: approximately 5,480 files - Ignored Python virtual environment: approximately 5,334 files - Relevant source/configuration files: approximately 61 - Direct local filesystem traversal: approximately 553 ms - Broad Cursor Agent search: intermittently 3–5+ minutes - Scoped searches against individual source directories: complete promptly - One broad search completed in under one minute after nested ignore files were added and Cursor was reloaded The workspace root is not a Git repository. Root .cursorignore contains both explicit and recursive virtual-environment exclusions. Adding nested .cursorignore and .ignore files improved one run, but this is an undocumented workaround and performance remains inconsistent. This appears to be a recursive Agent file-search/Instant Grep traversal issue, possibly caused by ignored directories being enumerated before pruning or inconsistent ignore-file discovery/caching. ### Does this stop you from using Cursor Yes - Cursor is unusable ---
**Author:** ![Arnav\_Vatsal](https://avatars.discourse-cdn.com/v4/letter/a/97f17d/32.png) [@Arnav\_Vatsal](https://forum.cursor.com/u/Arnav_Vatsal)\ **Post date:** [September 9, 2026, 8:58am UTC](https://forum.cursor.com/t/windows-agent-recursive-file-search-inconsistently-honors-cursorignore/171062/5 "2026-09-09T08:58:56Z")
When the workspace root is **not a Git repository** , Agent file search can walk large directories such as `.venv` **before** `.cursorignore` is applied. Ripgrep (which powers Instant Grep) reads `.ignore` / `.gitignore` **while walking** , so those skip the folder before it is scanned. That matches what we measured. One extra detail that may matter: the workspace root is not a Git repo, but several **immediate subdirectories are each their own Git repo**. `.gitignore` handling was inconsistent in that layout; a **workspace-root `.ignore`** was reliable. ### What we changed - Kept a single workspace-root `.ignore` with directory patterns and **trailing slashes** , e.g. `.venv/`, `node_modules/`, ` __pycache__ /`, `.pytest_cache/`, `.ruff_cache/`. - Stopped scattering nested `.cursorignore` / `.ignore` files as the primary fix. - Did **not** run `git init` at the workspace root (nested repos already exist under the root). ### Retest after a full Cursor restart **Terminal ripgrep** (honors root `.ignore`): | Search | Result | Time | | --- | --- | --- | | `rg --files` on `component/backend` | ~80 files | ~180 ms | | `rg --files` on the whole workspace | ~1,163 files | ~370 ms | | Paths containing `.venv` or `node_modules` | 0 | — | | Content search (`timezone` / similar) in `*.py` | matches instantly | ~300 ms | **Agent Grep (Instant Grep analog):** same hit counts as terminal `rg`, all felt instant. Content search is in good shape. **Agent Glob** (`component/backend/**/*`), the pattern that previously hung 3–5+ minutes: - Completed **quickly** this run (no multi-minute hang). - Returned **~2,961 files** , not ~80. The backend still contains a `.venv` on disk. Ripgrep / Grep skip it. Recursive **Glob still enumerates a large part of it**. ### Current split | Tool | Honors workspace-root `.ignore`? | After restart | | --- | --- | --- | | Instant Grep / Agent Grep | Yes | Fast, aligned with `rg` | | Agent Glob `**/*` | Incomplete | No longer hangs for minutes, but still walks ignored `.venv` (~3k files vs ~80) | | Workspace-root `.cursorignore` alone (non-Git root) | Insufficient | Original hang | ### Ask from Cursor team 1. Treat **Glob** separately from Instant Grep: prune ignored directories before recursive glob, the same way `.ignore` already works for Grep. 2. Ideally `.cursorignore` should do this in a **non-Git** workspace without requiring `.ignore`. ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [September 9, 2026, 1:53pm UTC](https://forum.cursor.com/t/windows-agent-recursive-file-search-inconsistently-honors-cursorignore/171062/9 "2026-09-09T13:53:55Z")
Hey @Arnav_Vatsal Thanks for flagging this. I saw you also got in touch with our support team who passed this info along to the team! ---
**Author:** ![system](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/system/32/99069_2.png) [@system](https://forum.cursor.com/u/system)\ **Post date:** [October 16, 2026, 7:34am UTC](https://forum.cursor.com/t/windows-agent-recursive-file-search-inconsistently-honors-cursorignore/171062/12 "2026-10-16T07:34:08Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.