You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Opening a backend-served URL path (/static/render/xxx.mp4) in the desktop app triggers GET /api/fs/read/... with a drive-root-relative Windows path (\static\render\xxx.mp4), which resolves to C:\static\render\xxx.mp4 (does not exist) → ENOENT → HTTP 500 → user-facing toast "加载文件失败 / UnexpectedStatus".
Environment
opencode version: 2.0.13 (from runtime diagnostics; opencode CLI not on PATH so opencode --version is Unavailable)
Active plugins: none found (no opencode.json(c) project or global; only ~/.config/opencode/service.json)
Reproduction
A local backend serves a file at URL path /static/render/task_x_composed.mp4; the same file exists on disk at <project>\static\render\task_x_composed.mp4.
In the desktop app, open/click this path as presented (string /static/render/task_x_composed.mp4).
The app requests GET /api/fs/read/... with path \static\render\task_x_composed.mp4.
FileSystem.realPath resolves the drive-root-relative path against C:\ → lstat 'C:\static' → ENOENT.
Server returns 500; desktop shows the toast "加载文件失败 / UnexpectedStatus".
Reproduced twice consecutively (2026-09-23 00:22:39 and 00:23:02 local time).
Expected Behavior
The file reader should resolve the path against the project/workspace root (where <project>\static\render\... exists), or a URL-style input should not be treated as a filesystem path at all. A genuinely missing file should surface as a not-found result, not a generic 500 → UnexpectedStatus.
Actual Behavior
cause="PlatformError: NotFound: FileSystem.realPath (\static\render\)
[cause]: Error: ENOENT: no such file or directory, lstat 'C:\static'"
http.method=GET http.url=/api/fs/read/task_..._composed.mp4 http.status=500
Both attempts failed identically (role=server, HTTP 500).
Additional Context
Log source: ~/.local/share/opencode/log/opencode.log, two identical entries at 2026-09-22T16:22:39.433Z and 2026-09-22T16:23:02.120Z.
The target file is fine: it exists at <project>\static\render\task_..._composed.mp4 and serves correctly over HTTP (200, video/mp4, 1,597,924 bytes).
Likely path derivation: the URL /static/render/... had / normalized to \, leaving a drive-root-relative path; Windows resolves \static\... against the current drive root (C:\).
Frequency: consistent (2/2 attempts).
Workaround: open the same content via its HTTP URL in a browser, or pass the absolute filesystem path; both avoid the toast.
Screenshot of the toast and full redacted log lines available on request.
The fix updates Windows path handling so URL-style paths such as /static/render/... resolve relative to the workspace, while preserving drive-qualified and UNC path handling. I've added regression tests and documented the validation results in the PR.
The PR is open and awaiting review. Thanks for reporting this!
Can you retest on the latest desktop release (2.2.0)? Since 2.1.0, /api/fs/read returns a not-found (404) error instead of a 500 for paths that don't exist or point outside the project. The way file links in messages are detected and opened has also been rewritten since 2.0.13 (feat(session-ui): deterministic timeline file link detection and resolution #53641). Please let us know whether you still see the error toast, and if so, include the matching log line.
Where exactly did /static/render/task_x_composed.mp4 appear, and what did you click? For example: a link in an agent reply, inline code in a message, the file tree, or a tool output. A short description or the screenshot you mentioned is enough. Links open through different code depending on where they appear.
You can reply here, or edit the issue. If you edit it, please also leave a comment saying you've updated it so we know you're done.
These issues are related but don't look like the same problem (ordered by likelihood):
We haven't heard back about the retest on the latest desktop release, or about where the /static/render/... path appeared and what was clicked, so I'm closing this for now.
Since 2.1.0, /api/fs/read returns a not-found error instead of a 500 for paths like this. File links in messages have also been reworked since 2.0.13 (#53641), so the error you saw may already be gone.
If it still happens on the current release, please comment here with where the path appeared, what you clicked and the matching log line, and we can reopen. Thanks for the detailed report!
Activity
harshitsharmaaaa commentedon Oct 22, 2026
I've opened a PR to address this issue: #58178
The fix updates Windows path handling so URL-style paths such as
/static/render/...resolve relative to the workspace, while preserving drive-qualified and UNC path handling. I've added regression tests and documented the validation results in the PR.The PR is open and awaiting review. Thanks for reporting this!
opencodejr commentedon Oct 28, 2026
Thanks for the detailed report and the log lines.
Two things would help us take this further:
/api/fs/readreturns a not-found (404) error instead of a 500 for paths that don't exist or point outside the project. The way file links in messages are detected and opened has also been rewritten since 2.0.13 (feat(session-ui): deterministic timeline file link detection and resolution #53641). Please let us know whether you still see the error toast, and if so, include the matching log line./static/render/task_x_composed.mp4appear, and what did you click? For example: a link in an agent reply, inline code in a message, the file tree, or a tool output. A short description or the screenshot you mentioned is enough. Links open through different code depending on where they appear.You can reply here, or edit the issue. If you edit it, please also leave a comment saying you've updated it so we know you're done.
These issues are related but don't look like the same problem (ordered by likelihood):
/api/fs/read, which fails with a 500 and the sameUnexpectedStatustoast/api/fs/readopencodejr commentedon Oct 31, 2026
We haven't heard back about the retest on the latest desktop release, or about where the
/static/render/...path appeared and what was clicked, so I'm closing this for now.Since 2.1.0,
/api/fs/readreturns a not-found error instead of a 500 for paths like this. File links in messages have also been reworked since 2.0.13 (#53641), so the error you saw may already be gone.If it still happens on the current release, please comment here with where the path appeared, what you clicked and the matching log line, and we can reopen. Thanks for the detailed report!