Windows local-file Markdown links fail on Ctrl+click when the assistant emits drive-letter paths

Start with the structural Markdown renderer and the CLI openLink helper, then reproduce the drive-letter link in a local Windows Terminal session while capturing the emitted hyperlink target. Compare Ctrl+click and Ctrl+X then O for Windows paths and file URIs, including the listed special characters and path forms. Done means supported local files open reliably without weakening protocol or hostname restrictions, with regression coverage for the reproduced cases.

Describe the bug

Environment

• GitHub Copilot CLI 1.0.84-6, Windows x64
• Windows Terminal 1.24.260710001
• PowerShell 7.6.6
• Windows build 26200.9448 / 25H2
• Local Windows Terminal session; WT_SESSION is present

Problem
Copilot creates an existing local HTML report and returns a Markdown link targeting an absolute Windows filesystem path. Ctrl+click does not open the report. The user has encountered this repeatedly.

Reproduction

1. Create C:\Temp\copilot-link-repro\report.html.
2. Have Copilot render this exact Markdown:
   Open report
3. Ctrl+click "Open report".
4. Compare these controls:
   Open report
   HTTPS control
5. Also compare Ctrl+X, then O ("open most recent link").

Expected
Assistant-generated local-file links open the existing file using its default application. Supported Windows paths are converted to properly escaped file URIs before rendering and opening.

Actual
The reported drive-letter link does not open the file. File existence was verified. The exact terminal click payload/error was not captured.

Diagnostic evidence

• The installed structural Markdown renderer passes the parsed href directly:
  link: { url: r.href, id: d5(r.href) }
• d5 computes a link ID, not path normalization.
• The CLI openLink helper allows http:, https:, and local file: URLs.
• URL parsing treats C:... as protocol "c:", not "file:".
• An isolated test of the installed opener, with a stub launcher, showed:
  C:... -> rejected; launcher not called
  file:///C:/... -> accepted; launcher called
  https://example.com -> accepted; launcher called

Qualification
This confirms a Windows path/URI handling gap. It does not establish that Ctrl+click invokes the CLI opener; Windows Terminal can dispatch OSC 8 hyperlinks itself. Capture the emitted hyperlink target and compare the controls to locate the click-specific failure.

Suggested fix
Emit canonical file URIs for local artifacts and normalize supported Windows absolute paths before rendering/opening. Preserve protocol and hostname restrictions rather than allowing arbitrary schemes. Surface an actionable error instead of silent failure.

Regression coverage
Test Ctrl+click and Ctrl+X then O with drive-letter paths, canonical file URIs, .copilot-style directories, spaces, parentheses, #, %, Unicode, and long/wrapped labels.

In another session I got a link and asked:

What is the exact format of the link you just gave me? c:... or file:////c:/ ?

It was a Windows path in a Markdown link:

the link.md

try it again with file:// type lin

< new link that works >

Affected version

GitHub Copilot CLI 1.0.86-0

Steps to reproduce the behavior

See above.

Expected behavior

Clickable link

Additional context

No response