Skip to content

Desktop: remote server on Windows cannot correctly load/use projects and sessions from macOS client #42627

Closed as not planned

Description

@triguero

Description

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.

Plugins

No response

OpenCode version

1.18.18 in both machines

Steps to reproduce

Environment

  • OpenCode Desktop: 1.18.18
  • Server: Windows 11
  • Client: macOS
  • Server: opencode serve --hostname 127.0.0.1 --port 4096
  • Connection: SSH tunnel
  • Windows Desktop can use the server normally

Reproduction

  1. Run opencode serve --hostname 127.0.0.1 --port 4096 on Windows.
  2. Connect Windows OpenCode Desktop to 127.0.0.1:4096.
  3. Create/use sessions and projects on that server.
  4. Expose port 4096 to a Mac through an SSH tunnel.
  5. Connect macOS OpenCode Desktop to 127.0.0.1:4096.
  6. The connection is shown as green.
  7. From the Mac, verify that the server contains the sessions:
    curl http://127.0.0.1:4096/session
  8. 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.

Related issues:

#19348
#29766
#25264

Screenshot and/or share link

No response

Operating System

Windows 10 and MacOS 26.5.2

Terminal

No response

Activity

  1. vstandos commented on Sep 6, 2026

    @vstandos

    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?

  2. vstandos commented on Sep 6, 2026

    @vstandos

    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.

  3. thdxr commented on Oct 11, 2026

    @thdxr
    Member

    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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions