findFiles doesn't find newly added files in a virtual workspace

[mb21]

Does this issue occur when all extensions are disabled?: Yes

This only seems to happen with a virtual workspace like GitHub in vscode.dev

Version: 1.101.0-insider
Commit: 2d6afddc470bf44f7e60fb5b6e6fdd08e771409b
Date: 2025-05-16T17:06:18.089Z
Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36

Steps to Reproduce:

1. Open any github repo in insiders.vscode.dev, for example https://insiders.vscode.dev/github/mb21/mastro-template-basic
2. Add a new file by in the Explorer view (e.g. test.css)
3. Hit Cmd-P and search for it (type e.g. test)
4. It does find the file as "recently openend": click the cross to "Remove from Recently Opened"
5. Hit Cmd-P again to search for the file

Expected: it finds the file Actual: it doesn't find the file

You may say this is a low-priority bug, because who clears the recently opened files? But I have the same problem when developing my extension, which calls vscode.workspace.findFiles, and there I don't have any recently opened files to fall back on. (I tried using vscode.workspace.findFiles2, but couldn't get it to work in vscode.dev, as it always says "You MUST start in extension development mode".)

[mb21]

Perhaps @andreamah could comment on whether this will be fixed in findFiles2? Or should I start working on a workaround for my extension? Thanks!

[andreamah]

I don't work in this area anymore, so I'll defer to @osortega :)

[osortega]

@mb21 I'm unable to reproduce this issue, looks like even after removing from recently opened I still see the file.

/gifPlease

[vs-code-engineering[bot]]

Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, .gif files are preferred as they are displayed inline on GitHub. You may find https://gifcap.dev helpful as a browser-based gif recording tool.

If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording (Developer: Toggle Screencast Mode in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue.

Happy coding!

[mb21]

Indeed, the exact steps I reported above now seem to work on insiders.vscode.dev, yet I can still reproduce them on vscode.dev and github.dev (see screen recording). Do you know what changed?

However, also on insiders.vscode.dev the following steps still are not working:

1. Open any github repo in insiders.vscode.dev, for example https://insiders.vscode.dev/github/mb21/mastro-template-basic
2. new step: Prime some cache: Hit Cmd-P and search for it (type test)
3. Add a new file by in the Explorer view (e.g. test.css)
4. Hit Cmd-P and search for it (type test)
5. It does find the file as "recently openend": click the cross to "Remove from Recently Opened"
6. Hit Cmd-P again to search for the file

This was on Version: 1.101.0-insider, Commit: 80203985a911729401181d4c044346508a175f35

Note that I can reproduce this also with this dummy extension (replacing the search in the GUI with a call to findFiles), so the bug must be somewhere in that function (or more accurately some state it depends on).

[mb21]

@osortega do I need to do anything for the info-needed tag to go away?

[mb21]

Okay, I debugged this with the Chrome dev tools on insiders.vscode.dev commit 7197360b79e6da3404ed5ad1fb4d7ea74a8bb5d2:

The return value of this.provider.provideFileSearchResults does not include the new files.

After that it calls into this extension.js file that has no source maps (or at least they don't load for me), and calls the function:

async provideFileSearchResults(e, {folder: t, maxResults: n, includes: i, excludes: o}, s) {
    const u = `${x(t)}|${JSON.stringify({
        includes: i,
        excludes: o
    })}`;
    let c = this.fileSearchCache.get(u);

Note that this.fileSearchCache.get(u) is a cache hit but does not include the new files. Thus the bug must be in whatever fails to update/invalidate the fileSearchCache.

I searched for the source of this file, and found extensions/github-browser/src/github/fs.ts in an old version of vscode, which looks very much like that file. However, it seems that extensions/github-browser was moved somewhere else a while ago, probably a private repo?

@osortega or @andreamah Would be great if you could tell me who owns that code now, because that's where the bug is. Seems this is the feedback repo?

Edit: on second thought, perhaps the github-browser extension is just used the wrong way? fileSearchCache is only set if there was no cache-hit, and only cleared in onRefreshOrRepositoryChanged (exposed as onDidChangeRepository I think). Otherwise it doesn't change. So probably the bug is that onDidChangeRepository is not called in that case.

[osortega]

Thanks for all the details, this helps a lot. I was able to reproduce this bug and marked it as confirmed

[reekystive]

I'm experiencing a similar issue where vscode.workspace.findFiles returns empty results in virtual workspaces, even when files exist and are accessible via direct vscode.workspace.fs.stat calls.

My specific case

• Extension: VS Code pnpm Workspace
• Problem: Need to find package.json files using patterns like packages/*/package.json
• Workspace types affected: GitHub Codespaces, vscode-test-web://, and other non-file scheme workspaces
• Standard findFiles returns 0 results despite files being present and accessible

Workaround implemented

I've created a comprehensive fallback system that manually traverses directories using vscode.workspace.fs APIs when findFiles fails in virtual workspaces. The implementation includes:

• Detection of virtual workspaces (non-file URI schemes)
• Manual directory traversal with glob pattern matching
• Fallback chain: try findFiles first, then manual traversal if needed

You can see the full implementation here:

https://github.com/reekystive/vscode-pnpm-workspace/blob/3d8b2ea3e46913ae2a47df4b530725898ec5b72c/src/virtual-workspace-workaround.ts#L146

Impact

This issue significantly affects extension functionality in virtual workspaces, requiring complex workarounds that duplicate VS Code's built-in file discovery logic. A fix would eliminate the need for these manual implementations and improve the developer experience for extensions that rely on file discovery.

The workaround works reliably, but it would be much better to have the standard findFiles API work consistently across all workspace types.

[mjbvz]

This also is effecting #codebase. Simple repo:

1. Install https://marketplace.visualstudio.com/items?itemName=jrieken.vscode-memfs
2. Run MemFS: setup workspace then MemFS: Create files to populate it
3. From your extension run vscode.workspace.findFiles('**/*');

This call never returns in my testing