Make links clickable in Windows Companion chat

[samanthamsong]

Problem URLs and Markdown links displayed in Windows Companion chat are rendered as text rather than clickable links. Users must manually copy and paste URLs into a browser, which makes documentation, issue references, tool output, and assistant responses harder to use. ## Expected behavior - Plain URLs such as https://example.com are detected and rendered as clickable links. - Markdown links such as [Example](https://example.com) are rendered with clickable link text. - Activating a link opens it using the user's default browser. - Link text remains selectable and supports normal keyboard navigation and accessibility behavior. - Unsupported or malformed URI schemes are not launched. ## Acceptance criteria - Links are clickable in assistant and user messages. - Links remain clickable in bulleted lists, tables, and other supported Markdown content. - Mouse, keyboard, and screen-reader activation are supported. - Tests cover plain URLs, Markdown links, malformed links, and unsafe URI schemes.

Screenshot

The authorization URL is rendered as plain text and cannot be activated directly from chat. The one-time code has been redacted.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 15, 2026, 4:52 PM ET / 20:52 UTC.

Summary
The requested interaction remains absent from current main and v2026.9.4. Keep this collaborator-authored request open: clickable links would replace an intentional, tested navigation-safety policy.

Reproducibility: yes. source establishes the reported behavior: assistant links lose navigation targets and user messages use plain text. The screenshot corroborates presentation; no runtime activation test was executed.

Maintainer decision needed

Question	Recommendation
Should native chat replace inert links with user-activated HTTP(S) navigation, and what destination disclosure should precede opening the browser?	Approve guarded web navigation: Allow explicit HTTP(S) activation with inspectable destinations and accessible controls while retaining HTML and remote-image protections.

Why: Current source, tests, and merged Markdown work intentionally suppress navigation from untrusted chat content; changing that contract requires an explicit owner decision.

Next step
Obtain approval for the navigation boundary before implementation; this collaborator-authored feature is not an automatic bug-repair candidate.

Security
Needs attention: The request changes a deliberate boundary between untrusted chat text and external browser navigation.

Review details

Best possible solution:

Provide explicitly activated HTTP(S) links through a shared validation and launch policy, with inspectable destinations, accessible interaction, preserved selection, and no automatic navigation or remote-image fetching.

Do we have a high-confidence way to reproduce the issue?

Yes, source establishes the reported behavior: assistant links lose navigation targets and user messages use plain text. The screenshot corroborates presentation; no runtime activation test was executed.

Is this the best way to solve the issue?

The direction is reasonable, but removing sanitization wholesale would be unsafe; a focused activation policy should preserve the existing image and HTML protections.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Scheme filtering alone does not address misleading link labels in untrusted assistant or tool content; the destination-disclosure and activation policy remains undecided.

Codex review notes: model internal, reasoning medium; reviewed against 3c43751b2bac.

Label changes

Label changes:

• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• remove issue-rating: 🌊 off-meta tidepool: Current issue advisory state no longer selects this label.

Label justifications:

• P2: Copying addresses into a browser remains possible, so this is a bounded chat usability improvement rather than a blocked first-use path.
• impact:ux-friction: Users must manually copy chat URLs to follow documentation and authorization links.

Evidence reviewed

Security concerns:

• [medium] Define safe activation of untrusted destinations — src/OpenClaw.Tray.WinUI/Chat/ChatMarkdownSanitizer.cs:23
  The existing sanitizer explicitly prevents trusted-looking assistant links from launching destinations; the replacement needs scheme validation and destination disclosure without restoring automatic fetching.
  Confidence: 0.98

What I checked:

• Current production navigation boundary: Assistant rendering calls BuildSafeMarkdown; its link callback discards the destination and returns a layout container, while Markdown input passes through the sanitizer. User bubbles render selectable plain text at lines 396–401. (src/OpenClaw.Tray.WinUI/Chat/ReactorChatTimeline.cs:560, 3c43751b2bac)
• Intentional safety contract: The sanitizer documents that gateway, tool, and model text is untrusted and deliberately flattens links to prevent trusted-looking navigation. ReactorChatMarkdownContractTests explicitly requires the inert link callback, sanitizer, image suppression, and NoHtml flag. (tests/OpenClaw.Tray.Tests/ReactorChatMarkdownContractTests.cs:24, 3c43751b2bac)
• Merged work preserved inert links: fix(chat): render Markdown tables #1260 (fix(chat): render Markdown tables) is merged and explicitly preserves inert link/image callbacks. It adds table rendering, not clickable navigation. (4ae1c366afca)
• Latest release matches inspected source: The latest published release is v2026.9.4; its annotated tag resolves to the inspected checkout and supplied main revision, so the missing interaction also remains in that release. (3c43751b2bac)
• Reporter screenshot inspected: The prepared proof-image-1.png shows a GitHub device-authorization address displayed as ordinary assistant text. It supports the presentation complaint; a still image alone does not demonstrate activation or keyboard behavior.
• Canonical search: GitHub searches for chat links and clickable/hyperlink behavior found this request and adjacent Markdown, selection, and wizard work, but no verified replacement implementing its acceptance criteria.

Likely related people:

• shanselman: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• karkarl: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.