Problem
Glob returns at most 200 matches and reports nothing about whether the pattern matched more. A caller receiving exactly 200 cannot tell a complete result from a capped one:
await globFiles({ cwd, pattern: '*.txt', limit: 200 })
// { files: [ ...200 paths... ] }A directory holding 201 matching files produces the same shape and the same count as one holding exactly 200. The model therefore reads a partial listing as the whole answer: it can conclude a package has no tests, that a rename left nothing behind, or that a directory listing is complete when it is not.
The tool description ("Returns at most 200 matches") does not help, because a count of exactly 200 is ambiguous by construction.
Grep already answers this question for search results — it returns matchedLines, returnedLines, omittedLines, and truncated from one completed search. Glob has no equivalent, so the two search tools disagree about whether they report completeness.
Desired outcome
Glob reports whether the result was cut short. Reading one match past the cap distinguishes "the pattern had exactly limit matches" from "there were more":
- exactly at the cap →
truncated: false
- more than the cap →
truncated: true, with limit files returned
The flag reaches the model in the Glob tool result, and the tool description states it.
One constraint matters as much as the flag itself. Filling the cap ends the result set; traversal past it only answers whether one more match existed. It must therefore not newly fail a capped result. Today a 200-match query over a large tree succeeds when some directory further down is unreadable, because the walk stops at the cap. A naive probe walks one step further and turns that success into an EACCES failure, which would regress exactly the large repositories the cap exists to serve.
Alternatives or workarounds
The model can narrow the pattern or add directory prefixes and compare counts across several calls. That costs turns, is unreliable, and cannot recover the fact that the walk discarded — nothing downstream of the tool can reconstruct whether the list was complete.
Problem
Glob returns at most 200 matches and reports nothing about whether the pattern matched more. A caller receiving exactly 200 cannot tell a complete result from a capped one:
A directory holding 201 matching files produces the same shape and the same count as one holding exactly 200. The model therefore reads a partial listing as the whole answer: it can conclude a package has no tests, that a rename left nothing behind, or that a directory listing is complete when it is not.
The tool description ("Returns at most 200 matches") does not help, because a count of exactly 200 is ambiguous by construction.
Grep already answers this question for search results — it returns
matchedLines,returnedLines,omittedLines, andtruncatedfrom one completed search. Glob has no equivalent, so the two search tools disagree about whether they report completeness.Desired outcome
Glob reports whether the result was cut short. Reading one match past the cap distinguishes "the pattern had exactly
limitmatches" from "there were more":truncated: falsetruncated: true, withlimitfiles returnedThe flag reaches the model in the Glob tool result, and the tool description states it.
One constraint matters as much as the flag itself. Filling the cap ends the result set; traversal past it only answers whether one more match existed. It must therefore not newly fail a capped result. Today a 200-match query over a large tree succeeds when some directory further down is unreadable, because the walk stops at the cap. A naive probe walks one step further and turns that success into an
EACCESfailure, which would regress exactly the large repositories the cap exists to serve.Alternatives or workarounds
The model can narrow the pattern or add directory prefixes and compare counts across several calls. That costs turns, is unreliable, and cannot recover the fact that the walk discarded — nothing downstream of the tool can reconstruct whether the list was complete.