[BUG] VSCode extension: markdown heading-anchor links (file.md#section) do nothing when clicked in the chat panel

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest is #41112 — a different failure mode; see Related)
• [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?

In the Claude Code VS Code extension chat panel, a markdown link whose href is a section/heading anchor — [text](file.md#some-heading) — does nothing when clicked. No file opens, no navigation, no error. The link renders with full affordance (colored text, pointer cursor) but the click is a silent no-op.

Same file, same panel, for comparison:

| Link in an assistant message | Result |
|---|---|
| [docs](docs.md) | Opens the file ✅ |
| [docs L42](docs.md#L42) — numeric line fragment | Opens the file at line 42 ✅ |
| [Installation](docs.md#installation) — heading slug | Nothing happens ❌ |

Clicking the identical [...](file.md#heading) link inside a Markdown editor/preview navigates to the heading correctly (VS Code's built-in Markdown support resolves heading slugs), so the behavior is inconsistent between the editor and Claude's panel.

This is not "file links don't work." Plain file links open fine here — including relative links (first row above) and numeric #L line links (second row). The defect is specific to non-numeric heading fragments. (This distinguishes it from reports where a link never opens at all — see Related.)

Root cause as investigated by Claude Opus 4.8 xhigh (from reading the shipped webview/index.js): chat messages are rendered with react-markdown, and the link click handler's file-path parser only recognizes numeric line fragments — its match is effectively path optionally followed by [:#]L?<digits>(-L?<digits>)?. A non-numeric fragment such as #installation fails that match, so the handler classifies the href as "not a file link" and falls through to the default <a target="_blank">, which can't navigate a relative path inside a webview → no-op. Consistent with this, no open_file message is emitted for these links (visible in the "Received message from webview" output-channel logs).

What Should Happen?

Clicking [text](file.md#some-heading) in the chat panel should open the file and scroll to the matching heading — the same as clicking the link in a Markdown editor/preview. If the slug matches no heading, it should fall back to opening the file at the top, so the click at least opens the file instead of doing nothing.

Suggested fix (small; reuses existing machinery): the panel already opens files at a given line (open_file with a line location). So it only needs to (1) stop rejecting non-numeric fragments, and (2) on the extension host, resolve the heading slug to a line in the target file using VS Code's own Markdown heading-slug logic (the slugging behind built-in .md link navigation / document symbols), then open at that line — falling back to line 1.

Error Messages/Logs

N/A — no error; the click is silent. No open_file message appears in the extension's webview-message logs for heading-anchor links.

Steps to Reproduce

1. Open a workspace with a Markdown file, e.g. docs.md, containing a heading such as ## Installation.
2. In the Claude Code VS Code side panel, get the assistant to emit a heading-anchor link — e.g. ask: "Link to the Installation section of docs.md using a markdown heading anchor." → it renders [Installation](docs.md#installation).
3. Click the rendered link in the chat panel. → Nothing happens.
4. For contrast, [docs](docs.md) and [docs](docs.md#L<line>) both open correctly from the same panel.

Related (adjacent, but distinct — not duplicates)

These all concern chat-panel links but fail at a different stage. In each of them the link never opens at all; in this report the file does open and only the heading fragment is ignored.

• #72889 — file references that "look clickable but don't navigate." Its repro uses absolute C:\… paths / bare filenames for files created in subfolders — i.e. the href is destroyed or was never a link (same family as #41112 / #69645). Not the same defect: relative file links and numeric #L links open correctly here; only non-numeric heading fragments fail.
• #41112 — markdown links fail for absolute Windows paths, because the href is stripped by the renderer's URL sanitizer before the click handler runs (a C:\ prefix reads as a URI scheme). Different mechanism from heading fragments, where the href survives sanitizing.
• #69645 — plain-text / backtick file paths aren't clickable at all.
• #23408 — numeric line-number links in the diff view (numeric fragments already work in the panel).

Claude Model

Opus

Is this a regression?

No.

Last Working Version

N/A

Claude Code Version

2.1.198

Platform

Other

Operating System

Windows 11

🤖 Generated by Claude Opus 4.8