Repository navigation
Description
Description
In the desktop app, a local path in a chat message becomes a clickable link only if it passes an existence check, but the check matches files only. Directories and paths containing spaces are never linkified, and a manually written markdown link to a directory renders as a link but fails on click with a "File not found" error toast.
Verified in desktop 2.0.29 (renderer bundles inside app.asar):
- The file service
exists()implementation lists the parent directory and accepts only entries wheretype === "file"and the basename matches. Directories come back astype: "directory"fromGET /api/fs/list, so a folder can never be linkified. - The inline-code path classifier rejects any candidate containing whitespace, so a file path like
C:\Program Files\app\file.txtis never linkified either — while the markdown-link route (file://URL) has no whitespace check and links the same path fine. - Clicking a link to a directory runs the file-read flow, which returns
404 FileNotFoundErrorfor directories, producing the error toast "Failed to load file / File not found: ".
The main process already exposes shell.openPath and showItemInFolder (wired to the Review panel file tree), so opening/revealing a directory is feasible — it just isn't wired into the chat-link open flow.
Suggested fixes:
- Allow whitespace in the inline-code path classifier (the span boundary is already delimited by the markdown backticks).
- Accept
type === "directory"inexists()(folder icons already exist in the tree renderer). - In the link open flow, fall back to a parent-directory listing on read 404: open/reveal directories via the existing bridge instead of toasting an error.
Plugins
none
OpenCode version
2.0.29 (desktop app; standalone CLI 2.0.15)
Steps to reproduce
- Desktop app, any session.
- Have the agent output an existing folder path in inline code, e.g.
C:\Users\foo\folder. - Observe: it renders as plain code, not a link.
- Have it output an existing file path containing spaces, e.g.
C:\Program Files\app\file.txt— also not a link. - Have it output the folder as a markdown link instead:
[folder](file:///C:/Users/foo/folder)— it renders as a link. - Click it → error toast: "Failed to load file / File not found: folder".
Screenshot and/or share link
n/a — repro is deterministic text; the error toast reads "Failed to load file / File not found: folder".
Operating System
Windows 11 (10.0.26200)
Terminal
n/a (desktop app)
Activity
opencode-agent commentedon Oct 15, 2026
Thanks for the detailed report. I reproduced all three problems on 2.0.29, and they still happen on the latest
dev(a448d5b).I couldn't run the desktop app here, so I ran the code it relies on against a real
opencode serve:/api/fs/listreturns a folder astype: "directory". The desktop'sexists()check accepts onlytype === "file", so it answers false and the folder never becomes a link./…/my folder/file.txtandC:\Program Files\app\file.txt. That's because of its whitespace check, even though the existence check would find the file.GET /api/fs/read/<folder>returns404 FileNotFoundError("File not found: "), which is the text of the toast you saw.The script below reproduces this. Related issues about desktop path links: #50390, #51872, #54540, #51516, and #37891, which asks for clickable paths that open or reveal.
Reproduction script (repro.ts)
Run it:
bun repro.tsFinn763 commentedon Oct 19, 2026
I'd like to work on this — the file-link existence check only accepts files and the inline-code classifier rejects whitespace, so directories and paths with spaces never linkify. I'll fix both and cover them with tests.