Repository navigation
[BUG]: Project selection is different between Desktop and Web #13518
Description
Description
I am connected to a remote instance of opencode web, running on a virtual machine, accessible via http://localhost:4096.
I connect via a browser tab and away we go.
OpenCode Web Experience
If I click a "Recent Projects" entry, it loads the session and all is well.
If I click on the Projects button, I can search for folders/locations within the context of where opencode web is running, having visibility into repositories/code inside of this virtual machine.
When I select one, a new session is created and all is well.
OpenCode Desktop Experience
While trying the OpenCode Desktop application, I add the http://localhost:4096 server and set it as the default.
When opening the Desktop application, the list of "Recent Projects" is populated based on sessions within my virtual machine.
If I click a "Recent Projects" entry, it loads the session and all is well.
If I click on the Projects button, I am presented with a Gtk-based File Picker modal, but it is on my host machine, rather than in the context of the server I am connected to.
Expected OpenCode Desktop Experience
Generally, I would expect this to match the OpenCode Web experience, where project and project selection occur in context of the server I am connected to.
If the OpenCode Desktop application is launched and connected to the self-launched backend, then using the file picker for local files makes sense and would be in the context of the server it is connected to (for an enhanced, "native" experience.
Plugins
None
OpenCode version
1.1.65 ~ 1.2.10+
Steps to reproduce
- Create a virtual machine that can run opencode. This was tested with RHEL 10.1.
- Ensure firewall allows ingress on port 4096.
- Run
opencode-cli --port 4096 --hostname 0.0.0.0as the virtual machine user whose contents you wish to have access to. - Connect to
http://localhost:4096/and verify that you can kick off sessions using the contents from within the virtual machine. - Launch the Desktop application, connect to the server at
http://localhost:4096/. - Try to open a new project and verify that it opens a file picker modal, accessing the host filesystem for the current user rather than the filesystem in the virtual machine for the server-running user.
Screenshot and/or share link
No response
Operating System
Host: RHEL 9.6; Virtual Machine: RHEL 10.1
Terminal
gnome-shell, ptyxis
Activity
github-actions commentedon Feb 13, 2026
This issue might be a duplicate of an existing issue. Please check:
Both report the same root cause: the Desktop app's file picker opens on the host/local machine instead of the remote server context when connecting to a remote OpenCode instance (WSL, VM, or similar). This differs from the Web UI, which correctly searches/opens projects in the remote server's context.
These may be related to or consolidated under the same fix.
jrmcpeek commentedon Feb 13, 2026
Yes, these look related. Similar documented behavior.
But the fix may not be as simple as merely checking whether the server is running on
localhostor127.0.0.1- it may need a more nuanced approach, or configurability on a per-server basis (remove vs local).jrmcpeek commentedon Feb 21, 2026
Despite changes to localhost interactions in both 1.2.7 and 1.2.10, this issue still persists.
Trying to start a new session only offers folder selection from the host running the desktop app and does not consider whether the desktop app is connected to an
opencode webinstance.camtheman256 commentedon Mar 9, 2026
A workaround for this is to edit your
/etc/hostsfile and add a line likeThen you can connect to your remote server as
remote-server:4096even though it's just an alias for localhost. Opencode will think you're accessing a remote and give you the web-based filepicker as expected. Not a great workaround, but it does work.jrmcpeek commentedon Mar 9, 2026
Yup. I tested that and it worked for me.
It also works if I give it the device's hostname instead of
localhost, which was nicer than modifying the hosts file (for me).github-actions commentedon Jul 3, 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.