session list is showing all sessions not only the ones scopes to the curent dir #6441

Open
opened 2026-02-16 18:04:15 -05:00 by yindo · 6 comments
Owner

Originally created by @luisrudge on GitHub (Jan 16, 2026).

Originally assigned to: @rekram1-node on GitHub.

Description

see title

Plugins

opencode-anthropic-auth, @franlol/opencode-md-table-formatter

OpenCode version

1.1.23

Steps to reproduce

open opencode anywhere and type /sessions
it should load only sessions from that directory, but lists all my sessions

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

Originally created by @luisrudge on GitHub (Jan 16, 2026). Originally assigned to: @rekram1-node on GitHub. ### Description see title ### Plugins opencode-anthropic-auth, @franlol/opencode-md-table-formatter ### OpenCode version 1.1.23 ### Steps to reproduce open opencode anywhere and type /sessions it should load only sessions from that directory, but lists all my sessions ### Screenshot and/or share link _No response_ ### Operating System _No response_ ### Terminal _No response_
yindo added the bug label 2026-02-16 18:04:15 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Jan 16, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #6098: The sessions list seems to show all history, not the sessions history of the working directory
  • #3551: Sessions are now mixed with home directory session list, disregarding which directory you're in
  • #7186: Sessions not displayed in /session for specific project path despite being written to storage

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 16, 2026): This issue might be a duplicate of existing issues. Please check: - #6098: The sessions list seems to show all history, not the sessions history of the working directory - #3551: Sessions are now mixed with home directory session list, disregarding which directory you're in - #7186: Sessions not displayed in /session for specific project path despite being written to storage Feel free to ignore if none of these address your specific case.
Author
Owner

@allisoneer commented on GitHub (Jan 21, 2026):

This is from Claude:

I've done some research on this issue and wanted to share findings on the existing PRs and a potentially more complete approach.

Existing PR Analysis

PR #8886 (client-side filtering in dialog only):

  • Only filters the session list dialog UI display
  • Does NOT filter the bootstrap session list fetch (initial load still fetches all sessions)
  • Does NOT filter real-time session.updated events (cross-directory sessions can still appear via SSE)
  • Does NOT filter session search results
  • Result: Sessions from other directories can still leak through via bootstrap, search, or real-time events

PR #6724 (server-side default filtering):

  • Changes Session.list() default behavior for ALL clients (web UI, API consumers, CLI)
  • Requires new --all flag and ?all=true query param for opt-out
  • More invasive change that affects the API contract
  • Web UI and other consumers may want cross-directory visibility by default

Proposed Alternative: TUI-only, use existing API

The API already supports GET /session?directory=<path> (exact match filter) - it's just never wired up in the TUI. A more complete TUI-only fix would:

  1. Pass directory param to bootstrap session.list call in sync.tsx
  2. Pass directory param to session search in dialog-session-list.tsx
  3. Filter session.updated real-time events by directory (early break if mismatch)
  4. Pass directory: cwd to tui() call for SDK context

Why this approach?

  • Uses existing API infrastructure (no server changes, no new flags)
  • Filters ALL entry points: bootstrap, search, AND real-time events
  • No behavior change for web UI or other API consumers
  • Purely additive - doesn't change any defaults or require opt-out mechanisms

Known limitation: Uses exact directory match (existing API behavior). Sessions created from a subdirectory won't appear when TUI is launched from repo root. This is acceptable for the worktree use case and could be improved later with prefix matching if needed.

I have a working implementation of this approach and happy to submit a PR if maintainers prefer this direction over the existing PRs.

@allisoneer commented on GitHub (Jan 21, 2026): This is from Claude: I've done some research on this issue and wanted to share findings on the existing PRs and a potentially more complete approach. ## Existing PR Analysis **PR #8886** (client-side filtering in dialog only): - Only filters the session list dialog UI display - Does NOT filter the bootstrap session list fetch (initial load still fetches all sessions) - Does NOT filter real-time `session.updated` events (cross-directory sessions can still appear via SSE) - Does NOT filter session search results - Result: Sessions from other directories can still leak through via bootstrap, search, or real-time events **PR #6724** (server-side default filtering): - Changes `Session.list()` default behavior for ALL clients (web UI, API consumers, CLI) - Requires new `--all` flag and `?all=true` query param for opt-out - More invasive change that affects the API contract - Web UI and other consumers may want cross-directory visibility by default ## Proposed Alternative: TUI-only, use existing API The API already supports `GET /session?directory=<path>` (exact match filter) - it's just never wired up in the TUI. A more complete TUI-only fix would: 1. Pass `directory` param to bootstrap `session.list` call in `sync.tsx` 2. Pass `directory` param to session search in `dialog-session-list.tsx` 3. Filter `session.updated` real-time events by directory (early break if mismatch) 4. Pass `directory: cwd` to `tui()` call for SDK context **Why this approach?** - Uses existing API infrastructure (no server changes, no new flags) - Filters ALL entry points: bootstrap, search, AND real-time events - No behavior change for web UI or other API consumers - Purely additive - doesn't change any defaults or require opt-out mechanisms **Known limitation**: Uses exact directory match (existing API behavior). Sessions created from a subdirectory won't appear when TUI is launched from repo root. This is acceptable for the worktree use case and could be improved later with prefix matching if needed. I have a working implementation of this approach and happy to submit a PR if maintainers prefer this direction over the existing PRs.
Author
Owner

@rekram1-node commented on GitHub (Jan 21, 2026):

Is this a git project? because in git projects it is scoped, everything else is global

@rekram1-node commented on GitHub (Jan 21, 2026): Is this a git project? because in git projects it is scoped, everything else is global
Author
Owner

@allisoneer commented on GitHub (Feb 5, 2026):

Is this a git project? because in git projects it is scoped, everything else is global

It is a git project! I want scoped to each worktree in that git project instead of just scoped to the git project as a whole.

@allisoneer commented on GitHub (Feb 5, 2026): > Is this a git project? because in git projects it is scoped, everything else is global It is a git project! I want scoped to each worktree in that git project instead of just scoped to the git project as a whole.
Author
Owner

@alexprudhomme commented on GitHub (Feb 5, 2026):

I have the same issue when working with worktrees. When using the --continue flag, it resumes the last session in whatever worktree. Ideally it would resume the session in that particular worktree.

@alexprudhomme commented on GitHub (Feb 5, 2026): I have the same issue when working with worktrees. When using the --continue flag, it resumes the last session in whatever worktree. Ideally it would resume the session in that particular worktree.
Author
Owner

@alexprudhomme commented on GitHub (Feb 5, 2026):

Is this a git project? because in git projects it is scoped, everything else is global

Hi @rekram1-node, I am having the same issue because of git worktrees. I am available to work on this if you can provide some instructions regarding where the fix should be. Should the fix be on the server and affect all clients or should this be a fix only for the TUI ? Let me know and I can provide a PR.

@alexprudhomme commented on GitHub (Feb 5, 2026): > Is this a git project? because in git projects it is scoped, everything else is global Hi @rekram1-node, I am having the same issue because of git worktrees. I am available to work on this if you can provide some instructions regarding where the fix should be. Should the fix be on the server and affect all clients or should this be a fix only for the TUI ? Let me know and I can provide a PR.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#6441