Bare URL autolinker includes trailing Markdown asterisks in link target

[yxlyx]

Summary

Bare URLs wrapped in Markdown bold markers can be parsed with the closing ** included in the URL. On macOS, Cmd-hover then underlines the trailing asterisks as part of the link and attempts to open an invalid target such as http://localhost:3003**.

Reproduction

Render or linkify this assistant response:

**http://localhost:3003**

The lower-level parser reproduces it directly:

cd gui
bun -e 'import { getChatLinkMatches } from "./src/components/chat/utils/chatLinks.ts"; console.log(getChatLinkMatches("**http://localhost:3003**"))'

Current result:

[{"kind":"url","start":2,"end":25,"value":"http://localhost:3003**"}]

Expected

The clickable target and underlined span should end at http://localhost:3003; Markdown delimiters must remain outside the URL.

Actual

The URL value includes the closing **, so Cmd-click/Cmd-hover treats the asterisks as part of the destination and the link cannot be opened correctly.

Likely cause

gui/src/components/chat/utils/chatLinks.ts uses:

const URL_PATTERN = /https?:\/\/[^\s"'`<>]+/giu;

* is accepted by that pattern, while trimLinkCandidate() removes punctuation and unmatched closing brackets but not Markdown emphasis delimiters. Markdown-rendered messages may normally split strong spans first, but raw/plain-text paths using ChatInlineText / getInlineTextSegments pass the markers directly to this matcher.

Suggested regression coverage

Add a getChatLinkMatches or rendered-component test covering URLs adjacent to Markdown delimiters, including:

• **http://localhost:3003**
• *https://example.com*
• ~~https://example.com~~

The matcher should preserve legitimate URL characters while excluding surrounding Markdown syntax.

[justrach]

@yxlyx Fixed and merged via #210 into release/v0.0.210 at d8200ca.

The PR was rebased onto the latest release branch, which pins Linux, Windows, and release workflows to our exact Zig 0.17.0-dev.813+2153f8143 toolchain. Validation is green:

• post-merge GitHub SDK, Zig, and Windows jobs
• 300/300 local Zig tests
• 19/19 JSON live-control cases
• 157/157 Bun tests
• targeted ESLint and GUI TypeScript checking

The matcher now removes only matching Markdown delimiters and preserves legitimate trailing * / ~ URL characters.

[yxlyx]

This is still being observed by a user after the fix in #210 (exact installed version not yet known):

• When an assistant response contains a localhost URL surrounded by bold Markdown, for example `http://localhost:3003**\`, holding Cmd and hovering underlines the trailing `` together with the URL.
• Cmd-click then does not open/redirect to the localhost page because the Markdown delimiters appear to be part of the clickable target.
• The visible `...` also appears not to render as bold in this path.

This suggests either a regression or another rendering/linkification path that is not covered by the original fix. Please verify both the displayed Markdown rendering and the final href/click target in the actual assistant-message component, not only `getChatLinkMatches()` in isolation.

[justrach]

Status check: the originally reported defect is fixed and verified — running this issue's own repro on main: getChatLinkMatches("**http://localhost:3003**") → {"value":"http://localhost:3003","start":2,"end":23} (delimiters excluded; #210 via b0b25c8, plus bb623af preserving legitimate trailing */~). On the follow-up claim of a second path: getChatLinkMatches has exactly one caller (inlineText.ts:11) feeding MarkdownRenderer, which parses strong before linkifying (MarkdownRenderer.tsx:141-148), and the TUI strips ** too (repl_util.zig:38-43) — we could not reproduce a path where ** renders literally and gets linkified. If you're still seeing it, the exact graff --version and whether it was the GUI or terminal would settle it; otherwise this looks closable.