VS Code extension: clicking chat links to binary files (images) silently fails — unhandled showTextDocument rejection

Summary

In the VS Code extension's chat panel, clicking a markdown link to any binary file (PNG, JPG, PDF, …) silently does nothing. The extension resolves the path correctly, then tries to open it with vscode.window.showTextDocument(), which rejects binary files — and the rejection is unhandled, so the user gets no error, no feedback, nothing.

For image-heavy workflows (e.g. Claude generating/reviewing art assets and linking them for review) this makes every link the model emits dead, and the user has to copy paths by hand and navigate manually.

Environment

• Claude Code VS Code extension: reproduced on every version I inspected from 2.1.123 (April) through 2.1.220 (current) — the code path is unchanged
• IDE: Antigravity (VS Code fork), macOS 15 / Darwin 25.5.0 — but the bug is in the extension's own handler and should reproduce in stock VS Code (showTextDocument rejects binaries everywhere)

Repro

1. Have Claude output a relative markdown link to any PNG in the workspace, e.g. [shot.png](assets/shot.png)
2. Click it in the chat panel
3. Nothing happens. The extension host log shows:

[error] CodeExpectedError: cannot open file:///Users/me/project/assets/shot.png.
Detail: File seems to be binary and cannot be opened as text

Links to text files (.md, .ts, …) work fine.

Root cause

In extension.js, the webview's open_file request is handled by openFile(filePath, location), which — after correct path resolution and a directory check that goes to revealInExplorer — unconditionally does:

ue.window.showTextDocument(n).then((i) => { /* selection/reveal logic */ })

• showTextDocument rejects with CodeExpectedError for binary files
• the promise has no rejection handler, so the failure is swallowed silently

No link-format workaround exists from the model side: file:// hrefs survive the markdown sanitizer but the webview host drops them, and custom-scheme deep links (vscode://file/... / fork equivalents) are stripped by the sanitizer's allowedSchemes list.

Suggested fix

Route non-text files through the generic opener, e.g.:

vscode.commands.executeCommand('vscode.open', uri)

either by sniffing known binary extensions before showTextDocument, or as a .catch() fallback when showTextDocument rejects (which also future-proofs any other non-text-openable resource). vscode.open shows images in the built-in image preview, which is presumably the expected UX.

At minimum, surfacing the rejection as an error notification would stop the failure from being silent.

Current workaround

Locally patching the installed extension.js to insert the extension-sniff + vscode.open fallback before the showTextDocument call fixes clicking for images — but the patch is wiped by every extension auto-update (which currently ship every 1–2 days), hence this report.