anthropics / anthropics/claude-code
[BUG] VS Code extension: chat file links are never wired to the existing open_file bridge
- Dominant language
- Python
- Stars
- 145k
- Forks
- 23.1k
- PR merge metrics
- PR metrics pending
Description
### Preflight Checklist
- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues) — this behaviour **has** been reported before (#10846, #16056, #44713, #51015, #57100, #72889), but every one of those is closed and locked, and none of them identifies the cause. The closing bot asks to file a new issue, so here it is, with the root cause.
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code
### What's Wrong?
Markdown file links rendered in the chat panel of the **VS Code extension** are styled as links but clicking them does nothing — no open, no reveal, no error. This is an affordance mismatch, and it hits exactly at handoff time, when Claude has just produced a deliverable.
The extension's own system prompt (`## Code References in Text`) instructs Claude to emit file references in precisely this markdown format. The links are dead on arrival.
I dug into the installed bundle. **There are two independent defects, and neither is "link handling is missing".**
**1 — the anchors are never wired to the bridge that already exists.**
The open path is present, complete, and in active use by the file chips and the diff view:
```
webview/index.js openFile(filePath, location)
-> sendRequest({type: "request", requestId, request: {type: "open_file", filePath, location}})
extension.js case "open_file": -> this.openFile(request.filePath, request.location)
```
The host side is thorough: it resolves relative paths against `cwd`, has fallbacks when the file is missing, and calls `revealInExplorer` for directories. Nothing about it is broken. The rendered `` elements simply never call it.
**2 — binary files fail silently even once (1) is fixed.**
The host's `openFile` ends in
```js
vscode.window.showTextDocument(uri).then(cb) // no rejection handler
```
`showTextDocument` rejects for non-text files. With no `onRejected` and no `.catch`, the rejection is unhandled and the user sees nothing at all. So a link to a `.png` or `.pdf` stays dead even after the anchors are wired up.
### What Should Happen?
Clicking a file link should open the file — text in the editor, binary in its own viewer (image preview, PDF) — and a directory should reveal in the Explorer. Line anchors (`file.md#L42`, `#L42-L51`) should map to the `location` argument the host already accepts.
### Error Messages/Logs
None. The click is a silent no-op. Defect 2 produces an unhandled promise rejection from `showTextDocument` inside the extension host; nothing surfaces to the user.
### Steps to Reproduce
1. Ask Claude to create two files in a subfolder, e.g. `docs/note.md` and `docs/chart.png`.
2. Claude replies with `[note.md](docs/note.md)` and `[chart.png](docs/chart.png)` — the format its system prompt mandates.
3. Click either link in the chat panel. Nothing happens.
4. Same result with absolute paths, `file:///` URLs and directory paths (previously reported in #51015).
### Claude Model
Opus 5
### Is this a regression?
Yes, and a recurring one. #10846 was reported fixed in v2.1.4; broken again by v2.1.92 (#44713); again in 2.1.132 (#57100); still broken in **2.1.263**.
### Last Working Version
2.1.4 (per #10846)
### Claude Code Version
Extension `anthropic.claude-code-2.1.263-linux-x64`, VS Code 1.132.0
### Platform
VS Code extension (chat panel webview)
### Operating System
Debian 13 (trixie), KDE Plasma on X11
### Terminal/Shell
zsh — not relevant here; the defect is in the webview panel, not the CLI.
### Additional Information
**The desktop side is not at fault.** Verified locally before filing: VS Code installed from the native `.deb` (no Flatpak/Snap sandbox), `xdg-open` present, three `xdg-desktop-portal` processes running, an image handler registered for `image/png`. None of that is ever reached.
**Suggested fix — both parts are small:**
- *Webview:* on click of an anchor whose `href` carries no URL scheme and is not a `#` fragment, parse an optional `#L` / `#L-L` suffix into `location` and call the existing `openFile()`. External schemes keep their current behaviour.
- *Host:* give `showTextDocument(uri).then(cb)` a rejection handler that falls back to `vscode.commands.executeCommand("vscode.open", uri)`. One argument.
**Workaround** while this is open: a patch script that applies both fixes to the locally installed extension — idempotent, backs up per version, verifies with `node --check` and rolls back automatically on a syntax error, `--revert` to undo. It contains no Anthropic code; it locates the insertion points by pattern. → https://github.com/0nelight/claude-code-vscode-linkfix
Happy to open a PR against the extension source if that is ever practical.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with webview/index.js and its openFile bridge, then inspect extension.js where the open_file request is handled. Reproduce the chat-panel links using the provided text, binary, directory, and line-anchor examples, and compare them with file-chip and diff-view behavior. Done means links open text and binary files, directories are revealed, line ranges are passed through, and failures are surfaced rather than silently rejected.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, vscode
- Domain
- desktop-dev, devtools
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 68/100