Repository navigation
desktop: file links send literal ellipsis (U+2026) to /api/fs/read and 404 #51516
Description
Summary
In the desktop app, clicking a file link whose displayed path is abbreviated with a
home-directory ellipsis (…) sends that abbreviated string verbatim to
GET /api/fs/read/…, so the request 404s. The real file exists and opens fine by its
full path. The ellipsis is U+2026 HORIZONTAL ELLIPSIS (%E2%80%A6), not ~, and the
server does not expand it.
Environment
- opencode version: 2.0.15 (desktop app,
opencode-cli.version); update to 2.0.18 staged - OS: Windows_NT 10.0.26200 (win32 x64), Windows 11
- Terminal: Unavailable — OpenCode desktop app (Electron);
TERM=xterm-256color,TERM_PROGRAMunset - Shell:
C:\WINDOWS\system32\cmd.exe - Install/channel: latest — desktop installer (
@opencodedesktop) - Active plugins: none found in config (only an MCP
playwrightserver configured)
Reproduction
- In a desktop session, have the assistant reference a file that lives under the home
directory but outside the project, for example
C:\Users\<user>\.config\opencode\commands\grill-me.md. - Click the file link in the chat.
- The UI shows
Failed to load file/File not found. - The server log shows the abridged path requested literally.
Expected Behavior
The link opens the real file. Any home-prefix abbreviation or middle-truncation used for
display should be expanded back to the real absolute path before the fs/read request.
Actual Behavior
The request path still contains the display ellipsis:
GET /api/fs/read/%E2%80%A6/config/opencode/commands/grill-me.md -> 404 (x2)
%E2%80%A6 decodes to … (U+2026). The real path
C:\Users\<user>\.config\opencode\commands\grill-me.md exists (2041 bytes) and reads
successfully by full path, so only the link expansion is broken.
The same happens when the chat text itself used a shorthand ellipsis:
GET /api/fs/read/%E2%80%A6/skills/engineering/prototype -> 404 (x3)
Additional Context
- The abbreviation seen in the UI is the home prefix (
C:\Users\<user>\.) collapsed to
…/; the click handler appears to use the rendered text as the path. - Related but distinct: desktop: file links in messages 404 when referenced by basename outside the session root #50876 and desktop: file card in chat 404s with "File not found" for files in subfolders #50881 cover relative / basename links resolving
against$HOME; desktop: opening URL-style path resolves to C:\static, /api/fs/read returns 500 (UnexpectedStatus) #50913 covers a URL-style path resolving toC:\static. This issue is
specifically the literal…surviving into the request URL. - Secondary symptom: the
skilltool's supporting-file sample lists bare relative names
(e.g.SKILL.md); clicking one requestsGET /api/fs/read/SKILL.md-> 404, because the
client has no base directory for the skill and does not resolve it against the skill
root. - Frequency: 100% reproducible on 2.0.15 across several clicks.
- Workaround: open the file from a terminal or editor instead of clicking the chat link.
Activity
github-actions commentedon Sep 26, 2026
This issue might be a duplicate of existing issues. Please check:
~-prefixed file path pill reports “File not found” while the absolute path works; the home-path expansion behavior may overlap.opencodejr commentedon Oct 28, 2026
Thanks for the detailed report! A couple of things would help us pin this down:
…should therefore no longer show up as a link.…before opening a file. Could you copy the raw text of the assistant message with the link (e.g. via copy message) and paste the relevant line here? That tells us whether the model wrote…/.config/...itself or the app turned a full path into….You can reply here with the details, or edit the issue. If you edit it, please also leave a comment saying you've updated it, so we know you're done.
Related issues, ordered by likelihood of overlap (none looks like the same problem):
C:\staticand failing in/api/fs/readopencodejr commentedon Oct 31, 2026
We're closing this as not planned for now, since we haven't heard back. We needed to know two things: whether file links with a literal
…still fail on the latest release (v2.2.0), and the raw text of the assistant message that contained the link. Since 2.0.15, an inline path only becomes clickable once the app confirms the file exists. Clicking a path also opens exactly the text written in the message, so the…most likely came from the model's own output, not from the app shortening your home directory.If this still happens on the latest version, please reply here with the raw message text (or open a new issue) and we can take another look. Thanks for the detailed report!