The Sessions page's list and its session count came from two different
lengths: the count is over every session (statsFor's Overview), while
GET /api/sessions fell back to sessions.Limit (200) when the page asked for
no number — and the page never asks for one. So the page said "238 sessions"
over a list of 200, and each agent whose sessions were oldest lost them
whole: Codex had 121 sessions here and the list showed 7, OpenCode 33 showed
2, ZCode 20 showed 3.
* sessions.All (5000) is what a listing that means every session asks for,
and the endpoint reads it when no number is asked of it; a caller that
asks for one still gets it. It lives in internal/sessions so the page, the
TUI and the CLI ask for the same number.
* sessions.Limit stays 200 and is not raised: traceRecentFiles sizes the
window gateway attribution is judged over by it (TraceSessionVisible
decides whether a session has a readable local transcript), so raising it
would change which calls count as magpie's.
* The page draws that list in pages: SESS_PAGE (200) rows, and "Show N
more" appends the next. A filter click or a keystroke in Search draws the
first page and no more, so the cost does not grow with the history. The
data stays complete, so the count and the list still agree. A list served
4000 sessions long rebuilt every row on every keystroke — 275–320 ms a
keystroke on a fast Mac with very small rows, worse on Windows — and now
draws 200.
* The note under the list counts the list the filters kept, not every
session on the computer: it says "showing {drawn} of {n}" while pages are
left and "{n} session"/"{n} sessions" once the whole list is drawn. Before
it counted the whole history beside the drawn rows, so a search matching
one session read "the list holds all 2600, 1 drawn" — as if 2599 were
behind a "Show more" that isn't there. It also no longer says "drawn",
which is how the page is built, not what a reader sees.
* The CLI read sessions.List(0) — 200 — and then cut to its own --limit, so
--limit 500 could never show more than 200 and the "%d more with --limit"
foot was counted off the truncated list. It reads the whole set now; only
o.limit rows are printed, so that costs a parse, not output.
* The TUI read List(0) beside a head that says how many sessions there are,
and then List(sessions.Limit+1) — 201, still not the whole set. It reads
sessions.All now.
What the wider list costs is unchanged: every session file is read either way
to sort by last activity. Measured here with 384 sessions and 84.5k calls:
cold List(200) 10.3 s, List(5000) 10.5 s. What it adds is per-row work while
List holds the lock — a Codex session's titles stat, a pi session's omp
look-up, 25× the rows of JSON — hundreds of milliseconds, not seconds.
Tests, each failing without its change:
* TestSessionsListIsAsLongAsTheCount (internal/gui): 205 Claude Code
sessions as Claude Code keeps them; all 205 with no number asked, 5 with
?limit=5, 201 with ?limit=201. Fails with the list holding 200.
* TestSessionsListIsNotCutAtTheLimit (internal/tui): 210 sessions, of which
the ten past sessions.Limit are all in the list. Fails at 201.
* TestSessionsMoreCountsTheWholeSet (root): the default --limit 20 over 212
sessions says "192 more with --limit", and --limit 205 prints 205 rows.
Fails saying 180 (counted off the truncated list).
* sessions-paging.test.cjs (Chromium and WebKit, en and zh): 2600 sessions;
the first page is 200 rows with "Show 200 more", the button appends to
600 with the rows above left in place, a keystroke in Search draws a page
in under 250 ms and starts the pages again, a search matching one session
reads "1 session" and never the 2600 on the computer, and the note follows
the list the filters kept (200 of 1111 after that search). Fails on
origin/main (200 rows are not a page there) and with the pages taken out;
counting every session again, or writing "1 sessions", fails it too.
Verified: go vet; go build (windows); go test ./internal/sessions
./internal/tui ./internal/gui . — only what origin/main fails (TestCursor,
TestGatewayFixQuitsOnlyAMagpie, TestPurposeAssetMatchesUsage,
TestUpdateThatWontStart, TestPluginListSaysMiddleware,
TestPluginOnOffRmShortName); node --check app.js and i18n.js; the browser
suites above plus sessions-overview, sessions-today, sessions-usage-open,
sessions-toolbar, sessions-calendar-fill, usage-sessions-agents-fit,
i18n-keys, usage-ledger and click-scroll.
Co-authored-by: wizzy-yang <wizzy-yang@users.noreply.github.com>
