Cursor’s (?)indexing and Agent Glob tool ignore VS Code search settings (search.useIgnoreFiles, search.useGlobalIgnoreFiles, search.useParentIgnoreFiles) and always apply .gitignore and core.excludesFile. This breaks separation of concerns and diverges from VS Code, which provides opt-in control over these behaviors.
Steps to Reproduce
Two distinct domains are mixed:
Version control — what Git tracks (.gitignore, core.excludesFile).
Search and indexing — what tools can discover and index.
These serve different purposes. A user may want:
.cursor/ ignored by Git (not committed), but included in search and indexing.
.env ignored by Git, but included in search for debugging.
Forcing indexing to follow gitignore rules, without a way to override them, violates this separation and makes otherwise valid workflows impossible.
Cursor derives from VS Code and reuses parts of it, but indexing and Agent Glob do not honor these settings. That contradicts expected behavior and industry practice: forked/extended products should respect upstream configuration when they reuse the same concepts.
Reproduction
Add /.cursor/ to project .gitignore (or ~/.gitignore_global).
Ensure .cursorignore is empty or does not override it.
Use Agent Glob with pattern **/profile.mdc or **/*.md.
Result: 0 files found in .cursor/, even though search.useIgnoreFiles is false in settings.
Expected Behavior
When search.useIgnoreFiles is false, indexing and Glob should not exclude files based on .gitignore or core.excludesFile.
When search.useGlobalIgnoreFiles is false, indexing and Glob should not use core.excludesFile.
.cursorignore negation patterns (e.g. !/.cursor/**) should be able to override gitignore for indexing, which they currently do not.
Operating System
Linux
Version Information
2.4.31
1.105.1
Additional Information
Impact
.cursor/ (rules, profiles, skills) cannot be found by Glob or semantic search when gitignore excludes it.
Users must either relax gitignore or rely on terminal tools, which bypass these rules.
Workarounds are unreliable and inconsistent across projects.
Suggested fix
Teach indexing and Glob to respect search.useIgnoreFiles, search.useGlobalIgnoreFiles, and search.useParentIgnoreFiles in the same way as VS Code search.
Alternatively, add Cursor-specific settings that explicitly control indexing vs gitignore, without breaking existing behavior.
About VS Code search settings: Cursor indexing and the Agent Glob tool intentionally use their own ignore logic, separate from VS Code settings like search.useIgnoreFiles and search.useGlobalIgnoreFiles. Per the docs, Cursor automatically respects .gitignore and provides .cursorignore as an override mechanism. So this is intentional behavior, not a bug, although I get the argument for parity.
About negations in .cursorignore not working: The docs say you can override gitignore exclusions using the ! prefix in .cursorignore. But there’s a known limitation, you can’t re-include a file if its parent directory is excluded. So if .cursor/ is in your .gitignore, the pattern matters:
# This may NOT work due to the parent directory exclusion:
!.cursor/**
# Try this instead, explicitly:
!.cursor/
!.cursor/rules/
!.cursor/rules/*.mdc
Can you share exactly what you have in your .cursorignore?
The team is aware of related issues where hidden or ignored files aren’t available to agent tools. Your report helps with prioritization, especially the .cursor/ directory case since it’s directly tied to rules and profiles.
Let me know if the suggested workaround pattern helps or not.
About search.useIgnoreFiles / search.useGlobalIgnoreFiles:
I understand that Cursor uses its own ignore logic. The issue is that many users expect Cursor (as a VS Code fork) to honour the same search-related settings. Right now, users who set search.useIgnoreFiles: false to include gitignored files in search still see /.cursor/ excluded from Glob.
About .cursorignore negation:
My exclusion comes from ~/.gitignore_global (via core.excludesFile), not from the project .gitignore. My .cursorignore was:
!/.cursor/
!/.cursor/**
I also tried the explicit patterns you suggested:
!/.cursor/
!.cursor/rules/
!.cursor/rules/*.mdc
(and similarly for profiles and skills). In both cases, Glob still returned 0 results for patterns like **/profile-technical.md and **/profile.mdc while the exclusion was in ~/.gitignore_global(.gitignore in homedir).
What did work:
The only workaround that worked was commenting out /.cursor/ in ~/.gitignore_global (via core.excludesFile):
# /.cursor/
After that, Glob correctly found the files in /.cursor/.
So in practice, .cursorignore negation does not seem to override core.excludesFile. If that’s by design, it would be useful to have it documented; if it’s unintended, it would be good to fix.
Thanks for testing these patterns and sharing the results.
Confirmed: negation in .cursorignore doesn’t override exclusions from core.excludesFile. That’s a gap. The docs say ! should override exclusions from .gitignore, but they don’t account for the global gitignore. I’ve passed this on to the team.
As for parity with search.useIgnoreFiles, that’s being tracked separately as a feature request. The current behavior is working as intended.