Bug: Glob returns "No files found" for any pattern with a literal directory prefix on Windows

Resolved 💬 1 comment Opened May 22, 2026 by wh0amibjm Closed Jun 21, 2026

Bug: Glob returns "No files found" for any pattern with a literal directory prefix on Windows

Environment

  • Claude Code: 2.1.148 (native install, ~\.local\bin\claude.exe)
  • OS: Windows 11 Pro 10.0.26200
  • Shell: PowerShell 7

Summary

On Windows, the Glob tool returns No files found for any pattern that contains a
literal directory segment before a wildcard (e.g. src/**/*.ts, src/*.ts,
src\**\*.ts), even when matching files clearly exist. Only fully-wildcarded patterns
(**/*.ts) match. The same files are found if the directory is moved into the path
parameter instead of the pattern. This makes the natural "scope a search to a
subdirectory" idiom silently return nothing.

Minimal reproduction

Create this tree (no .gitignore, no node_modules involved):

<root>\root.ts
<root>\src\a.ts
<root>\src\sub\b.ts

Then call the Glob tool 4 times:

| # | path | pattern | Result | Expected |
|---|--------|-----------|--------|----------|
| 1 | <root> | **/*.ts | ✅ root.ts, src\a.ts, src\sub\b.ts | ✅ |
| 2 | <root> | src/**/*.ts | ❌ No files found | src\a.ts, src\sub\b.ts |
| 3 | <root> | src/*.ts | ❌ No files found | src\a.ts |
| 4 | <root>\src | **/*.ts | ✅ src\a.ts, src\sub\b.ts | ✅ |

#2 and #3 are the bug: matching files exist but Glob returns nothing.

Likely cause

The pattern's literal segment uses /, but Windows paths are walked/compared with \,
so the anchored src/ prefix never aligns. Using \ in the pattern (src\**\*.ts)
also fails because \ is treated as an escape character. Result: any non-fully-wildcarded
pattern is unmatchable on Windows.

Impact

  • The standard way to narrow a search — Glob(pattern="src/**/*.ext") — silently yields

zero results. It's indistinguishable from a legitimate "no matches", so it leads to
wrong conclusions ("the file doesn't exist") rather than an obvious error.

  • Forces the workaround of always scoping via the path parameter, which isn't discoverable.

Secondary observation (separate, possibly by-design)

Glob does not honor .gitignore, while Grep (ripgrep) does. In a pnpm/Node project,
Glob(pattern="**/*.ts") from the repo root is dominated by node_modules/.pnpm/**/*.d.ts
and hits the truncation limit before reaching real source (measured: find = 3569 .ts,
ripgrep-with-gitignore = 146). Combined with the bug above (the obvious fix
src/**/*.ts returns nothing), Glob is effectively unusable for "list my source files"
on Windows. Consider either honoring .gitignore in Glob or documenting the asymmetry.

Suggested fix

Normalize path separators when matching Glob patterns on Windows so that a /-delimited
pattern with a literal prefix matches \-delimited paths.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗