The Glob tool used by the Agent (and possibly the same backend as “find files by pattern”) returns 0 files when target_directory is set to a project folder on drive D: on Windows, even though the folder exists, contains many files, and Read / Grep on the same paths work. This is not limited to dotfiles (e.g. .cursorignore); patterns like **/* and *.yml also return no matches.
Steps to Reproduce
On Windows, add a workspace folder on D: (e.g. D:\docker\my-project) with visible files such as docker-compose.yml, .cursorignore, etc.
In the Agent, run Glob with target_directory = that folder (e.g. D:\docker\my-project) and glob_pattern = **/* or *.yml.
Observe 0 files found.
Optionally: run Grep with path set to the same folder and a string known to exist (e.g. in docker-compose.yml) — matches are returned.
Optionally: Read the same file by absolute path — succeeds.
Expected Behavior
Glob should list files under the given target_directory according to glob_pattern, consistent with the filesystem and with other tools (Grep, Read) operating on the same absolute path on D:
Multi-root workspace may be relevant: e.g. roots on C: and D:; Glob with target_directory empty may only surface files under one root, while explicit D:\... still returns 0 for Glob.
NTFS ACL on D:\ and the project folder was checked: owner is the same user with Full control; ordinary shell listing works. Unlikely to be permissions.
Suggests Glob’s index or path handling for non–C: drives or explicit absolute target_directory on Windows.
Hey, thanks for the detailed report. This is a known issue with Glob on Windows. In a multi-root workspace, when target_directory is on a different drive than the workspace root, relative paths are calculated wrong and Glob returns 0 results. Read and Grep still work because they use different execution paths.
The issue is being tracked, but I can’t share an ETA for a fix yet.
As a workaround, you can add a rule in .cursor/rules so the agent uses the terminal to search for files:
When searching for files in this project, prefer using terminal commands
(find, grep, rg) instead of the built-in glob/grep tools, since this
workspace spans multiple drives on Windows where built-in Glob currently
returns no results.
Another option is to open the D: project as a single-root workspace without the C: root. Then Glob works correctly within a single drive.
When there’s an update on the fix, I’ll reply in the thread.
I can confirm this is broader than cross-drive paths.
After additional testing, the issue reproduces in multi-root workspaces even when all roots are on the same drive (C:). In my case, Glob returned empty/wrong results for a valid target_directory on C:, while shell listing and direct file reads still worked. When I switched to a single-root workspace, Glob behavior became normal again.
So the key factor appears to be multi-root context itself, not specifically D: vs C:
Thanks for running the extra test, it’s a helpful signal. The fact that the bug reproduces even in a same drive multi-root setup confirms the root cause is in multi-root path handling, not anything cross-drive specific. That matches how Glob resolves target_directory relative to the first workspace root.
Same workarounds for now: either open the project as a single-root workspace, or use .cursor/rules to tell the agent to use the terminal for file search. I’ll post an update in the thread once we have a fix.
Quick update: the fix for Glob returning 0 results in multi-root workspaces, including the cross-drive case, will ship in Cursor 3.6. Please try again after you update. Thanks for the extra test with a same-drive multi-root setup, it was a helpful signal that confirmed the issue is specifically in multi-root path handling.