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
{{ message }}
Repository navigation
[BUG]: POSIX server resolves foreign Windows directory hints against its cwd #34255
On a Linux/WSL server, a request directory such as C:\Work\Repo or a Windows UNC path can reach instance loading and be treated as a relative path. The value is then resolved under the server cwd, producing a mangled directory and a later 500 or misleading tool error.
The request boundary should consume query/header encoding once, detect foreign rooted syntax before InstanceStore.load, and return a structured 400 explaining that the server expects a native POSIX/WSL path.
This is only the server-side validation and diagnostic fix. It does not make Desktop preserve /mnt/c/...; that remains the client-side part of #30895.
OpenCode version
Current dev / 1.17.11
Steps to reproduce
Start opencode serve on Linux or WSL.
Request:
GET /session?directory=C%3A%5CWork%5CRepo
Observe that the path is resolved under the server cwd and fails later instead of being rejected at the request boundary.
The same class of failure can be reproduced with a UNC directory hint such as:
\\wsl.localhost\Ubuntu\home\user\repo
Expected behavior
The server returns a structured HTTP 400 before instance creation and explains that a server-native POSIX/WSL path is required.
Operating System
Linux or Windows 11 with WSL2
Terminal
Any HTTP client, or OpenCode Desktop connected to a WSL-hosted server
If your issue is specifically scoped to the server-side HTTP 400 validation fix (as a subset of #19473's suggested fixes), please clarify that distinction in the issue or consider contributing the fix directly to the existing tracking issue.
Activity
github-actions commentedon Jun 27, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is specifically scoped to the server-side HTTP 400 validation fix (as a subset of #19473's suggested fixes), please clarify that distinction in the issue or consider contributing the fix directly to the existing tracking issue.
github-actions commentedon Aug 27, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.