session: full-text search across session message content (only titles are searchable today) #53063

Summary

Sessions are the primary artifact opencode accumulates, but their content is not searchable: the session list's search parameter only matches the session title (like(SessionTable.title, ...) in the session store's list query). Once a project has more than a handful of sessions, finding "that conversation where we fixed X" means opening sessions one by one. This proposes full-text search over session message content, built on SQLite's built-in FTS5 — no new dependencies.

Current behavior

• GET /session list accepts search, but the store applies it only to session.title.
• Message content lives in SQLite, so the data needed for retrieval is already there; it is just not indexed.
• No FTS table exists in the migration set today.

Proposal

1. Index: a session_message_fts FTS5 virtual table (contentless or external-content, tied to the message table) created by a standard migration, with a one-time backfill of existing rows.
2. Sync: keep it fresh either via SQLite triggers or at the application write path — see open question 3.
3. API: extend the session list query (or add a dedicated GET /session/search) returning matching sessions plus matched message snippets.
4. TUI: a search entry in the /sessions surface that lists hits with snippets and jumps to the session.

Phased plan

• Phase 1 — migration + backfill + store query + HTTP route (usable from the API, independently mergeable).
• Phase 2 — TUI search surface.
• Phase 3 (optional) — tool-call/output indexing, per-project scoping, ranking tweaks.

I'm happy to implement this; phase 1 alone is a self-contained PR.

Open questions

1. Scope of indexed content: user + assistant text only (my default suggestion), or also tool calls/outputs? Tool output would grow the index much faster.
2. TUI surface: search box inside /sessions, or a separate command?
3. Index maintenance: SQLite triggers (simplest, migration-friendly) vs. writing through the application's message write path (more explicit, matches the event/projector architecture)?
4. Index growth: acceptable to index everything unbounded per project, or should there be a cap/retention knob?