GitHub Copilot `file_search` truncation can cause false “file does not exist” conclusions

[garretwilson]

GitHub Copilot file_search result truncation consistently trips up models. This is a recurring problem and the results misguide models. A model such as GPT-5.6 Luna is completely capable of a simple task of loading the context window with relevant context. However if there are many files, the file_search tool just truncates results and does not provide sufficient notice to the model that results were truncated and that more results are available. Instead, the model comes away with the impression that some of the files it was looking for does not exist.

Below is the explanation in the words of GPT-5.6 Sol:

file_search truncation is not reported explicitly enough

Description

A prompt requested loading several project-context artifacts, including an active work item's description, while skipping targets that do not exist.

I searched the work item's directory using a recursive glob:

path/to/work-item/**

I omitted maxResults, expecting the returned file list to be sufficient for determining which requested artifacts existed.

The tool reported the total number of matches, displayed only a subset, and ended the output with .... Because truncation was indicated only by this unstructured ellipsis, the omitted description file was incorrectly treated as absent.

A targeted search or a sufficiently large maxResults returns the file correctly, so this is not an indexing failure. It is a result-reporting problem: callers can easily mistake a partial result set for a complete inventory.

Steps to Reproduce

1. Create a directory containing more files than file_search displays by default.
2. Place the target file outside the subset selected for display.
3. Call file_search with a recursive glob and omit maxResults.
4. Observe that the tool reports the total match count, displays only some paths, and appends ....
5. Observe that the response provides no structured truncation flag, displayed-result count, or continuation mechanism.

Actual Behavior

Truncation is represented only by a trailing ellipsis. A matching file omitted from the displayed subset can therefore be mistaken for a nonexistent file.

Expected Behavior

The response should explicitly state that it is truncated, for example:

Showing 20 of 24 results. Results truncated; narrow the query or increase maxResults.

Ideally the tool result would also expose structured metadata such as:

{
  "totalResults": 24,
  "returnedResults": 20,
  "truncated": true
}

This would let agents reliably distinguish “no match exists” from “the match may have been omitted.”

Environment

Version: 1.131.0 (user setup)
Commit: e4c7e7b1d6d060162f4aa7f8225271b67ce1df75
Date: 2026-07-28T10:51:25Z
Electron: 42.7.0
ElectronBuildId: 14710161
Chromium: 148.0.7778.280
Node.js: 24.18.0
V8: 14.8.178.38-electron.0
OS: Windows_NT x64 10.0.26200

[garretwilson]

This actually has huge ramifications throughout the ecosystem. The task of "loading project ticket context" from a custom prompt is just one use case. Models need to look up files all the time, and I constantly see them claiming that a file doesn't exist, merely because this GitHub Copilot tool took it upon itself to truncate search results at a very low number, and even worse, did not provide sufficient feedback to the model that more files exist and how to resubmit the request to find them.

I would imagine that thousands of model searches daily are returning incorrect results and the models are making bad decisions based upon this bad information. It's bad enough to try to work around hallucinations, bad reasoning, etc.; but now we have to contend with inferior tools.

It's a file search! A file search tool (in an IDE no less!) should not be causing us problems, but here we are. See also #293428/#328102 and #293430.