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

[leolau]

Environment

• opencode web v1.18.19 headless on Ubuntu 24.04 (systemd), --hostname 127.0.0.1 --port 4096, WorkingDirectory set to a git repository (/opt/data/aicoding/repos/ai-prentice-4-all).
• Clients tested: web UI via HTTPS reverse proxy (Chrome, normal + private windows), Desktop app 1.18.x (macOS arm64) connected via defaultServerUrl (tunnel), TUI via opencode attach.

Expected

Home UI lists the server's project (the git repo) and its sessions; "+"/Add project usable.

Actual

• Web home shows Nothing here yet / Create a session to get started; Add project greyed; no project nodes (also with ?directory=<repo> in the URL and in a clean private window).
• Desktop shows the server as connected (green dot, Default Server) but lists no sessions/projects; its Add project opens the local OS file picker (useless for a remote server).
• TUI (opencode attach) works fine and lists sessions — so the server itself is healthy.

Evidence (server side is correct)

GET /project returns:

[{"id":"global","worktree":"/"},{"id":"76860fc1…","worktree":"/opt/data/aicoding/repos/ai-prentice-4-all","vcs":"git","sandboxes":[…]}]

GET /session?directory=<repo> returns sessions with that projectID. GET /global/health = {"healthy":true}.

Tried

• POST /session?directory=<repo> (registers project correctly; UI still empty).
• POST /experimental/workspace {"type":"worktree"} → WorkspaceCreateError: Timed out waiting for global event (and, before the project existed, Worktrees are only supported for git projects).
• Setting server cwd to the git repo (project then auto-registers; UI still empty).
• Private/incognito windows; hard reloads.

Impact

Headless deployments (the documented opencode serve/opencode web use-case) have no usable web/desktop home; only the TUI works. Related: #7790, #7371.

Suggestion

Home should render GET /project results regardless of workspace layer; web needs a server-side directory picker instead of the OS picker; workspace creation should not hang (Timed out waiting for global event).

[github-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

[blue126]

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).

[leolau]

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.