Repository navigation
Web sidebar shows 'no sessions' on Windows despite API returning them (F5 loses list; TUI sessions invisible) #42668
Description
Summary
Web UI sidebar shows "no sessions" for a project even though the server API returns all sessions. On Windows (native, not WSL), sessions created in the TUI are never listed in the web sidebar, and sessions created in the web disappear from the list after a page refresh (F5). The folder/project itself persists.
Environment
- opencode 1.18.18 (chocolatey), Windows native,
pwsh - Data dir:
C:\Users\rcocchiararo\.local\share\opencode\opencode.db - Server:
opencode web --hostname 0.0.0.0 --port 4096withOPENCODE_SERVER_PASSWORD(basic auth)
Facts verified
- Project
C:/DEV/popeiexists with 14 sessions in the DB, stored with forward slashes:C:/DEV/popei. /project/currentreturnsworktree: "C:\\DEV\\popei"(backslash).GET /api/session?directory=C:/DEV/popei&roots=true&limit=50returns 14 sessions. Same with backslash encoding. Server filter handles both.- Sessions created in the web do show up in the TUI (shared DB). Sessions created in the TUI are not shown in the web sidebar.
- Direct URL navigation to a session (
http://<host>:4096/<dir>/session/<id>) loads it fine (SPA returns 200) — only the sidebar list is broken. - The client bundle (index-CQtwhDOb.js) normalize fn already converts backslashes to forward slashes and strips trailing slashes:
Ge=e=>{const t=Sye(e)?e.replaceAll("\\","/"):e,n=kye(t);return !n&&t.startsWith("/")?"/":xye(n)?${n}/:n}
and the sidebar filter isJAe=(e,t)=>Ge(e.directory)===Ge(t)&&!e.parentID&&!e.time?.archived, so the separator mismatch should NOT be the cause — yet the list is empty.
Expected
After adding/selecting a project, the sidebar should list existing sessions from the API, and the list should survive F5.
Possibly related
- Web UI not showing my sessions #10519 Web UI not showing my sessions
- [Desktop] Session list is not updating when switching between projects #12262 Session list not updating / scoping issues
- [Windows] Web UI not showing sessions - path separator mismatch (backslash vs forward slash) #21340 Path separator mismatch hiding sessions on Windows
- [Regression] v1.17.13 web UI session list still empty — fixes from #30167/#30314/#30804 not cherry-picked to stable #35340 v1.17.13 web UI session list still empty
- [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 until manual server/directory click
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Aug 15, 2026
This issue might be a duplicate of existing issues. Please check:
You already referenced #35340 and #36237 in your report — the above may overlap with those as well. If your issue is distinct (e.g., the path normalization is provably not the cause), please clarify how it differs from the above.
MilkyWay008 commentedon Aug 15, 2026
That empty-sidebar-with-API-returning-sessions bug has a whole family behind it, #39040 and #40399 are nearly the same on Windows. One thing that kicks the list alive from #36237: click the server/directory entry manually to force the sidebar fetch, it's a client-side trigger thing, not a path issue. Might also be worth checking whether 1.18.18 predates the fix in that bug class, a newer build may just have it. Oh also, btw, I built a portable Hermes OTG and I run it on USB as my rescue agent; super handy doing quick diagnose & fix, check it, imo it'll help you. https://github.com/MilkyWay008/Hermes-OTG
Mattheinrichs commentedon Sep 21, 2026
Same "no sessions in the sidebar while the API returns them" symptom here. There's a fix up in #46520 — 1 file, Home session filter; sessions in the
globalproject (created outside a git repo) were dropped because their directory never matches the global worktree/.If it's still broken for you: PRs older than a month with fewer than 2 positive reactions get closed by the cleanup bot, so a 👍 on #46520 is what keeps that fix from being swept away.
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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊