desktop: home session list stays empty on startup until Home button is clicked #62298

Summary

On desktop startup the Home session list renders empty even though every session exists and the API returns them. The full list query GET /api/session?limit=5000&order=desc&parentID=null is never issued until the user clicks the Home button, which immediately fetches and renders the complete list (258 rows, today/yesterday/older groups).

Environment

• opencode version: 2.2.5 (desktop app 2.2.5-x64; Electron 44.9.1 / Chrome 152; background service opencode-cli.exe serve --service)
• OS: Windows_NT 10.0.19045.0 (win32 x64)
• Terminal: Unavailable: not applicable — this is the OpenCode desktop app (Electron renderer), no terminal attached
• Shell: C:\WINDOWS\system32\cmd.exe
• Install/channel: latest (desktop auto-updater reports up-to-date 2.2.5)
• Active plugins: @tarquinen/opencode-dcp@latest (global ~/.config/opencode/opencode.json); C:\Users\admin\.opencode\opencode.json also lists "plugin": ["oh-my-openagent"]

Reproduction

1. Launch the OpenCode desktop app on a machine with a large session history (762 rows in session_v2, including sessions migrated from V1).
2. Land on Home — the main area shows only the logo and prompt input; the sidebar shows only the open session tabs.
3. Observe that the Home session list is empty (no today / yesterday / older groups).
4. Click the Home button in the sidebar.
5. The full list query fires immediately and the complete history renders without any further interaction.

Expected Behavior

Home shows the recent session groups (today / yesterday / older) on startup, without requiring the user to click Home first.

Actual Behavior

CDP network capture of the first 30s after page load (66 API calls, fetch hook installed in the page):

• Missing: GET /api/session?limit=5000&order=desc&parentID=null (the full list query)
• Also missing: the inbox-sessions parentID=null list query
• Present and OK: /api/event (SSE) 200, /api/info 200, /api/config?location=... 200, GET /api/session/{id} 200, /api/session?limit=200&order=desc&parentID=<id> 200, /api/session/active 200
• No 401s, no timeouts; only two unrelated /api/fs/list 404s in console

Clicking Home issues GET /api/session?limit=5000&order=desc&parentID=null => 200 and the list renders. Timing is not the trigger: clicking Home 0.5s after load (SSE established at 0.3s) also returns 200 and renders 258 rows.

Relevant desktop renderer bundle code (minified, names preserved):

c = mX(() => {
  let t = e.server.focusedContext();
  return {
    ...pKt(e.server.focused(), t),
    enabled: !!t && t.sdk.connection.status() === `connected`,
  };
});

// pKt: queryKey [`home-sessions`, server], retry: false, staleTime: 30_000,
//      gcTime: Infinity, refetchOnMount: true, refetchOnReconnect: true
// nKt only sends { limit: 5000, order: `desc`, parentID: null, cursor } —
// no directory/project filter, so a successful call always returns the full list.

l = A(() => {
  let t = e.server.focusedContext(), n = e.server.focused();
  return !t || !n
    ? []
    : iKt(t.data.session.apply(
        rKt(c.isPending ? [] : c.data?.() ?? [], t.data.session.list()),
        64, Date.now()));
});

Because the query never starts, c.isPending stays true and the list falls back to whatever is already in the in-memory store — which is why only the 3 recently used sessions appear.

Additional Context

• Not a data problem: all 665 V1 sessions were migrated into session_v2 (762 total) and GET /api/session returns them all when called directly.
• Not directory/project scoping: after clicking Home, sessions from both D:\... and C:\ directories render, so no directory whitelist was applied.
• Not a failed request: the server log records failed responses (401/503/404 are logged), and there is no failed /api/session list response — the request is never sent, not rejected.
• Sidebar rows are tabs, not history: the sidebar items are open session tabs (each has a close button). One tab has title = null and falls back to the localized "session" label.
• Config guard suspicion: enabled depends on connection.status() === 'connected' and retry: false means the query never recovers on its own; a similarly guarded /api/config query does fire, so the connection state itself appears healthy at startup.
• Workaround: clicking Home (or searching with the session search) immediately restores the list.
• Frequency: reproduced consistently on every cold start observed in this session; restart does not fix it by itself.