[BUG] VS Code extension: @-mention file picker only searches the first folder of a multi-root workspace

Summary

In a multi-root VS Code workspace, the @-mention file picker only offers files from the first workspace folder. Files in the other folders are unreachable from the picker, even though the extension passes those folders to the CLI via --add-dir and Claude can read and edit them without trouble. The limitation is purely in the picker's file index.

Repro

1. Create a .code-workspace with three sibling folders:

{ "folders": [{ "path": "central-system" }, { "path": "frontend" }, { "path": "backend" }] }

1. Open it in VS Code and open the Claude Code panel.
2. Type @ in the input and search for a filename that exists only in frontend or backend.

Expected: results from all three workspace folders.

Actual: only files under central-system (the first folder) are suggested. Nothing from frontend or backend ever appears.

Root cause

In extension.js (2.1.235), the picker's search delegates to a ripgrep helper that takes a single root directory:

l = await TLe(e, this.cwd, bp(this.output))

TLe runs rg --files --follow --hidden with this.cwd as its only search path, and this.cwd is the first workspace folder. The remaining folders are never walked.

The fallback path is already multi-root correct — D5() uses vscode.workspace.findFiles, which searches every workspace folder:

i = await Lo.workspace.findFiles(t, r, 100)

but D5() only runs when the ripgrep call throws, so in normal operation the narrower path always wins. The code immediately around the call site already reads workspace.workspaceFolders and early-returns when it is empty, so the full folder list is in hand — it just isn't used for the search.

Suggested fix

Run the ripgrep search once per workspace folder, or pass every folder as a search path in a single rg invocation (rg supports multiple search paths natively), then merge and rank the results. Paths would need to be returned in the multi-root workspace-relative form to stay unambiguous. Failing that, preferring the existing findFiles path when workspaceFolders.length > 1 would be a smaller correctness win.

Related

insertAtMention (Cmd+Alt+K) inserts workspace.asRelativePath(...), which in a multi-root workspace returns a folder-name-prefixed path like frontend/src/Foo.tsx while the CLI's cwd is the central-system folder — so the inserted path isn't resolvable relative to cwd. A separate, smaller multi-root inconsistency in the same area.

This looks like the same class of bug as the file-link issues (#62718, and #83089 / #80126 which are now closed), but on the input side rather than the output side — the picker's search root, not link resolution. #36949 requests a claudeCode.workingDirectory setting, which would let a user pick which folder is searched but still wouldn't search all of them.

There is currently no setting that works around this; the extension exposes no configuration for search roots.

Workarounds

• None

Environment

• Claude Code extension: 2.1.235 (darwin-arm64)
• Claude Code CLI: 2.1.235
• VS Code: 1.133.0
• macOS 26.5.2, arm64