fix(desktop): make file:// chat links clickable

[tauseefkhan-max]

Issue for this PR

Closes#37891

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

In the desktop app, file:// links and absolute paths in chat looked clickable but did nothing.

Two causes:

1. DOMPurify dropped file: hrefs (default URI allowlist is web-only).
2. The desktop click handler always called shell.openExternal via open-link, which is the wrong path for local files (and fix(desktop): restrict external links #38914 is tightening that further to http(s)-only).

This PR:

• Allows file: through the sanitizer only on desktop (oc:// renderer / desktop API present). Web is unchanged.
• On click: file:// and absolute-path hrefs go through existing openPath / revealPath IPC (already used by the session header). Modifier-click (⌘/Ctrl/Alt) reveals in Finder/Explorer; plain click opens with the OS default app.
• Hardens open-link to http(s) only so local paths never hit openExternal.
• Turns absolute path chips in assistant markdown into file:// links on desktop.

Workspace-relative path chips and opening in the built-in editor tab are out of scope here.

How did you verify your code works?

cd packages/desktop && bun test src/main/external-link.test.ts src/renderer/file-link.test.ts
cd packages/session-ui && bun test src/components/markdown-desktop.test.ts

All 15 tests pass. Unit coverage includes URI parsing (unix/windows/file:/line:col suffixes), safeExternalUrl rejection of non-http(s), and desktop path→href conversion.

Screenshots / recordings

N/A — behavior change on click; no visual layout change beyond links remaining present after sanitize (they were stripped before).

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Related PRs Found:

1. PR #38645: feat(tui): make file paths in read/grep/glob tool output clickable

   • Related because it addresses making file paths clickable in tool output (TUI implementation), while PR fix(desktop): make file:// chat links clickable #39206 does the same for desktop chat links

2. PR #36862: fix(desktop): validate openExternal URLs by protocol

   • Related because it also hardens URL handling in desktop by validating protocols before calling openExternal, similar to the hardening approach in PR fix(desktop): make file:// chat links clickable #39206 (http(s) only validation mentioned in the summary)

These are complementary improvements rather than duplicates—one covers TUI file path clickability while the other validates URL protocols on desktop.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[100kristine]

this would be amazing, hope it can ship soon! one of the biggest problems with the desktop app rn

[wulinsekai]

+1 for this — exactly the gap we're hitting on a daily basis. Our agents produce a lot of file:// links in handover docs and PR summaries, and on desktop they currently render as chips that do nothing on click, so I fall back to copy-paste or open -R.

Two quick notes:

1. The DOMPurify allowlist + shell.openExternal analysis matches what I see: local files should never go through the external-browser path. Scoping the file: allow to desktop only (as this PR does) is the right call.
2. Once this lands, the TUI side is covered by feat(tui): make file paths in read/grep/glob tool output clickable #38645, so the whole surface area (desktop + TUI + web) would have a consistent answer. Would it make sense to also handle the web renderer in a follow-up?

Happy to test the desktop build once it's merged.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.