Repository navigation
desktop: file card in chat 404s with "File not found" for files in subfolders #50880
Description
Summary
Clicking a file card in the chat fails with «не удалось открыть файл: file not found».
The client requests only the file name (GET /api/fs/read/start.cmd) while the server
resolves relative paths against the user's home directory, so any file that does not
live directly in the home folder returns 404.
Environment
- opencode version: 2.0.15 (desktop app,
opencode-cli.version) - OS: Windows_NT 10.0.19045 (Windows 10 22H2, win32 x64)
- Terminal: Unavailable — OpenCode desktop app, no terminal session (
TERM=xterm-256color,TERM_PROGRAMunset) - Shell:
C:\Windows\system32\cmd.exe(ComSpec); commands executed via Windows PowerShell 5.1 - Install/channel: latest — desktop installer (
@opencode-desktop) - Active plugins: none found — no
opencode.json(c),.opencode/opencode.json(c)or~/.config/opencode/opencode.json(c)present
Reproduction
- Assistant writes a file into a project subfolder:
<project>/mini-figma/start.cmd. - Click the resulting file card in the chat.
- UI reports «не удалось открыть файл: file not found».
- Server log shows
GET /api/fs/read/start.cmd→http.status=404.
Expected Behavior
The card opens the file it refers to: <project>/mini-figma/start.cmd.
Actual Behavior
Request carries the base name only, the subfolder is dropped:
GET /api/fs/read/start.cmd
{"_tag":"FileNotFoundError","path":"start.cmd","message":"File not found: start.cmd"} (HTTP 404)
Path probes against the same endpoint:
| path | status |
|---|---|
/api/fs/read/start.cmd |
404 |
/api/fs/read/mini-figma/start.cmd (relative to project root) |
404 |
/api/fs/read/Documents/<project>/mini-figma/start.cmd (relative to $HOME) |
200 |
/api/fs/read/C:/Users/<user>/Documents/<project>/mini-figma/start.cmd |
200 |
Two mismatches: (1) the card sends only the base name; (2) relative fs/read paths resolve
from the home directory instead of the project/session directory.
Additional Context
Log excerpt (6 occurrences over two clicks):
level=INFO message="Sent HTTP response" http.method=GET http.url=/api/fs/read/start.cmd http.status=404
- Frequency: 6/6 — fully reproducible.
- Workspace is not a git repo;
worktree discovery failed ... DirectoryUnavailableError
warnings appear in the log (probably unrelated). - Workaround: hard link at
C:\Users\<user>\start.cmd→ real file, so the base-name
request resolves and the card opens (verified 200 afterwards). Masks the bug, not a fix.
Activity
Dante-dan commentedon Oct 6, 2026
I checked the current v2 file-opening path: relative paths retain their subdirectory and are sent with
location[directory], while absolute paths use the filename plus its parent directory. Write-tool cards render the tool content without a filesystem read.Could you share whether this still occurs on the latest desktop build, the exact card/link you clicked (or a screenshot), and the full request URL including its query string? That will help distinguish a tool card from a file link and identify where the path or session location is lost.
opencodejr commentedon Oct 28, 2026
Thanks for the detailed report and the path probes.
I couldn't reproduce this here: it happens in the desktop app's chat UI, and this sandbox has no way to run the desktop app. Reading the code, here's what I found:
/api/fs/read/...paths against the location (project directory) sent with each request. If none is sent, it uses the server process's working directory, which for the desktop app is likely your home folder. So that part is expected for requests made by hand without a location.start.cmd, without themini-figma/subfolder and seemingly without your project's location. That comes from how the app builds the link for the card.Related issues, most relevant first:
~-prefixed path links fail.You're on 2.0.15. Could you update the desktop app to the latest release and say here whether clicking the card still fails? If it does, the
GET /api/fs/read/...line from the log for that click would help a maintainer with the desktop app look into it.