fix: fetch tool should not warn when reading files inside the workspace

[Copilot]

The fetch tool was showing a "Fetch web page?" confirmation dialog for file:// URIs pointing to files inside the currently open workspace. The prompt injection risk warning makes no sense for workspace files that are already accessible.

Root cause

prepareToolInvocation added all URIs — web and file — to urlsNeedingConfirmation. Since trustedDomainService.isValid() only handles HTTP(S) domains, file URIs always failed the trust check and triggered the dialog.

Changes

• fetchPageTool.ts: Inject IWorkspaceContextService and use getWorkspaceFolder() to classify file URIs:

  • allFetchedUris (web + all file URIs) — message display only
  • fileUrisOutsideWorkspace — file URIs not inside any workspace folder
  • urlsNeedingConfirmation (web URIs + files outside workspace) — trust checks and confirmation dialog

  Workspace file fetches now produce confirmationTitle = undefined and confirmResults = false — no dialog, no post-confirmation. Files outside the workspace still trigger confirmation, as do all web (http/https) URIs.

• fetchPageTool.test.ts: Added TestContextService to all constructor calls; added tests covering: workspace file (no dialog), file outside workspace (still shows dialog), mixed workspace file + untrusted web URI (only web URI appears in confirmation).

Notes

Symlink resolution was considered but intentionally omitted — no other workspace membership checks in the codebase (e.g. read_file, ChatExternalPathConfirmation) resolve symlinks, and the confirmation dialog here is primarily guarding against web prompt injection rather than local filesystem traversal.

---

📱 Kick off Copilot coding agent tasks wherever you are with GitHub Mobile, available on iOS and Android.

[TylerLeonhardt]

@copilot I was expecting you to just check if the files are in the currently open workspace

[Copilot]

@copilot I was expecting you to just check if the files are in the currently open workspace

Reworked in 9b462d8. Now FetchWebPageTool injects IWorkspaceContextService and checks getWorkspaceFolder() for each file URI — files inside the workspace are excluded from urlsNeedingConfirmation, so no dialog is shown. Files outside the workspace still trigger confirmation, as do all web (http/https) URIs.

[Copilot]

Pull request overview

Adjusts the internal Chat “fetch” tool’s confirmation behavior so that reading file:// URIs inside the currently open workspace no longer triggers the “Fetch web page?” confirmation prompt, while still requiring confirmation for web URLs and file URIs outside the workspace.

Changes:

• Update FetchWebPageTool.prepareToolInvocation to classify URIs using IWorkspaceContextService.getWorkspaceFolder() and exclude workspace-contained file URIs from confirmation checks.
• Update message counts to use “all fetched URIs” (web + all valid file URIs) while keeping confirmations limited to web + outside-workspace file URIs.
• Extend tests to cover workspace file URIs (no dialog), outside-workspace file URIs (dialog), and mixed workspace file + untrusted web URI (only web prompts).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/vs/workbench/contrib/chat/electron-browser/builtInTools/fetchPageTool.ts	Injects workspace context to skip confirmations for workspace-contained file URIs; keeps confirmation for web/outside-workspace URIs.
src/vs/workbench/contrib/chat/test/electron-browser/tools/builtinTools/fetchPageTool.test.ts	Updates constructor calls and adds coverage for new workspace vs outside-workspace confirmation behavior.

[TylerLeonhardt]

@copilot what do you think of this comment ... does it feel contrived?

[Copilot]

@copilot what do you think of this comment ... does it feel contrived?

Yes, I think it's contrived for this context. A few reasons:

1. Inconsistency with existing patterns: The read_file tool and ChatExternalPathConfirmation also use getWorkspaceFolder() for workspace membership checks and don't resolve symlinks either. Adding symlink resolution only here would be inconsistent without fixing the same gap everywhere.

2. Same threat model: If an agent can create a symlink inside the workspace pointing to a sensitive file, it already has sufficient local access to do much worse. The fetch tool's confirmation dialog is primarily guarding against web prompt injection — that threat doesn't apply to workspace files regardless of symlinks.

3. fileService.realpath() returns Promise<URI | undefined>, so every file URI fetch would require an additional async stat + realpath call, adding latency for the common (non-symlink) case.

Happy to apply it if you feel strongly, but I'd lean toward leaving it as-is and addressing symlinks globally across all workspace membership checks if/when it's deemed necessary.