Sessions list not listing all items

[saitoh183]

In the screen shot, it say 123 WebUI sessions but the list doesnt load all of them. when you get to the bottom, you only have the Select Button.

[nesquena-hermes]

Summary

Thanks for the screenshot — the "123 WebUI sessions" header and a shorter visible list aren't a load failure or a hidden pagination cap. The sidebar does load every session the server returns; the mismatch is that the count in the tab label is computed before the list is collapsed and filtered, so the number is almost always larger than the rows you can scroll through. When you reach the bottom and see only the Select button, that's the genuine end of the (collapsed) list.

Code reference

The "WebUI sessions (N)" label comes from static/sessions.js:1348-1351:

function _sessionSourceLabel(filter, count) {
  const n = Number(count) || 0;
  return filter === 'cli' ? `CLI sessions (${n})` : `WebUI sessions (${n})`;
}

That count is webuiSessionCount from _partitionSidebarSessionRows (static/sessions.js:4669-4676), which only skips rows with no visible messages:

for(const s of allMatched){
  if(!_sidebarRowHasVisibleMessages(s, activeSidForSidebar)) continue;
  if(_isCliSession(s)) cliSessionCount++;
  else webuiSessionCount++;
}

But the rows you actually see (sessionsRaw, same function lines 4687-4695) are additionally dropped for s.default_hidden, the active project filter, and s.archived (unless "show archived" is on). Then before render they pass through two collapsing passes:

• _collapseSessionLineageForSidebar (static/sessions.js:4370-4401) folds every session sharing a lineage key — e.g. compression-continuation segments — into one row carrying _lineage_collapsed_count.
• _attachChildSessionsToSidebarRows (static/sessions.js:4309) nests child/subagent sessions under their parent instead of listing them top-level.

So 123 underlying WebUI sessions can legitimately render as far fewer top-level rows.

Diagnosis

This is a label-vs-rows inconsistency, not lost data. The dominant contributor is usually lineage collapse (compression segments + child sessions) and archived rows. I confirmed there's no server-side cap truncating WebUI sessions — _cap_recent_cli_sessions (api/routes.py:3540-3554) caps CLI sessions at 20 only; WebUI rows are returned in full.

Recommendation

The cleanest fix is to make the tab count agree with what's rendered: compute webuiSessionCount from the post-collapse/post-filter sessions array (the same list fed to the DOM at renderSessionListFromCache ~static/sessions.js:4737) rather than from raw allMatched. If the intent is instead to advertise the true total, the label could read WebUI sessions (12 of 123) so the gap is explained rather than surprising.

If your situation is actually different — e.g. the visible count is far below 123 even with archived shown and no project filter — it'd help to confirm whether the missing ones are archived, project-scoped, or compression segments. A quick check: toggle "Show archived" and clear any project chip; if the row count jumps, it's the filter/collapse path above. If it stays low, that'd point somewhere else and is worth a follow-up with the session counts by state.

[nesquena-hermes]

Fixed in v0.51.373 (Release ML) via #4055 — thanks @rodboev.

The sidebar source-filter counts (WebUI / CLI) now match the rows actually rendered — counts come from the same collapse-and-attach pass used to render each source.

Deployed to production and live.