fix(web): keep windows drive paths clickable in chat markdown

[CDVolvik]

A markdown link whose destination is an absolute Windows path renders as styled text with nothing behind it (#6418).

What changed

Both chat render paths drop the destination before the anchor can use it:

• Assistant messages leave parseRawHtml at its default of true, so rehype-sanitize runs, reads D: as an unknown protocol, and removes the href — before urlTransform is reached.
• User messages pass false, skip the sanitizer, and React Markdown's defaultUrlTransform blanks the same destination for the same reason.

Either way the anchor arrives without an href, so it cannot match an entry in markdownFileLinkMetaByHref even though that map has already resolved the path from the raw message text.

Both pipelines run remark, so the destination is normalized there: toFilesystemLinkUrl maps a drive path to the file: URL the sanitize schema already allows, and the existing rewriteMarkdownFileUriHref maps it back on the way out. resolveMarkdownFileLinkTarget already handled these paths, so this is only about getting them that far.

Two smaller pieces come with it:

• Link keys go through the same function, so M:\dir\file.md in the source and the M:/dir/file.md the renderer receives resolve to one key rather than missing each other on the separator.
• The anchor resolves a drive destination itself when the metadata map misses. That map is built by scanning the message text for inline links with a plain destination, so balanced parentheses, nested brackets and bracketed destinations with spaces are absent from it; without the fallback those would render as ordinary anchors pointing at a drive path with no file action.

CHAT_MARKDOWN_SANITIZE_SCHEMA is exported so the tests can render both pipelines with the real configuration; that needs an explicit type annotation because its inferred type is not nameable outside the module.

Before / after

Rendered from the real ChatMarkdown component with the app's built stylesheet. "Before" is the same component with this PR's source hunks reverted to origin/main. The file-type glyph inside the chip is a runtime SVG sprite the offline render does not load, so it shows as blank space.

Emitted markup for See [Open](D:/tmp/example.md) for the notes.:

pipeline	before	after
assistant (parseRawHtml: true)	<a target="_blank" rel="noopener noreferrer">Open</a>	<a href="D:/tmp/example.md" class="… chat-markdown-file-link">… example.md</a>
user (parseRawHtml: false)	<a href="" target="_blank" rel="noopener noreferrer">Open</a>	same as above

Scope

Markdown destinations only. A bare M:\dir\file.md written as plain text is still not linked, because GFM does not autolink filesystem paths and adding that is a separate change. If you read #6418 to include the bare-path case, this does not close it outright.

Testing

• apps/web unit project: 2574 tests across 262 files pass
• 63 tests in the three touched files, including new tests that render both pipelines through renderToStaticMarkup with the real sanitize schema, and that assert an unsafe scheme is still dropped
• tsgo --noEmit clean; vp lint 0 warnings / 0 errors on the changed files; vp fmt --check clean
• Rebased on origin/main @ 4cb676cc1

---

Note

Low Risk
Localized markdown rendering and URL handling for Windows drive paths; unsafe schemes remain rejected and behavior is covered by pipeline tests for both assistant and user render modes.

Overview
Fixes #6418: markdown links like [Open](D:/tmp/example.md) used to render without a usable href because D: was treated as an unknown protocol—assistant messages lost it in rehype-sanitize, and user messages got a blank href from defaultUrlTransform.

A new remarkFilesystemLinkDestinations plugin runs on both chat pipelines and rewrites drive (and reference-definition) destinations to allowed file: URLs; existing rewriteMarkdownFileUriHref still turns them back into plain paths on output. toFilesystemLinkUrl centralizes that mapping and normalizes \ vs / so metadata keys match what the renderer sees.

ChatMarkdown wires the plugin in, keys link metadata through the same helper, and falls back to resolveMarkdownFileLinkMeta at render time when the message-text regex scan missed the destination (parentheses, spaced <...> paths, etc.). CHAT_MARKDOWN_SANITIZE_SCHEMA is exported (with an explicit type) so tests can mirror both parseRawHtml paths; new unit tests assert drive links work, javascript: stays dropped, and https links are unchanged.

Scope: markdown link destinations only—not autolinking bare paths in plain text.

^{Reviewed by Cursor Bugbot for commit 7ddc786. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix Windows drive paths to remain clickable as file links in chat markdown

• Adds a new remark plugin, remarkFilesystemLinkDestinations in markdown-filesystem-links.ts, that rewrites Windows drive-style link destinations (e.g. D:/path/file.md, backslash variants) to file:/// URLs before sanitization strips them.
• Adds toFilesystemLinkUrl in markdown-links.ts to convert Windows drive paths to file: URLs and normalize path separators.
• Updates normalizeMarkdownLinkHrefKey in ChatMarkdown.tsx to key drive destinations via their file: form so lookups into the pre-scanned metadata map succeed for both slash and backslash variants.
• The anchor renderer in ChatMarkdown now falls back to resolving file link metadata on the fly when the pre-scan misses a link shape.

^{Macroscope summarized 7ddc786.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 4979ae81-1f0c-4a33-8472-43d2c03c8b13

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved 7ddc786

Straightforward bug fix that makes Windows drive paths clickable in chat markdown by rewriting them to file: URLs before sanitization. The fix is well-scoped to the markdown rendering pipeline with comprehensive tests including security verification that unsafe schemes remain blocked.

^{You can customize Macroscope's approvability policy. Learn more.}

[thelonewander3r]

Confirming this on Windows against a real thread, and this branch fixes it cleanly.

Repro (T3 Code 0.0.33, Windows 11)

An agent listed the files it had just created. The stored message text is a normal markdown list, percent-encoded because the paths contain spaces (names below are placeholders; the spaces, the & and the percent-encoding are verbatim):

- [Notes - August 2026.md](C:/Users/me/docs/20%20Projects/Alpha%20%26%20Beta/Notes%20-%20August%202026.md)
- [IMG_0001.jpg](C:/Users/me/docs/20%20Projects/Alpha%20%26%20Beta/media/IMG_0001.jpg)

Every link renders blue and underlined, and clicking one does not open the file panel.

Tracing 0.0.33's bundle matches your description exactly: rehype-sanitize reads C: as an unknown protocol and strips the href before urlTransform runs, and on the parseRawHtml: false path defaultUrlTransform returns "" for the same reason. resolveMarkdownFileLinkTarget handles these paths fine — the anchor just never receives a destination to key off, so markdownFileLinkMetaByHref is never consulted even though it already holds the resolved entry.

Verified against 7ddc786

I re-ran the gates shipped in 0.0.33 (hast-util-sanitize@5.0.2 safeProtocol, react-markdown@10.1.0 defaultUrlTransform) with and without this branch's toFilesystemLinkUrl plus the anchor fallback:

destination	main	this PR
C:/…/Alpha%20%26%20Beta/Notes%20-%20August%202026.md	dead, href=""	file chip
<C:/Users/x/My File.md>	dead, href=""	file chip
C:\Users\x\file.md	dead, href=""	file chip
C:/src/main.ts:42	dead, href=""	file chip
</Users/x/My File.md>	dead link	dead link
/Users/x/File.md	file chip	file chip

The percent-decoding and the & both survive the round trip into the resolved target.

Two notes

1. The fallback covers more than the description claims. Because the anchor re-resolves when the text scan misses, bracketed destinations containing spaces also start working — on Windows drive paths that is the Windows half of #5158, which currently reads as untouched by this PR. Worth stating explicitly so it is clear what is left: the POSIX half (</Users/x/My File.md>) still renders dead, so #5158 should stay open after this lands.

2. The fallback gate is drive-only. It is conditioned on toFilesystemLinkUrl(normalizedHref), which tests WINDOWS_DRIVE_PATH_PATTERN but not WINDOWS_UNC_PATH_PATTERN. So a UNC destination the text scan cannot read skips the fallback, even though resolveMarkdownFileLinkTarget already resolves UNC paths. Deliberate scope call, or worth widening that gate?

Neither blocks it. Rewriting at the syntax tree so both pipelines are covered by one change is the right shape here, versus patching the sanitizer and urlTransform separately.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing in favor of merged #8081, which fixes Windows drive-path file links in chat without weakening Markdown URL sanitization. Your work is credited in #8081.