Repository navigation
[QUESTION] Configurable session picker limit (#6138) #20754
Description
Question
Replacement for auto-closed #6137 to keep design discussion active for PR #6138.
Would maintainers accept a narrow session_list_limit setting in tui.json for the TUI session picker?
Proposed scope:
- cap the non-search session picker only, with a default of 150
- preserve the existing server-limited search path
- keep the current session visible when the list is capped
- add focused picker and config tests
This is intentionally not a broader session loading or pagination rewrite. If this narrower picker preference is acceptable, I can keep PR #6138 updated. If not, I can close or rework it.
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Apr 2, 2026
This issue might be a duplicate of existing issues. Please check:
If your request is already covered by one of these, please consider adding context or a +1 there instead of opening a new issue.
[-][FEATURE]: configurable session picker limit[/-][+][QUESTION] configurable session picker limit[/+]CasualDeveloper commentedon Apr 17, 2026
Rebased PR #6138 onto the latest
devagain.Still applies on current
tui.json-backed TUI config architecture. Verified locally withbun run test test/cli/tui/session-list.test.ts,bun run typecheck, andbun turbo typecheck.[-][QUESTION] configurable session picker limit[/-][+][QUESTION] Configurable session picker limit[/+][-][QUESTION] Configurable session picker limit[/-][+][QUESTION] Configurable session picker limit (#6138)[/+]Dhruv-Garg79 commentedon May 8, 2026
is there any temporary solution to this problem?
syo093c commentedon May 9, 2026
You can use opencode webui
jensenojs commentedon May 15, 2026
or https://github.com/sudo-tee/opencode.nvim
CasualDeveloper commentedon Jun 6, 2026
Quick update: the fork branch has been refreshed and synced to origin/dev at 4519a1d.
CasualDeveloper commentedon Jun 16, 2026
Closing this for now.
The original user need is better handled first by fixing the session picker loading architecture, not by adding a config option. The current direction is #31132, which makes the dialog request root sessions directly so child/subagent sessions cannot consume the picker backend limit.
If users still need more control after that lands, the follow-up should probably be pagination/load-more. If a config is accepted anyway, it should be framed as a dialog-local root-session page size, not a render-time cap over shared synced sessions.