[Bug]: Sidebar thread search does not search message content

[iamtoled]

Area

apps/web

Steps to reproduce

1. Have a non-archived thread containing a distinctive word in a user message, but not in its title or linked PR metadata.
2. Enter that word in the thread search field at the top of the sidebar.
3. Wait for additional results.

Actual behavior

Sidebar search only returns metadata matches. Threads matching only message content never appear, regardless of how long I wait.

Searching via the command palette (Cmd+K) successfully finds message-content matches on the same installation. The problem is specific to the sidebar search field.

Expected behavior

Show title matches immediately, then add threads whose messages contain the query. Keep title matches first, avoid duplicate threads, and show a short matching message excerpt.

Impact

I cannot find past discussions from the sidebar when I remember their content but not their titles.

Workaround

Use the command palette (Cmd+K). I have confirmed that content search works there, but the difference between the two search entry points is confusing.

Supporting investigation

Source inspection of main at 9375c779707fb95c06670db6da87441720b2d2e2 shows that:

• Sidebar.tsx derives results using only searchSidebarThreads.
• searchSidebarThreads filters titles and PR search terms, without message content.
• CommandPalette.tsx uses useThreadSearch for content results.

Related: #3509 was closed after #4959 added conversation-content search, but the current web sidebar search does not use that capability. #10091 concerns content-search performance; this report concerns the sidebar not invoking content search at all.

Version or commit

Installed version not yet provided. The commit above identifies the source inspected, not the installed version. The reproduction steps are a minimal case for maintainers to verify; no local runtime reproduction was performed during this investigation.

[juliusmarminge]

Triage

Confirmed on main (9375c779707fb95c06670db6da87441720b2d2e2). This is a real web/desktop gap, not a broken search backend.

The sidebar field only runs searchSidebarThreads, which matches thread titles and linked PR terms. It never calls useThreadSearch / orchestration.searchThreads. Command palette (Cmd/Ctrl+K) and mobile thread lists already use that RPC, which is why the same query finds message-content hits there.

This is not a duplicate of #3509 (closed after #4959 added content search) or #10091 (query performance on large histories). #4959 wired the palette and mobile; #4769 added the web sidebar as a local title filter and never connected the RPC. #10870 later added PR metadata to sidebar search, still without message bodies. #7115 tried this exact sidebar wiring and was closed because it bundled unrelated work, not because the idea was rejected. No open fix PR.

Scope: web sidebar (Sidebar.tsx / Sidebar.logic.ts). Desktop wraps web. Mobile already works. Contracts and server search are already in place.

Suggested fix: focused PR only — debounce useThreadSearch for connected environments, merge with existing title/PR hits (titles first, one row per thread), show a short You/Agent excerpt, and keep a pending state while content results load. Follow the palette/mobile pattern. Do not revive #7115 as-is. #10091 is a performance consideration for an extra caller of the same RPC, not a blocker if the existing 2-character debounce is reused.

Workaround remains the command palette.