Web: Sidebar session list hides worktree/sandbox sessions after 1.2.6 upgrade (filters to current directory only) #14082

Activity

1. benoitheinrich

   added

   bugSomething isn't workingSomething isn't working

   on Feb 18, 2026
2. benoitheinrich commented on Feb 18, 2026

   

   benoitheinrich

   on Feb 18, 2026

   Last edited by benoitheinrich

   Author

   More actions

   Key evidence (API vs Web UI mismatch)

   1) The web server API does return root sessions across multiple directories (repo + worktrees)

   If I query the server in the repo context, GET /session?roots=true returns sessions whose directory spans multiple worktree dirs:

   curl -fsS \
     -H "x-opencode-directory: /home/USER/dev/REPO" \
     "http://127.0.0.1:4096/session?roots=true&limit=1000" \
   | jq -r '[.[].directory] | group_by(.) | map({dir:.[0], count:length}) | sort_by(.count) | .[] | "\(.count)\t\(.dir)"'

   Example output shape (counts vary, but note multiple directories):

   28  /home/USER/dev/REPO
   8   /home/USER/dev/_wt/REPO-WT-1
   2   /home/USER/dev/_wt/REPO-WT-2
   ...
   

   So the backend can see and return root sessions for worktree dirs.

   2) Web UI bundle shows filtering to current directory only (roots + unarchived + directory equality)

   From the downloaded web bundle (minified), two relevant snippets:
   (a) Session list API call is directory-scoped + roots-only (via oX)

   async function oX(t){
     try {
       return {
         data: (await t.list({ directory: t.directory, roots: !0, limit: t.limit })).data,
         limited: !0
       }
     } catch {
       return t.onFallback(), {
         data: (await t.list({ directory: t.directory, roots: !0 })).data,
         limited: !1
       }
     }
   }

   (b) Sidebar list filters sessions to session.directory === currentDirectory (plus root + unarchived)

   const Xle = (s, dir) =>
     normalize(s.directory) === normalize(dir) &&
     !s.parentID &&
     !s.time?.archived;
   zl = (t, now) =>
     t.session
      .filter(s => Xle(s, t.path.directory))
      .sort(sortByRecent(now));

   This matches the observed symptom exactly: the Web UI sidebar shows only root/unarchived sessions whose session.directory equals the currently selected directory, excluding worktree directories.

   ---

   What I expected

   When opening the main repo project in Web UI, the sidebar session list should include sessions for:

   • the main repo directory and
   • all worktree/sandbox directories belonging to the same project (or offer a toggle like “This directory” vs “Whole project incl. worktrees/sandboxes”)
     This used to work for me on 1.2.5, and I rely on it to navigate sessions across many worktrees.

   What actually happens

   On 1.2.6, the Web UI sidebar only shows sessions whose session.directory equals the main repo directory (e.g. 28), while TUI/CLI show all sessions and the server API can return root sessions across multiple worktree directories.

   ---

   Attempted fixes / ruled out

   Duplicate project rows + merging project IDs in SQLite did not fix it

   My SQLite DB (~/.local/share/opencode/opencode.db) had duplicate project rows for the same worktree path. I wrote and ran a safe script to merge duplicate project IDs and re-associate sessions under one canonical project row (with backups + revert).
   Result:

   • The merge succeeded (sessions moved/merged under one project row)
   • But the Web UI behavior did not change: it still only shows sessions for the current directory and hides worktree directory sessions.

   So this does not appear to be simply “Web UI picking the wrong project id”.

   ---

   Regression note (1.2.5 -> 1.2.6)

   This behavior started after upgrading from 1.2.5 to 1.2.6. On 1.2.5, Web UI showed worktree/sandbox sessions for this repo in the sidebar.

   Possibly related changes / commits

   I don’t know the exact offending commit yet, but this seems in the same area as:

   • Sidebar / session-list directory filtering logic (exact directory match)
   • Pagination / “load more” / sidebar session fetching changes
     One relevant merged fix in this area:
   • fix(desktop): "load more" button behavior in desktop sidebar #8430 (merged commit: 077ca4454f152176328496bf0ab3b3d44c2fba9d)
     And some related (but currently open) PRs that touch directory filtering / session list behavior:
   • feat(session): filter sessions by current directory #6724 (feat(session): filter sessions by current directory)
   • perf: filter archived sessions and sort by update time in session list API #6807 (perf: filter archived sessions and sort by update time in session list API)

   ---

   Suggested direction / fix ideas

   If worktrees/sandboxes are a supported concept in Web UI:

   • When the current project has multiple sandboxes/worktrees, the sidebar should include sessions across those directories (or provide a toggle).
   • Alternatively, the sidebar could group sessions by directory and include each sandbox/worktree directory under the same project.
     Happy to provide more sanitized diagnostics if needed (e.g. /project/current output showing sandboxes, additional /session queries, etc.).
3. github-actions

   assigned

   adamdotdevin

   on Feb 18, 2026
4. github-actions

   added

   webRelates to opencode on web / desktopRelates to opencode on web / desktop

   on Feb 18, 2026
5. Relicus commented on Feb 18, 2026

   

   Relicus

   on Feb 18, 2026

   More actions

   really degraded after "v1.1.65".. I've just reverted back.
6. benoitheinrich commented on Feb 18, 2026

   

   benoitheinrich

   on Feb 18, 2026

   Author

   More actions

   I tried reverted back to 1.1.65 but still have same problem, I thought that downgrading to 1.2.5 would fix the problem but it didn't.
7. benoitheinrich commented on Feb 18, 2026

   

   benoitheinrich

   on Feb 18, 2026

   Author

   More actions

   @adamdotdevin I see that you're assigned to this issue, do you want me to give it a try and fix it ?
8. Relicus commented on Feb 18, 2026

   

   Relicus

   on Feb 18, 2026

   Last edited by Relicus

   More actions

   Yeah. Same. Opecode isn’t working now. I think have to do a fresh install or something of old version. But I stopped using it. Im using CLI version now and gone back to antigravity
9. benoitheinrich commented on Feb 19, 2026

   

   benoitheinrich

   on Feb 19, 2026

   Author

   More actions

   I dug deeper into this and can reproduce a related (and I think underlying) failure mode in the current dev backend when using git worktrees/sandboxes. This affects both the Web UI and the TUI depending on which directory you open from.

   What I observed (real reproduction)

   Setup:

   • Backend started from source on a separate port (e.g. serve --port 4097) because my stable install runs on 4096.
   • Project: /home/benoit/dev/sfp-3pl-approval
   • Sandbox/worktree: /home/benoit/dev/_wt/sfp-3pl-approval-SFP-81755

   A root session that clearly belongs to that sandbox exists:

   • title: "Regenerating springSBOM.json and helidonSBOM.json files"
   • id: ses_398fcc074ffeX7XQLbikuQsdNP
   • projectID: 930a00aa130185a96d9860997d5c190eb37da4be
   • directory: /home/benoit/dev/_wt/sfp-3pl-approval-SFP-81755

   You can find it via the API when scoped to the main worktree (header scope):

   • curl -H "x-opencode-directory: /home/benoit/dev/sfp-3pl-approval" --get http://localhost:4097/session --data-urlencode "search=Regenerating springSBOM.json and helidonSBOM.json files" --data-urlencode "limit=50"

   But in the Web UI (workspaces enabled), I see one request per workspace like:

   • GET /session?directory=<workspaceRoot>&roots=true&limit=...

   And here is the key mismatch:

   • GET /project/current?directory=/home/benoit/dev/sfp-3pl-approval returns project id 930a...
   • GET /project/current?directory=/home/benoit/dev/_wt/sfp-3pl-approval-SFP-81755 returns project id 45063dff81483b2c49f6c95b53a7074e2f5c49b5

   So when the UI requests:

   • GET /session?directory=/home/benoit/dev/_wt/sfp-3pl-approval-SFP-81755&roots=true...

   it runs under project 45063... and returns [], even though there is a root session whose directory is exactly that sandbox root — because the session is stored under projectID 930a....

   This is not just hypothetical: GET /project shows two project rows with the same worktree path /home/benoit/dev/sfp-3pl-approval but different ids (930a... and 45063...), and sessions are split across them.

   Also affects the TUI (important)

   This also affects the TUI when you open/attach it from the sandbox directory:

   • If you open/attach the TUI from a sandbox path that resolves to the “other” project ID, you won’t see the “old” sessions that were created under the original project ID.
   • If you create new sessions while in that sandbox, those new sessions show up (because they’re created under the sandbox’s currently-resolved project ID), and they also show up in the Web UI for that workspace. But older sessions remain “missing” in that scope.

   So this is a project identity split across worktrees, not only a UI rendering problem.

   Why this happens (code pointers)

   Project ID resolution for git repos happens in:

   • packages/opencode/src/project/project.ts (Project.fromDirectory())

   Key details:

   • ID is seeded from git rev-list --max-parents=0 --all and it caches the chosen ID in .git/opencode.
   • In git worktrees, .git is per-worktree (and can be a file pointing elsewhere), so the cache can diverge across worktrees.
   • rev-list --all can yield different refs depending on worktree context, so the computed ID can differ.

   Session listing is consistently filtered by the resolved project ID at the DB layer:

   • packages/opencode/src/session/index.ts (Session.list() uses eq(SessionTable.project_id, Instance.project.id) and optionally eq(SessionTable.directory, input.directory))

   So once a repo ends up with two project IDs, sessions created under one ID won't show up when the server resolves the instance to the other ID.

   Proposed fix (minimal + durable)

   There are two parts; doing only one is likely insufficient long-term:

   1. Stabilize project ID resolution across worktrees:

   • Prefer a stable seed (e.g. compute roots from HEAD instead of --all, or otherwise ensure worktree-invariant behavior).
   • Cache the computed ID in the git common dir (e.g. via git rev-parse --git-common-dir) so all worktrees share the same cache, rather than per-worktree .git/opencode.

   2. One-time reconciliation for users already affected:

   • Detect duplicate project rows that share the same worktree but have different id.
   • Migrate sessions from the duplicate project id(s) to the canonical one, merge sandboxes, then remove duplicates.
     (Otherwise existing “old” sessions remain invisible depending on which worktree the instance resolves to.)

   Background / when this likely started (git revs + versions)

   Relevant commits:

   • 0b4af9522 (2026-01-03) "core: add sandbox support for git worktrees..." (introduces sandbox/worktree project id + .git/opencode cache behavior)
   • b02075844 (2026-02-14) "tui: show all project sessions from any working directory" (makes split more visible in TUI behavior)
   • 68bb8ce1d (2026-02-14) "core: filter sessions at database level..." (makes scoping by project_id consistent; per-workspace directory requests now strictly filtered)
   • 6d95f0d14 (2026-02-14) "sqlite again (sqlite again #10597)" (storage changes around this timeframe)

   Release tags containing these:

   • 0b4af9522 is in v1.1.1 (first release tag that contains the sandbox/worktree support commit)
   • b02075844 is in v1.2.1
   • 68bb8ce1d is in v1.2.2 (and thus also in v1.2.6)

   So affected users are most likely those who ended up with duplicated project ids for the same repo across worktrees, typically from earlier runs / differing worktree contexts.

   Happy to provide exact curl commands / additional data if helpful.

   👀React with 👀1Reacted by M. Lanza
10. benoitheinrich commented on Feb 19, 2026

    

    benoitheinrich

    on Feb 19, 2026

    Author

    More actions

    I've got a working fix and I'll be submitting a PR very soon, I tested locally and my worktrees are back :)

    
11. benoitheinrich commented on Feb 19, 2026

    

    benoitheinrich

    on Feb 19, 2026

    Author

    More actions

    PR for this available here #14287

    🎉React with 🎉1Reacted by Dan Simpson
12. github-actions commented on Apr 21, 2026

    

    github-actionsBot

    on Apr 21, 2026 – with GitHub Actions

    Contributor

    More actions

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
13. github-actions

    closed this as completedon Apr 21, 2026