fix(cli): session list --max-count not honored, shows too few sessions#14162
Merged
rekram1-node merged 1 commit intoanomalyco:devfrom Feb 18, 2026
Merged
Conversation
The CLI was calling Session.list() with no arguments, hitting a default LIMIT 100 that included child/delegation sessions, then filtering them out in JS. This meant --max-count could never show more than ~24 root sessions. Now passes roots: true and limit: maxCount to the DB query.
Contributor
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #14163
Summary
opencode session listshows far fewer sessions than expected and--max-counthas no effect for values above ~24.Root cause: The CLI handler calls
Session.list()with no arguments, so the DB query appliesLIMIT 100(the default). It then filters out child/delegation sessions in JS, and only after that applies--max-countviaArray.slice(). Since many of the 100 rows are child sessions, the user sees far fewer root sessions than exist — and passing-n 1000can never return more than the ~24 that survive the JS filter.Fix: Pass
roots: trueandlimit: args.maxCounttoSession.list(), matching what the server HTTP API already does. This moves both the parent filter (WHERE parent_id IS NULL) and the limit into the SQL query where they belong. The redundant in-memory sort is also removed sinceSession.list()already returns results ordered bytime_updated DESC.Related: #13877 (same root cause affecting TUI
/sessionspicker)(FYI I am a human being that experienced this bug and wanted a fix. Obviously I prompted an LLM on what to do, etc, but just making clear this fix was the idea of a human being. Love the project)