microsoft / microsoft/vscode

[security] chat fetch allow/deny behavior different based upon grouping of requests

Open
#334,292 0 comments 0 reactions 1 assignee Claimed by @TylerLeonhardt View on GitHub
Dominant language
TypeScript
Stars
193k
Forks
42.4k
PR merge metrics
PR metrics pending

Description

**Issue:** Whether a user is required to confirm fetches is currently based upon whether multiple fetches are done in a group or individually. **Security should not depend on sequencing or grouping of the request.**

In my `settings.json` I have the following:

```json
"chat.tools.urls.autoApprove": {
….
"https://github.github.com/gfm": {
"approveRequest": false,
"approveResponse": true
},
"https://spec.commonmark.org": true,

},
```

I also have a prompt (let's call it `/load-context`) that tells the LLM to fetch these two documents:

* [CommonMark 0.31.2 specification](https://spec.commonmark.org/0.31.2/)
* [GFM 0.29-gfm specification](https://github.github.com/gfm/)

If the LLM attempts to fetch those two documents from the Internet as separate requests, _those requests succeed_!

But if the LLM attempts to fetch them both at the same time, then I am presented with an approval dialog.

Image

(There was one other listed item in the cropped screen shot because before filing this ticket I added a third document to fetch. Nevertheless the behavior is identical; I have not included the third document in order to simplify this bug report.)

Image

Furthermore as you can see the approval requests mentions the CommonMark spec, which was from a completely-approved domain.

Below is a screen shot of when the model attempted to fetch _the same documents_! This happened after I filed this ticket (but is simply another occurrence of the behavior this ticket is reporting). I am inferring that the difference is that the two documents were fetched separately rather than as a group; but perhaps a different tool is being used.

Image

Whatever the root cause, this is a security issue because allow/deny behavior _should be deterministic and consistent under all conditions_, not affected by the order or the grouping of the request. There are several problems and questions surrounding this;

* Does `"approveRequest": false,` mean that a request to the GFM document should _always_ require approval before retrieval? If so, this is broken: if requested individually, it succeeds.
* If `"approveRequest": false,`, shouldn't I be presented with an option to "always approve requests for this resource/domain"? I'm never presented with such an option — only a dialog to approve _both_ (one time) if they are being fetched together.
* Why do my settings even say `"approveRequest": false` to begin with? This is not to question why I made a choice; the question here is to examine why that situation might have come about in the first place, as I likely would have allowed the retrieval. Perhaps when it started asking about the other URL, it stopped asking about the GitHub URL? That is the purpose of this question; it feels like perhaps the order at which these got added to settings could have something to do with it. It's something to consider.
* Why does it indicate the CommonMark URL as needing review, when it is completely allowed?
* Even though it asks me to "Allow and Review Once", _it doesn't actually then present the result for review_.

(One thing you might want to check is whether there is some hard-coded behavior regarding GitHub's own domains in some logic branch of the security checks. I'm not saying there is any indication of this; I'm just brainstorming things you might want to check, my having not looked at the code.)

This has been happening for many versions; this is not a regression in the latest version.

```
Version: 1.136.1 (user setup)
Commit: a44adf7f53e00964ab890f9f8758a334f1fc15bc
Date: 2026-09-03T05:06:41Z
Electron: 42.10.0
ElectronBuildId: 15109253
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
@github/copilot: 1.0.81-0
@github/copilot-sdk: 1.0.11
OS: Windows_NT x64 10.0.26200
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.