[BUG] Windows absolute paths in markdown links: false affordance (renders clickable, click does nothing)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Continuing from Issue 10846
Regression report — Windows absolute paths in markdown links: false affordance (renders clickable, click does nothing)
Reproducing on the current Claude Code VSCode extension on Windows 11.
Two distinct failure modes observed:
- [file.cs](relative/workspace/path.cs)
→ Clickable, opens file correctly ✅
c:\absolute\windows\path.md(code span)
→ Not rendered as a link — acceptable
- [text](c:\absolute\windows\path.md) (markdown link syntax)
→ Renders blue with hover cursor change, but click performs NO ACTION
The third case is the problem — the link has the full visual affordance of an
interactive element but silently does nothing on click. No error, no file picker,
no navigation. Observed on links generated by Claude pointing to files outside
the workspace root (e.g. c:\Code\.agent\output\).
Relative workspace-root paths work correctly, so the issue is specific to
absolute Windows paths in markdown link syntax.
Environment:
- OS: Windows 11 Pro
- Shell: bash (Git Bash)
- Extension: Claude Code VSCode extension (current version)
Previously tracked as a duplicate in #27672. Noting here as the root issue since
the false-affordance case (looks interactive, does nothing) is the most
user-confusing variant — worse UX than simply not rendering a link at all.
What Should Happen?
Links produced in the output should function if presented as functional.
Error Messages/Logs
Steps to Reproduce
- Create an output to the VS Code Claude extension with three links:
[file.cs](relative/workspace/path.cs)
→ Clickable, opens file correctly ✅
c:\absolute\windows\path.md(code span)
→ Not rendered as a link — acceptable
[text](c:\absolute\windows\path.md) (markdown link syntax)
→ Renders blue with hover cursor change, but click performs NO ACTION
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.81 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
VS Code integrated terminal
Additional Information
_No response_
6 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Existing issues are either closed or different.
+1 — Same issue on Ubuntu Linux with CJK (Traditional Chinese) filenames. Markdown file links with non-ASCII characters render as clickable but do nothing when clicked. ASCII-only filenames work fine.
This appears to be part of a broader cross-platform issue affecting all non-ASCII file paths in the VS Code extension chat panel. See also: #16056, #25426, #10846, #48892.
Up
When clicking a file link in the chat panel, text files open correctly but binary files (PDF, PNG, and similar) do nothing. Relative paths work for the text formats; absolute paths do not open at all. From the outside this looks like the click handler only ever opens the target as a text document, so anything that is not text silently fails, and absolute paths (which may contain spaces or need encoding) are not resolved.
It would be a real improvement if clicking any file link tried to open the file the way VS Code itself would: in an installed viewer if one is registered (for example a PDF preview), otherwise handing it off to the operating system's default application.
The VS Code extension API already exposes the pieces for this. The built-in vscode.open command is documented to open a resource Uri that can be a text or a binary file, and vscode.env.openExternal hands a Uri to the OS default handler as a fallback. Building the Uri with vscode.Uri.file(path) also takes care of encoding paths with spaces, which would likely fix the absolute-path case as well.
Can confirm this reproduces on Windows 11 / VS Code as well, with a variant worth noting: it also happens for the global ~/.claude/CLAUDE.md config file.
Tried two forms in the chat pane, neither worked:
C:\Users\<me>\.claude\CLAUDE.mdfile:///C:/Users/<me>/.claude/CLAUDE.mdBoth rendered as clickable (blue text, hand cursor) but did nothing on click. For comparison, pasting the same file:// URI directly into the contents of an open file and clicking it there worked fine — that's VS Code's own built-in link detection, not the extension, which suggests the chat pane's link handler specifically only wires up workspace-relative paths and silently no-ops on anything else, including file:// URIs.