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

Activity

1. github-actions

   assigned

   Hona

   on Jun 5, 2026
2. github-actions commented on Jun 5, 2026

   

   github-actionsBot

   on Jun 5, 2026 – with GitHub Actions

   Contributor

   More 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.
3. SrHenry commented on Jun 5, 2026

   

   SrHenry

   on Jun 5, 2026

   More actions

   Having this exact same issue, never happened before v1.16.0
4. sky10205 commented on Jun 5, 2026

   

   sky10205

   on Jun 5, 2026

   Author

   More actions

   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.
5. rekram1-node

   marked how to open wsl project when attach wsl server #31372 as a duplicate of this issue on Jun 8, 2026
6. c17r commented on Jun 8, 2026

   

   c17r

   on Jun 8, 2026

   More actions

   Also happens when using opencode web inside WSL but the browser is on the Windows side.
7. WhiteGiverMa commented on Jun 23, 2026

   

   WhiteGiverMa

   on Jun 23, 2026

   More actions

   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.
8. romanilyin commented on Jun 27, 2026

   

   romanilyin

   on Jun 27, 2026

   More actions

   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.
9. Realmagnum commented on Aug 26, 2026

   

   Realmagnum

   on Aug 26, 2026

   Last edited by Realmagnum

   More actions

   Same root cause on Windows Desktop 1.18.23 → Linux opencode serve (server at <internal-host>, project at <internal-path>/work-projects).

   The remote connection itself works: server returns 401 without creds (basic auth), and the client receives server events (turn-complete notifications land in opencode.global.dat for the configured server URL). But the Home UI never lists the remote project/sessions.

   Decisive log line from the bundled sidecar (~/.local/share/opencode/log/opencode.log):

   bootstrapping directory="C:\home\srv\projects\work-projects"
   ERROR PlatformError: NotFound: FileSystem.realPath (/home/srv/projects/work-projects)
     cause: ENOENT: no such file or directory, lstat 'C:\home'
   

   So the Windows client translates the server-native POSIX path /home/srv/projects/work-projects into C:\home\srv\projects\work-projects and tries to realPath it locally → ENOENT → project/session list never loads.

   Notes:

   • Same server + same credentials work fine from macOS Desktop client — macOS doesn't do the drive-letter translation.
   • The desktop even created opencode.workspace.-home-srv-pr.*.dat workspace state for the remote project path, confirming it treats the remote worktree as a local workspace.
   • Duplicate family: Desktop GUI sidebar empty when connected to WSL2 opencode serve #29766, Desktop Home view shows projects but zero sessions (database is correct) #36064, Desktop: remote server on Windows cannot correctly load/use projects and sessions from macOS client #42627, Web & Desktop home UIs render no projects/sessions against a headless server (v1.18.19) although GET /project returns the registered git project #44216.
10. thdxr commented on Oct 11, 2026

    

    thdxr

    on Oct 11, 2026

    Member

    More actions

    Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

    — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
11. thdxr

    closed this as not plannedon Oct 11, 2026