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
Desktop: remote server on Windows cannot correctly load/use projects and sessions from macOS client #42627
OpenCode Desktop can connect successfully to an opencode serve instance running on a Windows workstation from a macOS Desktop client, but the remote projects/sessions are not usable from the macOS client.
The underlying API works correctly: the Mac can retrieve the Windows server's sessions and projects, and the Desktop connection is shown as green. However, the Desktop UI does not correctly load/use those remote projects and sessions.
The Desktop UI, however, does not correctly populate/use the remote projects/sessions.
Opening a new session (in the client) gets stuck, it doesn't produce any error, simply it doesn't respond.
New sessions in the host don't show up either.
The same server works correctly from Windows Desktop.
From macOS, /session returns the Windows sessions successfully, demonstrating that this is not a networking or server-state problem.
Reproducing on Windows Desktop against a WSL2 server (opencode web --hostname 0.0.0.0 --port 4096, v1.18.29). The desktop registers the project as \\wsl.localhost\Ubuntu\home\ssa (UNC path from the native Windows file picker), and every list query uses that string — while session.directory on the server is /home/ssa. The server happily resolves the foreign hint against its own cwd: it previously stored directory=C:\temp as /home/ssa/C:\temp — the exact unmerged issue #34255 (PRs #34256/#40857 still open) — so the desktop's read key never matches the write key; same "normalised on write, exact-match on read" asymmetry described in #44216.
Sessions render perfectly via deep link (which bypasses the Home directory filter), confirming server state is healthy. The --mdns --mdns-domain workaround from #19473 avoids UNC entirely and may be worth documenting for WSL users. What do maintainers consider the right layer to fix: rejecting foreign hints server-side (#40857), or making the desktop adopt the server-reported project path after connect?
New data point on Windows Desktop -> remote Linux server (WSL): the "Add project" dialog for a remote http server still uses the local Windows folder picker, so a WSL target is persisted verbatim as a UNC worktree (\\wsl.localhost\Ubuntu\home\ssa) in the client registry (%APPDATA%\ai.opencode.desktop\opencode.global.dat, key server.projects["<url>"]). The Home list then filters the global session index (GET /api/session) client-side via pathKey (\ -> / normalization for UNC). Server session directories are Linux paths (/home/ssa after realpath resolution) or, when the server resolves the raw UNC against its cwd, the hybrid /\\wsl.localhost\Ubuntu\home\ssa. Neither spelling survives pathKey equal to //wsl.localhost/Ubuntu/home/ssa, so the project row renders permanently empty while per-project exact-match requests (GET /session?directory=<raw UNC>) do resolve — sessions are visible until restart and gone after, because only the registry/selection persist. Note the add flow already fetches the server-resolved project via project.current({location}) but discards its worktree and stores the raw picker string instead; for remote connections the desktop should either use the server-echoed worktree or a server-side path picker, and/or normalize \\wsl.localhost\<distro>\... to the native mount.
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.
Activity
vstandos commentedon Sep 6, 2026
Reproducing on Windows Desktop against a WSL2 server (
opencode web --hostname 0.0.0.0 --port 4096, v1.18.29). The desktop registers the project as\\wsl.localhost\Ubuntu\home\ssa(UNC path from the native Windows file picker), and every list query uses that string — whilesession.directoryon the server is/home/ssa. The server happily resolves the foreign hint against its own cwd: it previously storeddirectory=C:\tempas/home/ssa/C:\temp— the exact unmerged issue #34255 (PRs #34256/#40857 still open) — so the desktop's read key never matches the write key; same "normalised on write, exact-match on read" asymmetry described in #44216.Sessions render perfectly via deep link (which bypasses the Home directory filter), confirming server state is healthy. The
--mdns --mdns-domainworkaround from #19473 avoids UNC entirely and may be worth documenting for WSL users. What do maintainers consider the right layer to fix: rejecting foreign hints server-side (#40857), or making the desktop adopt the server-reported project path after connect?vstandos commentedon Sep 6, 2026
New data point on Windows Desktop -> remote Linux server (WSL): the "Add project" dialog for a remote http server still uses the local Windows folder picker, so a WSL target is persisted verbatim as a UNC worktree (
\\wsl.localhost\Ubuntu\home\ssa) in the client registry (%APPDATA%\ai.opencode.desktop\opencode.global.dat, keyserver.projects["<url>"]). The Home list then filters the global session index (GET /api/session) client-side viapathKey(\->/normalization for UNC). Server session directories are Linux paths (/home/ssaafter realpath resolution) or, when the server resolves the raw UNC against its cwd, the hybrid/\\wsl.localhost\Ubuntu\home\ssa. Neither spelling survivespathKeyequal to//wsl.localhost/Ubuntu/home/ssa, so the project row renders permanently empty while per-project exact-match requests (GET /session?directory=<raw UNC>) do resolve — sessions are visible until restart and gone after, because only the registry/selection persist. Note the add flow already fetches the server-resolved project viaproject.current({location})but discards its worktree and stores the raw picker string instead; for remote connections the desktop should either use the server-echoed worktree or a server-side path picker, and/or normalize\\wsl.localhost\<distro>\...to the native mount.thdxr commentedon Oct 11, 2026
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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊