desktop: clicking a message link opens it as a local file instead of the browser #53013

Activity

1. github-actions

   assigned

   Brendonovich

   on Oct 3, 2026
2. github-actions commented on Oct 3, 2026

   

   github-actionsBot

   on Oct 3, 2026 – with GitHub Actions

   Contributor

   More actions

   ---

   This issue might be a duplicate of an existing issue. Please check:

   • #52255: Reports desktop chat links failing to open after a click (in 1.18.33); this issue describes them being routed to the file viewer instead.
3. opencodejr commented on Oct 27, 2026

   

   opencodejrBot

   on Oct 27, 2026

   Contributor

   More actions

   Thanks for the detailed report. I couldn't reproduce this here because it needs the Windows desktop app, and I only have a Linux environment without it, so a maintainer with Windows will need to check it.

   From reading the code (I haven't run it):

   • Links without a scheme (e.g. discord.com/developers/applications shown as inline code): in 2.0.22, any inline code containing a / is treated as a file path and opened in the file viewer without checking that the file exists. That explains the File not found toast. Newer code only makes such text clickable once the file is confirmed to exist, so this part may already be fixed in a later release.
   • https:// links: going by the code, these should be handed to your default browser. I couldn't find what produces UnexpectedStatus: 500, so a maintainer needs to look at this part on Windows.

   These would help:

   • Does the https:// failure still happen with opencode-dcp and opencode-v2-token-usage disabled?
   • Was the URL shown as a normal link, or as inline code (monospace)?
   • Does it still happen on the latest desktop release?
4. KoBadger commented on Nov 11, 2026

   

   KoBadger

   on Nov 11, 2026

   Author

   More actions

   Updating with where this landed.

   Environment now: desktop v2.2.7 (this was filed against v2.0.22).

   Since the report, the two symptoms in it map onto two changes:

   • File not found: <text> — feat(session-ui): deterministic timeline file link detection and resolution #53641 ("deterministic timeline file link detection and resolution", merged 2026-10-09) rewrote how file links in messages are detected and opened. In 2.0.22 any inline code containing a / was treated as a path and sent to the file viewer unconditionally; the newer code only makes such text openable once the path is confirmed to exist.
   • UnexpectedStatus: 500 — /api/fs/read no longer answers 500 for a path that does not exist or resolves outside the project; since 2.1.0 it returns a not-found. That is the same failure described in desktop: opening URL-style path resolves to C:\static, /api/fs/read returns 500 (UnexpectedStatus) #50913, which was closed for exactly this change.

   Both paths from the original report are covered by those, so I am closing this as resolved upstream. If a link still opens in the file viewer on a current build, comment here and I will reopen with the link, whether it rendered as inline code or as a normal link, and the matching log line.

   On the plugin question: opencode-dcp and opencode-v2-token-usage do not touch click routing, so I would not expect disabling them to change anything.
5. KoBadger

   closed this as completedon Nov 11, 2026