VSCode extension: clickable-styled file links in chat do nothing on click
Environment
- Extension:
anthropic.claude-code-2.1.114-darwin-arm64 - VSCode on macOS (Darwin 25.2.0)
Behavior
Markdown file links that Claude emits in the chat panel — e.g. [filename.mp4](projects/path/filename.mp4) — render with link styling (color/underline) but clicking them has no effect. Both plain click and Cmd+Click do nothing.
Tried formats:
- Workspace-relative:
[name](projects/briefs/.../file.mp4)— no response - Absolute
file://URL:[name](file:///Users/.../file.mp4)— no response - Directory paths (for reveal-in-Finder):
[name](file:///Users/.../dir/)— no response
All click/Cmd+Click attempts silently no-op.
Expected
Clicking a file link should route to VSCode's file-open handler (open in editor if text, reveal in OS handler if binary). The extension's own system-prompt guidance (## Code References in Text block) explicitly instructs Claude to use this markdown link format for file references — but those links are dead on arrival.
Workaround
Asking Claude to open -R <path> via Bash after saving binary outputs reveals the file in Finder. This shouldn't be necessary for every deliverable.
Impact
Every file reference Claude generates per the documented convention is non-functional. Significant friction for any workflow producing file outputs (screenshots, renders, reports).
3 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is a control-surface trust problem more than a mere convenience issue. The extension is actively teaching Claude to emit markdown file links in a particular format, those links render with visual affordances that strongly imply clickability, and then the UI does nothing when clicked.
That means the product is presenting a dead affordance as a live one.
From the user perspective, this is especially frustrating because it affects exactly the handoff moment when Claude has produced a deliverable and the human wants to inspect it quickly. If the link looks actionable but silently no-ops, the operator has to fall back to manual shell commands or path hunting.
So there are two mismatches here:
When those diverge, users stop trusting both the assistant formatting guidance and the extension surface around it.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.