chat: linkified paths in replies fail on click — ~ home paths not expanded, non-file text linkified as file reference #51872

Summary

In the desktop client, path-like text in agent replies (table cells, markdown link syntax) is rendered as clickable blue links. Clicking them is inconsistent: absolute paths open fine (including non-ASCII/Chinese directories), but home-relative ~ paths fail with "File not found", and non-file @ text (e.g. a skill-store coordinate) is linkified as a file reference and also fails.

The linkification heuristic and the click resolver disagree: the UI offers a click affordance for text it cannot resolve on click.

Environment

• opencode version: CLI v2.0.15, background service /api/info reports 2.0.18 (mismatch)
• OS: Windows_NT 10.0.26200 (Win32NT x64)
• Terminal: desktop client; TERM=xterm-256color
• Shell: C:\Windows\system32\cmd.exe
• Install/channel: release (latest)
• Active plugins: none found in config

Reproduction

Text of this form appears in an agent reply (table cell or markdown link):

1. C:\temp\preview-link-test.png — absolute, ASCII → click opens the file ✅
2. E:\下载\stitched-grid-5.png — absolute, Chinese path → click opens ✅
3. ~/.skillhub/ — home-relative → click fails with "File not found"
4. @user_c3d829cb/img-stitch — skill-store coordinate (not a file) → click fails with "File not found"

Expected Behavior

• Either: only linkify text the resolver can actually open (case 3 should resolve by expanding ~ to the user home, as permission rules do for read/external_directory resources), or: clicking an unresolvable path shows a non-error affordance / is not linkified at all (case 4).
• Home expansion for ~ in click resolution is documented behavior elsewhere in V2 config ("OpenCode expands ~ and $HOME" for read/edit resources), so the chat click resolver is inconsistent with it.

Actual Behavior

• Cases 1–2 open correctly; backslash and non-ASCII paths are handled fine.
• Case 3: ~ is not expanded — resolved as a workspace-relative path → "File not found".
• Case 4: @<something>/<something> is linkified as if it were a file reference → "File not found", even though it is a store coordinate, not a path.

Additional Context

• Linkified contexts observed: table cells and explicit markdown link syntax [text](path). Plain body text and code blocks are NOT linkified — the heuristic is context-dependent and undocumented.
• Related: [FEATURE]: Desktop: Clickable file paths in chat to open/reveal in Explorer #17209 (feature request for clickable file paths — states paths were plain text by default), [FEATURE]:[Web]: Clickable file:line references in messages (jump to file and line) #13430 (clickable file:line refs in Web UI). Those request the feature; this reports inconsistent behavior of the linkification that already exists.
• No official docs define how paths in replies should be written or how clicks resolve them (checked References / Attachments / Agents pages).