MCP tool results for large files are silently truncated with a vscode-chat-response-resource:// hint that does not work

[mikejohnstonPremierinc]

Description

When a GitHub MCP get_file_contents tool call returns a large file (50KB–999KB, under the MCP server's 1MB hard limit), VS Code's context window manager truncates the tool result before it reaches the LLM and marks the response isTruncated=true.

VS Code then displays the following hint to the agent/user:

"you can read the full contents of any truncated resources by passing their URIs as the absolutePath to the read_file tool"

The hint provides a vscode-chat-response-resource:// URI. However, passing this URI to read_file (VS Code's built-in file reading tool) does not work. It returns:

"File is outside of the workspace, and not open in an editor, and can't be read."

The hint instructs a recovery action that is impossible to perform. This causes AI agents to enter a confused state where they have been told a recovery path exists, attempt it, fail, and have no clear way forward.

Steps to Reproduce

1. Open VS Code with the GitHub MCP server configured
2. In Copilot Chat, use the get_file_contents tool to fetch a file between 50KB and 999KB from a GitHub repository (e.g., a large C# utility file ~120KB)
3. Observe that VS Code truncates the result and marks it isTruncated=true
4. Observe the hint displayed: "you can read the full contents of any truncated resources by passing their URIs as the absolutePath to the read_file tool" along with a vscode-chat-response-resource://... URI
5. Attempt to call read_file with that URI as the absolutePath parameter
6. Observe the error: "File is outside of the workspace, and not open in an editor, and can't be read."

Reproduction files used:

• PQA_Training_Services.cs (~120KB) from PremierInc/pqa-browser-base-framework
• Browser.Base.Framework.xml (~233KB) from same repo

Both triggered the truncation + broken hint on the same session.

Expected Behavior

Either:

• (a) The vscode-chat-response-resource:// URI is readable via read_file, allowing the agent to retrieve the full content as the hint promises, OR
• (b) The hint is removed entirely and replaced with an honest message such as: "This file is too large to include in full. Use search_code with specific search terms to find the content you need."

Actual Behavior

The hint is displayed but the suggested action is impossible. read_file with the URI returns an error. The agent has no actionable recovery path from the hint.

Additional Context

• This appears to be an incomplete or abandoned feature — the URI scheme (vscode-chat-response-resource://) exists in VS Code internals but is not exposed as a readable file path to tools
• Related community discussion: https://github.com/orgs/community/discussions/164353 (even 14.4KB files truncated)
• Related community discussion: https://github.com/orgs/community/discussions/169224 ("Copilot's context pipeline isn't currently designed to automatically ingest arbitrary file contents")
• Separate but related: copilot-cli has a distinct 10KB truncation bug (MCP tool responses silently truncated to 10KB before large-output-to-file mechanism can save them github/copilot-cli#1732) — that is a different issue, not this one

Copilot Chat Extension Version

• VS Code Version: 1.116.0
• OS Version: Windows_NT x64 10.0.26200
• Feature (e.g. agent/edit/ask mode): agent/ask
• Selected model (e.g. GPT 4.1, Claude 3.7 Sonnet): Claude Opus
• Logs:

[mikejohnstonPremierinc]

Hi, thanks for the questions!

1. Does this work on a fresh install?
   It does not work on a fresh install. The vscode-chat-response-resource:// URI scheme fails deterministically every time read_file is called with it — it's not flaky or environment-dependent. The behavior is reproducible across sessions.

2. What does the full error trace show?
   There is no stack trace — the failure is a tool-level response, not an exception. The complete output returned to the agent when calling read_file with a vscode-chat-response-resource:// URI is exactly:

"File is outside of the workspace, and not open in an editor, and can't be read."

That is the entire response. No additional detail is surfaced to the agent.

3. Have you tried the workaround mentioned in similar issues?
   Could you point me to the specific issue? I wasn't able to find a prior report for this exact scenario. The hint itself is the intended recovery path — there is no other workaround built into the flow. Our actual workaround is to ignore the hint entirely and use search_code with multiple targeted queries to reconstruct the file content from fragments, which is not ideal but functional.