Repository navigation
Web Home hides global-project sessions (empty list for sessions created outside git repos) #46444
Description
Description
When I start the web UI with opencode web --hostname 0.0.0.0 --port 4096 from a directory that is not a git repo (my Windows home directory, C:\Users\Raphael), the Home page shows an empty session list ("Nothing here yet"), even though the CLI lists dozens of sessions:
opencode session listreturns all my sessionsGET /sessionvia the API returns them too- the SQLite DB (
~/.local/share/opencode/opencode.db) contains them
Steps to reproduce
- Open opencode from
C:\Users\Raphael(not inside a git repo) - Create several sessions there (I have ~21 tied to non-git directories:
C:/,C:/Users/Raphael,I:/Projetos) - Run
opencode web --hostname 0.0.0.0 --port 4096from the same directory - Open
http://localhost:4096→ Home is empty despite sessions existing
Root cause I traced
The Home page filters sessions by matching session.directory against each project's allowed directories (worktree + sandboxes) in packages/app/src/pages/home/home-sessions-controller.tsx:
const directories = new Set(input.projectDirectories().map(pathKey))
const sessions = input.sessions().filter((s) => directories.has(pathKey(s.directory)))where projectDirectories() = [worktree, ...sandboxes].
Sessions created outside a git repo belong to the global project, whose worktree is forced to / in packages/opencode/src/project/project.ts (fromDirectory). That same code skips adding sandboxes for the global project:
if (projectID !== ProjectV2.ID.global && ...) result.sandboxes.push(data.directory)So a session with directory = C:/Users/Raphael (or C:/, I:/Projetos) is compared against the global project's allowed set ["/"] and never matches → dropped from the Home list. In my DB: 21 global sessions across 3 real directories, 0 shown in the web UI; the only visible one is from a separate git project (Email-agent).
The CLI doesn't hit this because it lists by project_id, so all global sessions match.
I believe this is the same underlying problem as #27837 / #37096 / #45011 (CLI-created sessions invisible in web Home), reported from the angle of the global project worktree/sandbox mismatch.
Suggested fix
Treat the global project specially in home-sessions-controller.tsx (fall back to session.directory when no worktree/sandbox matches), or let fromDirectory accumulate sandboxes for the global project. Compare the TUI-only fix already shipped for the related /sessions issue (#29581 / #29582) which was never applied to the web Home.
A local workaround that unblocks me: manually set the global project's sandboxes column (JSON array) to my working directories so Home's directory filter matches them.
Plugins
No response
OpenCode version
1.18.20
Steps to reproduce
See above
Screenshot and/or share link
No response
Operating System
Windows 11
Terminal
Windows Terminal / PowerShell
Activity
github-actions commentedon Aug 31, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is distinct (e.g. specifically about the
globalproject worktree/sandbox mismatch on non-git directories), please note that in a comment so maintainers can track it separately.SeashoreShi commentedon Sep 1, 2026
Working on this — fix targets the web Home filter: sessions belonging to the
globalproject (created outside any git repo) are no longer dropped when their directory doesn't match the global project's/worktree. PR coming shortly.fix(app): show global-project sessions in web Home (anomalyco#46444)
vstandos commentedon Sep 6, 2026
Can reproduce on Linux (WSL2) with
opencode web --hostname 0.0.0.0started with cwd/— projectglobalhasworktree: "/".Confirmed server-side:
GET /session?directory=/&roots=true&limit=55andGET /api/sessionboth return the session; it renders fine when opened via deep link (open-project?directory=/even issues the correct request — the item is still filtered out of the list).Two additional data points:
subpath: hidden = root session with emptypath/subpath, visible = non-emptysubpath(e.g.home/ssa). Suggests the list filter dropssubpath === "".PATCH /session/:id {"directory": "/home/ssa"}returns 200 and echoes the session but does not persist — legacy root sessions cannot be migrated into a visible project at all.Related: #42627 (desktop remote server), and note that Windows desktop clients send their own cwd as project directory to a Linux server (
C:\\tempwas stored server-side as/home/ssa/C:\\temp), which compounds the visibility problem.vstandos commentedon Sep 6, 2026
Additional data point: same WSL server, and the desktop client shows the identical empty list — the session is only reachable via deep link there too, so this is not web-Home-only. Confirmed on v1.18.29 (latest release):
GET /session?directory=/home/ssa&roots=trueand/api/sessionreturn the session, the deep link renders it, and the item is still filtered out becauseglobalhasworktree: "/"and no sandboxes. Note the session carriessubpath: "home/ssa"even though the project root is/— for global-project sessions the session's owndirectory(orsubpath) should arguably be sufficient membership for Home.PR #46520 looks like the right direction but remains unmerged; since the filter is shared, landing it should also close the duplicate reports #37096 / #42668. Until it merges, the manual
sandboxescolumn workaround from the issue body is the only known unblock (WAL caveat applies).SeashoreShi commentedon Sep 7, 2026
Thanks for the extra data points — both the web Home and desktop clients use the same directory filter, so they're affected identically.
A fix is ready in #46520 (global-project sessions are no longer filtered out; rebased on latest
dev, 1-file change). If you hit the empty-session-list issue, a 👍 on the PR helps it get maintainer attention — opencode's cleanup bot closes PRs older than a month with fewer than 2 positive reactions, so community support directly affects whether the fix lands.Mattheinrichs commentedon Sep 21, 2026
Opened a fix for this: #50440
Cause: the Home list dropped sessions that had already been fetched.
buildHomeSessionRecordskept only sessions whosedirectorystring matched a projectworktree/sandbox, and sessions created outside a git repo belong to theglobalproject — whose worktree is forced to/and which records no sandboxes — so nothing matched and the list rendered "Nothing here yet".The PR matches sessions to the scoped projects by
projectIDfirst (falling back to the previous directory match), which is what the issue's suggested fix describes.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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊