Describe the bug
The built-in glob tool returns "No files matched the pattern." for any
pattern containing a path separator, unless the pattern is prefixed with
**/. Literal relative paths (2026/07/26.md) and wildcarded multi-segment
patterns (2026/07/*.md) both fail even though the files exist directly under
the given paths root. Single-segment patterns (inbox.md, *.md) and
**/-prefixed patterns work.
This is worse than an inconvenience: the agent trusts the empty result. In one
session the agent checked for a file with its exact relative path, got no
match, and confidently declared the file missing — then acted on that false
premise.
Affected version
1.0.70-0 (running as the VS Code Agent Sessions CLI backend; macOS arm64)
Steps to reproduce the behavior
Against a repo containing 2026/07/26.md and inbox.md at the root:
glob with pattern: "2026/07/26.md", paths: ["<repo>"] →
No files matched the pattern. (file exists)
glob with pattern: "2026/07/*.md", same paths →
No files matched the pattern. (31 files exist there)
glob with pattern: "**/07/26.md", same paths →
<repo>/2026/07/26.md ✔
glob with pattern: "inbox.md", same paths →
<repo>/inbox.md ✔
So the failure is specifically: multi-segment pattern not prefixed with
**/. It looks like the matcher compares patterns against basenames (or a
single path segment) unless a globstar forces full-path matching.
Expected behavior
A relative pattern is resolved against the given paths roots, per standard
glob semantics: 2026/07/26.md matches <root>/2026/07/26.md. At minimum,
the tool description should say patterns must be **/-prefixed to traverse
directories — but fixing the matching is much better than documenting the
trap, since empty results are treated as evidence of absence.
Additional context
- OS: macOS 26.5.2, arm64
- Observed both from VS Code Agent Sessions and reproduced deterministically
(4 calls above, same session, seconds apart)
Describe the bug
The built-in
globtool returns "No files matched the pattern." for anypattern containing a path separator, unless the pattern is prefixed with
**/. Literal relative paths (2026/07/26.md) and wildcarded multi-segmentpatterns (
2026/07/*.md) both fail even though the files exist directly underthe given
pathsroot. Single-segment patterns (inbox.md,*.md) and**/-prefixed patterns work.This is worse than an inconvenience: the agent trusts the empty result. In one
session the agent checked for a file with its exact relative path, got no
match, and confidently declared the file missing — then acted on that false
premise.
Affected version
1.0.70-0 (running as the VS Code Agent Sessions CLI backend; macOS arm64)
Steps to reproduce the behavior
Against a repo containing
2026/07/26.mdandinbox.mdat the root:globwithpattern: "2026/07/26.md",paths: ["<repo>"]→No files matched the pattern.(file exists)globwithpattern: "2026/07/*.md", same paths →No files matched the pattern.(31 files exist there)globwithpattern: "**/07/26.md", same paths →<repo>/2026/07/26.md✔globwithpattern: "inbox.md", same paths →<repo>/inbox.md✔So the failure is specifically: multi-segment pattern not prefixed with
**/. It looks like the matcher compares patterns against basenames (or asingle path segment) unless a globstar forces full-path matching.
Expected behavior
A relative pattern is resolved against the given
pathsroots, per standardglob semantics:
2026/07/26.mdmatches<root>/2026/07/26.md. At minimum,the tool description should say patterns must be
**/-prefixed to traversedirectories — but fixing the matching is much better than documenting the
trap, since empty results are treated as evidence of absence.
Additional context
(4 calls above, same session, seconds apart)