Sub-repos are ignored in Cursor index

[gregc (Greg)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The agent’s file-search tools (Grep and Glob) silently return no matches for files that live inside a nested/embedded git repository — a subfolder that contains its own .git — even though those files are tracked in their own repo and are not gitignored. The files are reachable: raw ripgrep finds them, and Grep against the exact file path finds them. Only the directory-walking search skips the embedded-repo subtree, and it does so with no error or “results truncated” warning. In a meta-repo setup (a parent repo containing cloned child repos that are themselves git repos), this means the agent silently misses most of the codebase and draws wrong conclusions.

Steps to Reproduce

1. Create a parent git repo containing an embedded child git repo: mkdir -p parent/child cd parent && git init && printf ‘NEEDLE_MARKER\n’ > top.txt cd child && git init && printf ‘NEEDLE_MARKER\n’ > inside.txt

2. Open the parent folder as a workspace in Cursor.

3. In chat, ask the agent to Grep for NEEDLE_MARKER (or Glob for **/inside.txt).

4. Observe: only top.txt is returned. child/inside.txt, inside the embedded repo, is missing.

5. Compare: running “rg NEEDLE_MARKER parent” in a terminal returns both files; and asking the agent to Grep the exact path parent/child/inside.txt also returns the match.

Notes: the child is an independent clone, not a submodule (no .gitmodules). “git check-ignore” reports the files as NOT ignored, and the parent .gitignore does not list them. The child shows in the parent’s “git status” as an untracked embedded repo (?? child/). Adding the child repos as their own workspace folders (multi-root) does not help.

Expected Behavior

Grep and Glob should search tracked, non-ignored files inside nested/embedded git repositories that are part of the workspace, consistent with raw ripgrep — or at minimum when the nested repo is added as an explicit workspace folder. If embedded repos are intentionally excluded, the tools should surface that fact rather than returning an empty or partial result set silently.

Operating System

MacOS

Version Information

Version: 3.7.21
VS Code Extension API: 1.105.1
Commit: 517f696d8ab6c53eb04fbfdaae705cd146bf3460
Date: 2026-06-07T21:46:09.237Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 24.6.0

Does this stop you from using Cursor

Yes - Cursor is unusable

[Colin]

Thanks for the report @gregc

This looks like the same issue that was reported here:

Agent Grep/Glob tools return zero results for nested Git repository directories while Read, Shell rg, and editor Find in Files all work

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug 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 sep…

I’ve linked your report to the existing bug report!

@deanrie also shared a potential workaround here:

Agent Grep/Glob tools return zero results for nested Git repository directories while Read, Shell rg, and editor Find in Files all work

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 …