Desktop v1.16.0 converts WSL /mnt/c/... workspace to Windows C:\... path and breaks file/session list

[sky10205]

Description

OpenCode Desktop v1.16.0 on Windows is connected to an opencode serve instance running inside WSL.

The real workspace path on the WSL server is:

/mnt/c/Projects/ExampleWorkspace

Direct API requests to the WSL server work correctly with this WSL-native path. However, after opening the same workspace in Desktop, the UI fails to list files/sessions with:

Unexpected server error. Check server logs for details.

The WSL server logs show that Desktop sends a translated Windows path back to the Linux/WSL server:

Path is not absolute: C:\Projects\ExampleWorkspace
FileSystem.realPath (/home//C:\Projects\ExampleWorkspace)
FileSystem.realPath (/home//C:/Projects/ExampleWorkspace)

Desktop network logs show requests like:

GET /session/?directory=C%3A%5CProjects%5CExampleWorkspace
GET /session?directory=C%3A%5CProjects%5CExampleWorkspace&roots=true
GET /path?directory=C%3A%2FProjects%2FExampleWorkspace

But the WSL server expects:

/mnt/c/Projects/ExampleWorkspace

I also reset Desktop state/cache and verified the active persisted state no longer contained C:... or C:/... paths. After restarting Desktop, it recreated malformed workspace state and continued sending Windows-style paths to the WSL server.

Confirmed failure point:
Desktop internally translates/restores the server-native WSL path /mnt/c/... into C:... or C:/..., then sends that translated Windows path as the directory query parameter to the WSL server. On Linux/WSL this path is invalid or resolved as /home//C:/..., causing /file, /session, or /path APIs to fail with HTTP 500.

Expected:
When connected to a WSL/remote HTTP server, Desktop should preserve and use the server-native workspace path /mnt/c/... in API requests.

Actual:
Desktop sends C:... or C:/... to the WSL server, causing file/session list failures.

Plugins

None relevant

OpenCode version

Desktop v1.16.0; WSL server/CLI v1.16.0

Steps to reproduce

1. In WSL, start the server from a workspace under /mnt/c:

   cd /mnt/c/Projects/ExampleWorkspace
   opencode serve --hostname 0.0.0.0 --port 4096

2. On Windows, open OpenCode Desktop v1.16.0.

3. Connect Desktop to:

   http://localhost:4096

4. Open/select the WSL workspace:

   /mnt/c/Projects/ExampleWorkspace

5. Verify direct API requests work:

   GET http://127.0.0.1:4096/global/health
   GET http://127.0.0.1:4096/session?directory=/mnt/c/Projects/ExampleWorkspace&roots=true&limit=3
   GET http://127.0.0.1:4096/file?directory=%2Fmnt%2Fc%2FProjects%2FExampleWorkspace&path=.

6. Observe Desktop sidebar errors:

   Failed to list files
   Unexpected server error. Check server logs for details.

   and/or:

   Failed to load sessions
   Unexpected server error. Check server logs for details.

7. Check WSL server logs. Desktop is sending C:\Projects\ExampleWorkspace or C:/Projects/ExampleWorkspace instead of /mnt/c/Projects/ExampleWorkspace.

Screenshot and/or share link

No response

Operating System

Windows 11 + WSL2

Terminal

Desktop app + WSL server started from WSL shell

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Desktop App sends UNC paths to WSL-hosted server, breaking all bash tool calls [WORKAROUND ✅ ] #19473: Desktop App sends UNC/Windows paths to WSL-hosted server, causing path mangling and tool failures — same root cause (Desktop translating server-native WSL paths into Windows-style paths before sending API requests)
• Desktop GUI sidebar empty when connected to WSL2 opencode serve #29766: Desktop GUI sidebar empty when connected to WSL2 opencode serve — documents the same path concatenation bug on Linux where Windows paths get resolved as relative paths (e.g. /home/<wsl-user>/C:/...)
• WSL cannot be used from Desktop App (with WSL server) #28799: WSL cannot be used from Desktop App (with WSL server) — same symptom of Desktop sending \\wsl.localhost or Windows-style paths to a WSL server instead of the server-native path
• Path Confusion in OpenCode Desktop with WSL Server: Files Not Visible #21193: Path Confusion in OpenCode Desktop with WSL Server: Files Not Visible — same Desktop+WSL path mismatch scenario

If your issue has distinct details or a different reproduction path not covered by these, please link to them and explain the difference.

[SrHenry]

Having this exact same issue, never happened before v1.16.0

[sky10205]

Thanks. I agree this is related to earlier WSL path issues, but this report is specifically for a v1.16.0 regression.

Another user also confirmed the exact same issue and said it never happened before v1.16.0.

The key difference from the older reports is that direct WSL server API calls with /mnt/c/... work, but Desktop v1.16.0 still sends C:... or C:/... as the directory query parameter to the WSL server for file/session/path APIs, even after clearing persisted Desktop state/cache. Desktop then recreates malformed workspace state after restart.

So this seems to be an internal Desktop path restoration/translation issue in v1.16.0, not only stale local state or a corrupted server DB.

[c17r]

Also happens when using opencode web inside WSL but the browser is on the Windows side.

[WhiteGiverMa]

Can confirm this is still reproducible on v1.17.9, with an additional trigger scenario: directory rename.

Environment

Component	Version / Detail
Desktop	OpenCode Desktop (Electron), Windows 11
WSL server	opencode serve v1.17.9, WSL2 Ubuntu
Project location	G:\dev\dreamer-heroines (Windows) / /mnt/g/dev/dreamer-heroines (WSL)
Connection	Desktop → http://localhost:4096 (WSL2 port-forwarded)

Scenario

The project directory was renamed from DreamerHeroines to dreamer-heroines. After the rename:

1. Windows-side DB (%LOCALAPPDATA%\opencode\opencode.db) stores the path as G:/dev/dreamer-heroines — correct for Desktop's own file operations
2. WSL-side DB (~/.local/share/opencode/opencode.db) stores the path as /mnt/g/dev/dreamer-heroines — correct for WSL serve

Both databases are independently correct for their respective platforms. The problem occurs when Desktop reads the Windows-native path from its own DB and sends it as-is to the WSL server via API:

GET /session?directory=G:/dev/dreamer-heroines

WSL server log:

ERROR: Path is not absolute: G:/dev/dreamer-heroines
  at U0 (chunk-arezpm57.js:59:16502)
  at buildQueryFromSourceParams (chunk-arezpm57.js:2:5450)
  at Session.list (chunk-e6zcxa2p.js:3:8541)
  at SessionHttpApi.list

On Linux, path.resolve("G:/dev/dreamer-heroines") treats this as a relative path, prepending CWD:
→ /home/{user}/G:/dev/dreamer-heroines → doesn't exist → HTTP 500

Workaround attempted

Changed Windows-side DB paths to /mnt/g/ format — this fixes the WSL server interaction but breaks Desktop's own file operations (it can't resolve /mnt/g/ paths natively on Windows). This confirms the fix must be in Desktop's API client layer (path translation before sending to remote server), not in the database.

Additional note: file picker corruption

When Desktop receives the malformed path back from the server, it also corrupts the file picker state:

ERROR: Failed to init file picker: Invalid path /home/alyssaillusion/G:/dev/dreamer-heroines

This suggests the Windows path is being concatenated with the WSL CWD somewhere in the file picker initialization logic as well.

[romanilyin]

I traced the server-side failure to the directory request boundary and opened #33107 to discuss a staged path contract.

The first PR (#34256) only prevents a client-native Windows path from reaching instance loading and returns a clear 400. It would not close this issue: Desktop still needs to preserve/send /mnt/c/... when connected to a WSL server.