Repository navigation
desktop: file card in chat 404s with "File not found" for files in subfolders #50881
Closed as duplicate
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
argszero commentedon Sep 23, 2026
Duplicate of #50880 — same reporter, same reproduction; this one was opened four minutes later with an identical body, so it can be closed in favour of #50880.
For whoever picks this up, on
v2the click path ispackages/app/src/session/files/open-artifact.tsx:ArtifactOpener.open()→resolve(href, base)→resolveArtifactPath(base ?? "", href)(packages/app/src/workspaces/files/artifact.ts). A bare basename resolves against the workspace root, sostart.cmdbecomesstart.cmdand/api/fs/read/start.cmd404s when the file actually lives in a subfolder;openTab()only creates a tab whenfile.get(path)?.loadedis true, so the failure surfaces as a generic error with no fallback lookup.neriousy commentedon Oct 20, 2026
Thanks for the report. We're tracking this same file-card opening problem in #50880, so I'm closing this as a duplicate. Please follow that issue for updates.