When a workspace contains a nested Git repository (a subdirectory with its own .git), the Agent’s built-in Grep and Glob tools cannot find any files or content inside that directory.
The Read tool, terminal rg, Ctrl+Shift+F, and codebase indexing all work correctly for the same paths.
Steps to Reproduce
Create a workspace root that is itself a Git repo.
Inside it, have a subdirectory (e.g. implementation/) that is a separate Git repo (has its own .git/).
The subdirectory is not in any .gitignore or .cursorignore.
Open a multi-root .code-workspace that includes both the parent and the nested repo as folder entries.
Confirm Ctrl+Shift+F finds content inside the nested repo.
Confirm Cursor Settings > Indexing & Docs > View included files lists files from the nested repo.
In Agent (Cmd+I or chat), ask it to search for a known string inside the nested repo.
Expected Behavior
Agent Grep/Glob find matches in the nested repo, same as editor search and indexing.
Hey, thanks for the detailed report. This is a known issue. Agent Grep and Glob build their search off the git tree, and nested git repos that aren’t registered as submodules with no entry in .gitmodules end up invisible to these tools. That’s why Read, terminal rg, and Ctrl+Shift+F work since they scan the filesystem directly, but Grep and Glob don’t.
I’ve passed this to the team. For now, a workable workaround is to add a rule in .cursor/rules so the agent uses the terminal for search:
When searching for files in this project, prefer using terminal commands (find, grep, rg)
instead of the built-in glob/grep tools, as this workspace contains nested git repositories
which the glob/grep tools currently don't handle correctly.
Not ideal, but it unblocks you. Let me know if you need anything else.
I have exactly the same problem. My application consists of several modules - each of them is a separate git repository, but the development standards are the same across them. I thus have created a top-level git repo to store our Cursor rules and skills for this application, checked it out locally, and checked out into this folder all the modules as subfolders (note: these are not git submodules, just separate git repos). This works great except the fact that the built-in Glob and Grep tools do not see the files in subfolders. Only the SemanticSearch tool sees them.
I did the workaround, i.e. added rule to use (find, grep, rg) instead of built-in Glob and Grep, but this is cumbersome when used without auto-run, i.e. with the “Ask Every Time” mode. So it would be great if Cursor fixed the build-in tools to work correctly in such a setup.
BTW, is there a better way to share rules and skills across many highly-related git repos?
Hey, thanks for confirming. Your setup matches the same case we’re seeing (nested git repos, not submodules). We’re tracking the bug, but I can’t share an ETA for a fix yet. I agree that using a rule with “Ask Every Time” is awkward. Once there’s an update, I’ll reply in the thread.
On sharing rules or skills across repos, here are a few options:
User Rules (Cursor Settings > Rules > User Rules) apply globally to all projects. This is a good fit for shared dev standards that don’t depend on a specific repo.
Project rules in the meta-repo: what you’re already doing, keeping .cursor/rules/*.mdc in the top-level repo. This works, but it currently runs into the Grep/Glob bug.
Symlink .cursor/rules from a shared location into each repo (if you want each module to work as a standalone workspace).