Web & Desktop home UIs render no projects/sessions against a headless server (v1.18.19) although GET /project returns the registered git project #44216

Activity

1. github-actions

   assigned

   Brendonovich

   on Aug 22, 2026
2. github-actions commented on Aug 22, 2026

   

   github-actionsBot

   on Aug 22, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Web UI: session list empty on left panel when using web server mode #27837: Web UI session list empty on left panel when using web server mode — same symptom: sessions visible via API but not rendered in the web UI home when running in server mode
   • [BUG] Web UI session list stays empty when embedded in iframe, requires manual server/directory click to populate #36237: Web UI session list stays empty when embedded in iframe — same root cause analysis (SSE race/workspace registration timing causing the frontend to miss projects/sessions on initial load)
   • Desktop: project picker sends host paths to a remote server, and the resulting failure is silent #44150: Desktop project picker sends host paths to a remote server — overlaps with the observation that Desktop's "Add project" opens the local OS file picker instead of browsing the remote server's filesystem
3. blue126 commented on Aug 23, 2026

   

   blue126

   on Aug 23, 2026

   More actions

   Hit this from a different deployment shape — desktop app on macOS against opencode serve inside a dev container — and found something that might narrow it down. In my case the desktop app listed some sessions rather than none, and which ones it listed turned out to depend entirely on one string.

   The asymmetry: the directory is normalised on write but matched exactly on read.

   The repo is bind-mounted into the container at /workspaces/<repo>. The desktop app's project picker is the native macOS one, so it can only ever send the host path, /Users/<user>/Projects/<repo>.

   I first made that host path resolve inside the container with a symlink to /workspaces/<repo>. Prompts then worked, but the session list was empty. Looking in the database:

   sqlite> SELECT directory, COUNT(*) FROM session GROUP BY directory;
   /workspaces/<repo>            15
   /Users/<user>/Projects/<repo>  3
   

   Querying the server the way each client does:

   GET /api/session?directory=/workspaces/<repo>             -> 15
   GET /api/session?directory=/Users/<user>/Projects/<repo>  ->  0
   

   The desktop app asks for the second and gets nothing. The three rows that did carry the host path were all created before the symlink existed — at that point realPath failed outright, so the raw client string got stored. Once the symlink was in place, realPath resolved it to /workspaces/<repo> and every new session was filed under a path the app never asks about — including sessions the app itself had just created.

   So: the write path resolves symlinks, the read path compares strings. Any deployment where the client's path and the server's resolved path differ ends up with a list that is empty (or partially populated, if some rows predate the mismatch).

   Workaround, for anyone else on dev containers: don't use a symlink — mount the checkout a second time at the exact path the host uses:

   "mounts": [
     "source=${localWorkspaceFolder},target=${localWorkspaceFolder},type=bind"
   ]

   A bind mount has nothing to resolve, so realPath returns the same string the client sent and write/read agree. After also rewriting the existing rows (session.directory, session.path, project.worktree, project_directory.directory) to the host path, both the desktop app and the web UI list everything — the web UI follows the project record, and that path is now valid on both sides.

   That last part may be the useful bit for a fix: pick one canonical form for the directory, and apply it in both directions. Resolving on write while matching raw on read cannot agree unless the two paths happen to be identical.

   Environment: desktop app 1.18.21 (macOS arm64), opencode serve 1.18.21 in a Debian dev container, plain HTTP to 127.0.0.1:4096, no workspaces (session.workspace_id is null throughout).
4. leolau commented on Aug 25, 2026

   

   leolau

   on Aug 25, 2026

   Author

   More actions

   Still reproduces on v1.18.23 (server opencode web headless + clean private-window browser client). GET /project returns the git project with worktree and vcs: git; home remains empty, Add project greyed. PR #39732 not merged; no changelog mention in 1.18.22/23. Watching releases daily.
5. Mattheinrichs commented on Sep 21, 2026

   

   Mattheinrichs

   on Sep 21, 2026

   More actions

   Related: #46520 is a 1-file fix for one of the causes — Home/Desktop dropping sessions that belong to the global project (created outside a git repo), because their directory never matches the global worktree /.

   Note it won't cover the empty client-side project registry case (that's the separate #45011 thread), so if your install has no projects registered at all this may not be the whole story. But if sessions exist and the API returns them, it's worth a look — and a 👍 on #46520 helps it survive the cleanup bot's age/reaction rule.
6. 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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
7. thdxr

   closed this as not plannedon Oct 11, 2026