[BUG] `ide_selection` broken when filename starts with square brackets

Confirming this on macOS, and I traced the root cause. The scope is broader than the title suggests.

It's not limited to filenames, or to leading brackets. The trigger is any glob metacharacter anywhere in the path — including a directory several levels above a plainly-named file. My case is src/routes/{-$locale}/perimenopause/visits/book/index.tsx: the filename is an ordinary index.tsx, and the offending segment is a TanStack Router optional-segment directory. Braces fail exactly like brackets.

Root cause

pfr() in extension.js decides whether a file is hidden/ignored by feeding the file's own relative path back into findFiles as a glob pattern:

let r = No.workspace.asRelativePath(e, !1);
let n = await PLe();
if ((await No.workspace.findFiles(new No.RelativePattern(t, r), n, 1)).length === 0) return !0;

A path containing {} or [] does not self-match as a glob — {-$locale} parses as brace alternation, [id] as a character class. findFiles returns 0 results, so the function returns true, "ignored".

That result flows into the selection builder, which omits selectedText for ignored files:

function nZ(e, t) {
  ...
  let s;
  if (!t) s = r.getText(o);            // t = isIgnored; text captured only when false
  return { filePath: n, startLine: ..., endLine: ..., selectedText: s };
}

Note that the git check-ignore call further down in pfr() answers this question correctly — it's just gated behind the broken findFiles probe, which returns early.

Secondary issue

The webview picks its tag based on the presence of selectedText:

if (i.selectedText)
  a.push({ ... `<ide_selection>The user selected the lines ${i.startLine} to ${i.endLine} from ${i.filePath}: ...` });
else
  a.push({ ... `<ide_opened_file>The user opened the file ${i.filePath} in the IDE. ...` });

nZ() computed correct startLine/endLine and they're discarded here. Even for a genuinely gitignored file this is worse than lossy — it tells the model the file was merely "opened" when the user actually selected a range. Emitting <ide_selection> with the line range and omitting only the text would preserve the signal, and would have made this bug visible instead of silent.

Verification

Against ripgrep, the engine backing findFiles — each path is globbed against itself:

app/[slug]/page.tsx          -> FAILS to self-match
app/{-$locale}/page.tsx      -> FAILS to self-match
app/(marketing)/page.tsx     -> matches
app/normal/page.tsx          -> matches

Escaping the metacharacters ([{]-$locale[}]) restores the match. git check-ignore on the affected files exits 1 — they are not ignored.

Suggested fix

Escape glob metacharacters ({}, [], *, ?) in r before building the RelativePattern, or drop the findFiles probe entirely and rely on the git check-ignore call already present.

Workaround

Alt+K (claude-vscode.insertAtMention) works on affected files — it bypasses the ignore check, and the @-mention resolver handles the metacharacters correctly.

Environment

anthropic.claude-code-2.1.237-darwin-arm64, VS Code 1.134.0, macOS 26.6.2 arm64 — so this is not Windows-specific (issue is currently labeled platform:windows) and is still present in 2.1.237.

Identifiers above (pfr, nZ) are from the minified bundle in that build.

Possibly related

#83861 and #37392 are the same class of defect in the chat-link handler (paths with square brackets, e.g. Next.js [locale] folders). A path-escaping audit would likely cover all of these together.

@HiiiiD @kyle-pomelo hey, it seems this is fixed now in the latest version of vscode (1.139.0 as of now), can you confirm this? #83861 and #37392 however are still an issue.

I think it's fixed now (I still have an older vscode (1.133.0), but I updated the CC extension, which was probably the fault)

Confirmed fixed! Thank you!