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

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