search: only the ~100 loaded sessions are searchable; main-side searchClaudeSessions (500-pool) is dead code

[grimmerk]

Current behavior (verified 2026-07-12)

Session search only covers the ~100 loaded sessions, and the main-side search API is dead code:

1. Display path: the renderer loads getClaudeSessions(100) (src/switcher-ui.tsx:397) — the merged multi-account timeline sliced to the global top-100 by recency.
2. Search path: the search box filters that same loaded list client-side via filterSessionsLocally (src/switcher-ui.tsx:384-393), matching against projectName/project/firstUserMessage/lastUserMessage/customTitle/branch/PR/assistantResponse/terminalBadge.
3. Dead code: searchClaudeSessions (src/claude-session-utility.ts:186, pool = readClaudeSessions(500), result cap 50) is fully wired — IPC handler search-claude-sessions (src/main.ts:2329) + preload (src/preload.ts:81) — but no renderer code ever calls it.

Impact

With 414 unique sessions currently in history.jsonl (measured), ~314 sessions are unreachable: they are neither displayed nor searchable, no matter what keywords match them. This is a silent gap — the UI gives no hint that older sessions exist.

Notes

• Widening the underlying pool is effectively free: readClaudeSessions caches the FULL unsliced session list (src/claude-session-utility.ts:178); the limits are applied per-call via slice.
• Enrichment fields (branch/PR/AI response/custom title) only exist renderer-side for the loaded 100 — a full fix needs main-side search over all sessions (and all prompts, not just first/last), unioned with the client-side filter, with lazy enrichment for matches outside the loaded set.
• Fix is planned as Batch 1 item A1 in docs/session-finding-plan.md (§4.2) — implemented by PR feat(sessions): Batch 1 — full-prompt search, match snippets, junk fold, highlight fix #132 (the dead searchClaudeSessions path was rewritten into the real main-side full-prompt search).
• Related perf study note: perf: session tab switching performance regression (PR #103) #106 (comment on multi-account × limits).

🤖 On behalf of @grimmerk — generated with Claude Code

[grimmerk]

補充:multi-account × session-list 成本結構(zh-TW 原文;英文版在 #106 comment)

成本分兩段,只有便宜的那段會隨帳號數成長:

Stage A — history.jsonl 掃描(readClaudeSessions,claude-session-utility.ts:109-157):

• 每個帳號的 history.jsonl 整份讀 + 逐行 JSON.parse,合併進同一個 map。這段從來就不受 limit 限制——單帳號時代也是全檔 parse 完才 sort + slice,limit 只裁回傳的 array,不裁掃描量。
• 所以這段成本 = 各帳號 history 檔案大小之和。理論上兩個同樣大的帳號 ≈ x2,但實測:personal 15,324 行 / 6.7MB vs work 142 行 / 50KB → 增量 +0.9%,無感。
• 而且有 5s cache(:70, :99-101),popup 開著期間的重複呼叫直接吃 cache;全檔 parse 本身是 ms 級 in-memory 工作。

Stage B — 真正貴的 per-session 檔案讀取(enrichment:titles/branches/PR links、preview):

• renderer 是 getClaudeSessions(100)(switcher-ui.tsx:397)→ 拿到已切齊的 100 筆,才丟給 loadSessionEnrichment(result.slice(0, 100))(:520)。
• 每-session 開 transcript 檔的數量被 post-merge 的 100 鎖死,跟帳號數無關。

結論:

1. CPU time 不會 ×2——會成長的只有 Stage A(便宜、有 cache、成長量 = 第二帳號 history 的實際大小);Stage B 不變。per-account 的 active-session/status 掃描是每帳號幾個小 PID/status 檔,微不足道。
2. Render 是全局 100 不是 200——兩帳號 merge 後按 lastTimestamp 排序再 slice(0, 100)(:161-180),unified timeline,badge 區分帳號。被切掉的第 101+ 名浪費的只有 history 行 parse,而這在單帳號時代就存在,不是多帳號新增的模式。

這個成本結構是本 issue 修法(main-side 全量搜尋)的前提:搜尋走 Stage A 的 in-memory 資料(便宜、可全量),不碰 Stage B 的 per-file 讀取(貴、維持 ≤100)。

🤖 On behalf of @grimmerk — generated with Claude Code