Sessions dropdown and home sessions list render empty despite successful session-list responses

[aarontrowbridge]

Sessions dropdown and home sessions list render empty despite successful session-list responses

Problem — The web app's Sessions dropdown ("Sessions" toolbar button) and the home page's sessions section render "Nothing here yet" even when the underlying session-list fetch succeeds with a full payload. Reproduced on a plain browser against the hub server (GET /session?directory=<project>&roots=true&limit=55 → 200, 55 sessions, every entry passing the isRootVisibleSession predicate when replayed), while the dropdown still renders the empty state. Deep links to individual sessions render fine, so data and session view are healthy — only the list aggregation surfaces are affected. Fleet clients (MacBook panel over SSH tunnel) are the primary victims: the panel shows no session history at all.

Suspected area — The aggregation path shared by SessionChatsDropdown and the home sessions view: per-directory child stores populated by the session bootstrap, and the directory list they aggregate over (server projects vs persisted open-projects state). Something in that chain drops or never surfaces the fetched sessions; needs runtime instrumentation to pinpoint.

Acceptance Criteria

• With a server holding N root sessions under a project directory, a fresh browser (empty localStorage) shows those sessions in the Sessions dropdown without any manual project-open step.
• Same for the home page sessions section.
• Existing session-view and dropdown tests still pass.

Notes

• Diagnostic trail: fresh-browser reproduction via headless Chromium on the hub host; response payload verified healthy (correct directory, parentID absent, time.updated present); trimSessions keeps all 55 when replayed. The failure is between fetch and render, not in the API.
• Found while investigating "all my sessions disappeared" on the fleet — the data was never lost; the list UI just stopped showing it.