GitHub Copilot refuses to use VS Code search tools for multi-root workspaces

[garretwilson]

GitHub Copilot refuses to use its search functionality to look for files in another root of a multi-root workspace.

This is exhaustingly frustrating. This has gone on for hours and there is no solution. It's just a GitHub Copilot bug.

Reproduction

(I'm using Git Bash on Windows 11, so I'm showing Git Bash style Windows paths.)

1. Open /c/foo in VS Code.
2. Use "File > Save Workspace As..." to save the project as /c/projects/foobar.code-workspace.
3. Use "File > Add Folder to Workspace..." to add the folder /c/bar. You wind up with:
   /c/projects/foobar.code-workspace
   • /c/foo
   • /c/bar
4. Add a default instructions file and add the following:

## Tools

- **Always use VS Code tools (`file_search`, `grep_search`, `read_file`) for file operations.** Use `file_search` with a glob pattern (e.g., `**/Filename.java`) to locate files before assuming they are external.
- Terminal file commands (`grep`, `cat`, `find`, `sed -i`) are permitted **only** for paths listed under "allowed external paths" that `file_search` confirms are not in the workspace.
- For `grep_search`, use workspace-relative paths in `includePattern` (e.g., `**/ByteOrderMark.java`), not absolute paths.
- For `read_file`, use the absolute path returned by `file_search`.
- When performing search-and-replace operations across multiple files in the workspace, use VS Code's built-in search-and-replace facility rather than shell tools like `sed -i`. VS Code preserves line endings, provides change preview, and integrates with the editor's undo system. Reserve `sed` for stream processing or piped transformations where output goes to `stdout`. **Do not** use `sed -i` for in-place file modification.

## Code Search

For searching the code of dependency libraries (especially the `bar` library), the source code may have been added to the workspace as a separate root workspace. **First see if the appropriate directories have been added to the workspace as described above. If so, use workspace tools to search the files directly.**

## Instructions Checklist

- **Stop!** Before any file operation, run `file_search` with a glob pattern (e.g., `**/Filename.java`).
- If `file_search` returns a result, use VS Code tools. Do not use `cat`, `grep`, or `find`.
- If `grep_search` returns no results due to `.gitignore` or exclude settings, retry with `includeIgnoredFiles: true` before falling back to terminal commands.

5. Ask GitHub Copilot to look up something in the bar library.

Expected: GitHub Copilot will use a VS Code tool such as file_search, grep_search, or read_file to search /c/bar in the workspace.

Actual: GitHub Copilot will try to search GitHub for the source code. Or it will try to download something. Or it will make stuff up. Or heaven forbid that it sees in the terminal that you used some command to access the /c/bar directory, in which case it will try to grep or cat or sed -i in /c/bar

I don't care if you write a whole book of instructions. They are futile. GitHub Copilot will ignore all of it. Even a top model such as Claude Open 4.5.

I'm not saying it can't use tools to search other workspace roots. If you force it to, and call it out, and deny its terminal commands, and ask it to read the instructions again, even weaker models such as Claude Haiku 4.5 will eventually relent and use the VS Code search tools in the other workspace roots as requested.

This is not only a huge GitHub Copilot usability issue, it is also a security issue. The issue here is not to prevent access to other directories (although that is a separate issue #282211). This ticket is not about denying the terminal commands; I've already done that to large extent in settings.json. The issue here is that VS Code GitHub Copilot refuses to use the built-in search tools as a first resort, without wasting half my day telling it over and over again each time to RTF instructions.

One can say, "ah, LLMs will be LLMs", but I do not believe that. Tool usage is an essential part of using GitHub Copilot in VS Code, and if you do not put in the appropriate safeguards and/or prompt structures to make sure the LLM tries to use the bult-in tools first, the product is broken. LLMs have all sorts of biases and defects. You must find out how to work around them, and the behavior here tells me that not only is GitHub Copilot not effectively working around these LLM issues, something about the way built-in tools and instructions are presented to the LLM is biasing the LLM against using the built-in tools.

Version: 1.108.2 (user setup)
Commit: c9d77990917f3102ada88be140d28b038d1dd7c7
Date: 2026-01-21T13:52:09.270Z
Electron: 39.2.7
ElectronBuildId: 12953945
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Windows_NT x64 10.0.26200

[snoop244]

I would estimate 1 out of 2 prompts will spin and spin on the grep issue in my workspace. I can see in GPT 5.2's reasoning:

"Troubleshooting grep issues. It seems like I'm having trouble with the grep command, possibly due to the include pattern. I double-checked, and the file does exist at..."

Eventually it fulfills the prompt, but it really seems confused by this.

[garretwilson]

@roblourens , the difficulty GitHub Copilot has using search tools within the workspace may be related (at least in part) to bugs in the search tools themselves—one of which is pretty severe—which I have filed as #293428, #293430, and #293204 .

[snoop244]

Is there a reasonable workaround for this? Something I can add to my prompt to steer the AI? A different way to setup a workspace?

[roblourens]

It doesn't match my general experience that it refuses to use the proper tools for multi-root workspaces specifically. I am aware that

• It often uses them incorrectly or inefficiently in multiroot
• Sometimes they really want to run terminal commands instead of using the search tool, depending on the scenario and model

And we're definitely fighting the models here because they are all trained on more typical single-cwd scenarios and rely on terminal commands. In the terminal it can do really precise searches instead of reading huge amounts of raw tokens. Which is nice in some scenarios. And so I think only reliable sandboxing will give us precise and efficient exploration.

But I'm going to try some different patterns in the search tools and see if that helps things.

[garretwilson]

I include the explicit LLM instructions I indicated in the description, and I have turned-off auto-approve for search commands, e.g.:

"chat.tools.terminal.autoApprove": {
    "cat": false,
    "find": false,
    "grep": false,
    "sed": false,

Now when the LLM tries to use the terminal to search, I can hit the Skip button and the LLM can usually figure out to the use the search tools. (Obviously this is not ideal, because many times it wants to pipe things to grep, e.g. mvn test | grep …, which is OK and is not the same things as searching files within the workspace.

So I'm limping by with this ticket.

Related but much more debilitating are the bugs in the search tools themselves in multi-root workspaces, especially #293428. This is a undeniable bug that fails to retrieve content and is inconsistent with the other search tools. The poor LLM tries to search and doesn't find anything. Even with my telling the LLM about this VS Code GitHub Copilot bug, the LLM gets confused when it looks for a file but can't find it.

@roblourens why is no one even paying attention to #293428 and its two related bugs? These are much more pressing that the current bug, and #293428 likely even contributes to this bug! (The LLM will likely fall back to terminal commands because the built-in search tools don't return what they should.) I put a lot of research into that bug report and a lot of effort into presenting it correctly. It's a model bug. It explains the situation. It provides extensive evaluation on edge and corner cases, and even presents a survey of results compared with other search tools that all should provide consistent results but don't. This is an undeniable, well-documented, significant bug in a tool. Why is it being ignored?