VS Code extension: chat file links use showTextDocument(), bypassing custom editors — PDFs always open as garbage text

Environment

• Claude Code VS Code extension anthropic.claude-code 2.1.220-win32-x64
• VS Code 1.130.0, Windows 11 Pro 26200
• PDF viewer extension tomoki1207.pdf 1.2.2 (custom editor pdf.preview, selector *.pdf)

What happens

When Claude writes a markdown link to a workspace file in the VS Code chat panel and the user
clicks it, the file is always opened in the text editor. For a PDF this means the user
gets a screenful of binary garbage instead of the rendered document. The same link clicked in
a Markdown preview opens the PDF viewer correctly.

Why

extension.js opens clicked file links like this:

let n = vscode.Uri.file(r);
try { if (fs.statSync(r).isDirectory()) { vscode.commands.executeCommand("revealInExplorer", n); return } } catch {}
vscode.window.showTextDocument(n).then(...)

vscode.window.showTextDocument() resolves in the workbench to $tryShowTextDocument, which
sets override: EditorResolution.EXCLUSIVE_ONLY:

$tryShowTextDocument(resource, options) {
    const o = { preserveFocus, pinned, selection, activation, override: 1 /* EXCLUSIVE_ONLY */ };
    const r = await this._editorService.openEditor({ resource, options: o }, ...);
}

That deliberately disables editor resolution, so neither workbench.editorAssociations nor
any registered custom editor with priority default is considered. Users cannot work around
it:

• workbench.editorAssociations has no effect (verified by measurement, with and without the

setting, after a window reload)

• a third-party extension cannot register a custom editor with priority exclusive — the

customEditors contribution point only accepts enum: ["default", "option", "never"]

• no URI scheme reaches the chat's opener: file:///, vscode://, command: and absolute

Windows paths are all silently ignored; only http(s) is forwarded to env.openExternal

• none of the 14 claudeCode.* settings affects how files are opened

Steps to reproduce

1. Install tomoki1207.pdf; confirm that clicking a PDF in the Explorer renders it
2. Put any PDF into the workspace
3. Have Claude write a relative markdown link to that PDF in the VS Code chat
4. Click the link → text editor with binary garbage
5. Click the same link in a Markdown preview of a workspace .md file → PDF renders correctly

Suggested fix

Use vscode.commands.executeCommand('vscode.open', uri, options) instead of
showTextDocument() for file links. vscode.open goes through the editor resolver, so PDFs,
images, notebooks and other custom-editor formats open in their proper viewer, while plain
text files behave exactly as before. Where the current code needs the returned TextEditor
(e.g. the searchText path), keep showTextDocument() for text documents and fall back to
vscode.open otherwise.

Additional, smaller issues found while investigating

• File paths containing umlauts are not resolved at all — the click does nothing, both literal

(.../Angebote-Prüfung/x.pdf) and percent-encoded (.../Angebote-Pr%C3%BCfung/x.pdf).
Markdown preview handles both correctly.

• Absolute paths (d:/…) in chat links do nothing.