- Copilot Chat Extension Version: 0.43.0 (EDITED - originally reported as 0.38.2 - regression introduced between 0.32.x and 0.38.x)
- VS Code Version: 1.115.0 (EDITED - originally reported as 1.110.x - worked correctly in 1.108.x)
- OS Version: Linux (RHEL 9, x86_64) - but issue is OS-independent
- Feature (e.g. agent/edit/ask mode): agent mode
- Selected model (e.g. GPT 4.1, Claude 3.7 Sonnet): Claude 4.6 Sonnet, Claude 4.5 Sonnet, Claude 4.6 Opus
- Logs: transcript evidence below
Steps to Reproduce:
- Open a Markdown or text file longer than 200 lines where the content around line 200 ends on a natural-looking boundary (e.g., a complete bullet point, the end of a section). A skill/documentation file works well.
- In Agent mode, ask the model to read the file and summarize it. The model reads lines 1-200, receives raw text with no metadata indicating total file length, and reports a "complete" summary - silently losing everything after line 200. The model usually chooses 200 as the batch size; in a very rare case it chooses 100, it seems to notice the output ending abruptly and runs more
read_file batches to read it fully.
- Ask follow-up questions about content that exists only in lines 200+. The model will confidently say that content doesn't exist.
- Only when explicitly challenged ("Are you sure you have the whole file?") does the model read further.
What changed
Commit microsoft/vscode-copilot-chat@7dc4b8e ("tools: avoid putting fences into file reads by default", 2026-02-06) changed the read_file tool output in two ways:
- Removed code fences (triple backticks wrapping file content)
- Removed the metadata header line that previously read:
File: `path/to/file`. Lines 1 to 200 (430 lines total):
Old output (working, pre-1.108):
File: `skills/my-great-skill/SKILL.md`. Lines 1 to 200 (430 lines total):
[file content here]
New output (1.110+):
The (430 lines total) metadata was the only signal the model had that a partial read occurred. Without it, and with the content ending on a syntactically complete line, the model has no way to distinguish "I read part of the file" from "I read the whole file."
The model confirmed this in a conversation:
"The current read_file tool does not return total line count metadata. The response is just the raw file content for the requested range. If previous versions returned something like {"content": "...", "totalLines": 430}, that made the batching loop reliable and automatic. Without that metadata, the agent has to over-estimate or risk stopping early — which is exactly what happened here. That's a real regression in the tooling, not a model reasoning failure."
The model was asked why it read 200 lines and then believed the file ended at line 200. Its verbatim response:
Honestly, 200 was an arbitrary round number — a rough heuristic guess. There was no specific reason to choose 200 over 100 or 300. In hindsight, the better approach would have been to check the file length first (e.g., wc -l) and then read the full file in one shot, rather than guessing. Or at minimum, check whether the response was cut off at the end and read more if needed. The file happened to end right at line 200, so it worked out — but it was luck, not reason.
Requested fix
Please, either always include the header (N lines total) in the tool result, or make readFileCodeFences a public user-facing setting.
Steps to Reproduce:
read_filebatches to read it fully.What changed
Commit microsoft/vscode-copilot-chat@7dc4b8e ("tools: avoid putting fences into file reads by default", 2026-02-06) changed the read_file tool output in two ways:
Old output (working, pre-1.108):
New output (1.110+):
The
(430 lines total)metadata was the only signal the model had that a partial read occurred. Without it, and with the content ending on a syntactically complete line, the model has no way to distinguish "I read part of the file" from "I read the whole file."The model confirmed this in a conversation:
The model was asked why it read 200 lines and then believed the file ended at line 200. Its verbatim response:
Requested fix
Please, either always include the header (
N lines total) in the tool result, or makereadFileCodeFencesa public user-facing setting.