You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE]: Filter TUI session list by current directory/worktree #9881
I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Problem: Sessions are shared across all git worktrees of the same repository because they use projectID (first root commit hash) as the storage key. Users working with multiple worktrees see sessions from all worktrees mixed together, making it difficult to find relevant sessions.
Proposed Solution: Wire up the existing directory API filter so the TUI only shows sessions from the current working directory.
The infrastructure already exists:
API supports GET /session?directory=<path> (exact match filter)
tui() accepts a directory prop but it's never passed
SDK supports directory parameter in session.list()
Changes needed (TUI-only, no server changes):
Pass directory: cwd to tui() call in thread.ts
Add directory param to bootstrap session.list call in sync.tsx
Filter session.updated realtime events by directory (prevent cross-worktree sessions appearing)
Add directory param to session search in dialog-session-list.tsx
Alternatives considered:
Server-side auto-filter: Rejected because it changes behavior for all clients (web UI, API consumers may want cross-worktree visibility). TUI-only approach is purely additive.
Plugin approach: Not feasible - no plugin hook exists for session listing.
Hidden session field: Out of scope - separate feature that requires schema changes.
Known limitations:
Uses exact directory match (API behavior). Sessions created from a subdirectory won't appear when TUI is launched from repo root.
No config toggle - filtering is always-on (this is the expected UX for worktree users).
Happy to submit a PR if this approach sounds reasonable.
Feel free to ignore if these don't address your specific case. Issue #8836 in particular seems to describe the exact same symptom you're addressing with this feature request.
Dax please do this it's been so long and the other issue hasn't gone anywhere and it's still an unbelievable pain in the ass and the code changes are very small and detailed accurately above. pretty pretty please.
Activity
github-actions commentedon Jan 21, 2026
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if these don't address your specific case. Issue #8836 in particular seems to describe the exact same symptom you're addressing with this feature request.
allisoneer commentedon Jan 21, 2026
Closing as duplicate of #8836.
The existing issue #8836 tracks this same problem, and there are already two open PRs attempting to fix it:
--allopt-outI've added a comment to #8836 with analysis of these approaches and a proposed more complete solution.
allisoneer commentedon Mar 25, 2026
Dax please do this it's been so long and the other issue hasn't gone anywhere and it's still an unbelievable pain in the ass and the code changes are very small and detailed accurately above. pretty pretty please.
github-actions commentedon Jul 6, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.