Agent's Grep/Glob tools silently return zero results inside any Cursor-managed Worktree

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The Agent’s Grep and Glob tools silently return zero results inside any Cursor-managed worktree (Agents Window worktrees). The same Agent, same repo, same query works fine when opened as a regular checkout of main. The failure is silent: there is no error, just “No matches found” / “0 files found”, so agents proceed as if the code doesn’t exist and propose duplicate or wrong implementations.

Why this is high-impact

  • The failure mode is silent: zero matches looks identical to “the thing genuinely isn’t there”, so the agent commits to the wrong conclusion and proceeds without retrying. There’s no signal for the agent (or the user) that something is wrong.
  • It affects every Cursor user who uses Worktrees, i.e. exactly the workflows Cursor is actively pushing.
  • Sub-agents inherit the broken state, so Task(...) doesn’t escape it.
  • For exploration-heavy or refactor sessions, it leads to confidently wrong answers (missed call sites, duplicate code) and partial-coverage refactors with no warning to the user.

Likely related reports

Steps to Reproduce

  1. Pick any non-trivial repo. Open it as a regular checkout (not a worktree) in Cursor and start an Agent chat.
  2. Ask the Agent to Grep for any string that exists multiple times in the repo (e.g. an exported constant, a function name). It returns the matches correctly. Same for Glob.
  3. Now create a Cursor worktree of the same repo via the Agents Window.
  4. In an Agent chat opened against the worktree, ask the Agent to Grep for the same string, or Glob for a known filename pattern. → “No matches found” / “0 files found”, every time.
  5. Confirm the files exist via Read (works) and shell grep -rn <string> . (works). So the files are physically present and readable; only Grep/Glob are blind.
  6. Spawn a sub-agent (e.g. Task(subagent_type="explore")) inside the same worktree and have it run the same Grep/Glob calls. → Same zero-result behavior. The bug is workspace-scoped, not session-scoped.

Expected Behavior

Grep and Glob should return the same matches inside a worktree as they do in a regular checkout of the same repo, since the file contents are identical and the working directory is correctly set to the worktree path.

Actual behaviour:
Grep returns No matches found and Glob returns 0 files found, silently and consistently, for any pattern in any worktree. Re-running and waiting for indexing to “warm up” does not fix it; I confirmed it stays broken 15+ minutes after the worktree is created. Read, shell grep/find, and the editor’s “Find in Files” all work normally on the same files in the same worktree, which is what makes me confident this is a tool-side issue rather than a filesystem or ignore-rule issue.

Operating System

MacOS

Version Information

Version: 3.3.30
VSCode Version: 1.105.1
Commit: 3dc559280adc5f931ade8e25c7b85393842acf30
Date: 2026-05-09T18:28:42.332Z
Layout: glass
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
OS: Darwin arm64 24.6.0

For AI issues: which model did you use?

Opus 4.7 Extra High

For AI issues: add Request ID with privacy disabled

Request ID: 8f85e9a3-49f0-4e51-a269-76fff5338d18

Does this stop you from using Cursor

No - Cursor works, but with this issue