Conversation search and retrieval for Claude Code agents

[amahpour]

Problem

When working on a project, I frequently need to find a past conversation — e.g., "last Friday we reviewed Discord feedback and created tickets, but there were 4 outstanding items." Today I used AgentsView running locally to search through past sessions and retrieve the exact conversation. It worked really well, but ideally this capability lives natively in Command Center.

What I did with AgentsView (the workflow to replicate)

1. Full-text search across all message content — GET /api/v1/search?q=discord+feedback&sort=recency instantly found the session via SQLite FTS5
2. Date-filtered session listing — GET /api/v1/sessions?date=2026-03-27 narrowed to a specific day
3. Message-level retrieval — GET /api/v1/sessions/{id}/messages let me read through the full conversation and extract the 4 outstanding items that never became tickets

The whole thing was curl calls from a Claude Code session against AgentsView's REST API. The key insight: a Claude Code agent can search its own past conversations to recover context — things like decisions made, items deferred, feedback reviewed, etc.

Feature request

Add conversation search and retrieval so that Claude Code agents (and the dashboard UI) can find and read past sessions.

Three possible approaches

Option A: Hook into AgentsView

• AgentsView already indexes Claude Code sessions into SQLite with FTS5
• It has a clean REST API (/api/v1/search, /api/v1/sessions, /api/v1/sessions/{id}/messages)
• Command Center could either proxy to a running AgentsView instance or import its database
• Pros: battle-tested search, multi-agent support (see below), minimal new code
• Cons: external dependency, separate process to run, potential data overlap with our own SQLite

Option B: Implement natively

• Command Center already has SQLite + FTS5 and watches ~/.claude/projects/ JSONL files
• Extend the existing schema to index full message content (not just session metadata)
• Add search API endpoints similar to AgentsView's design
• Pros: single tool, no external dependency, tighter integration with dashboard UI
• Cons: more work, may duplicate what AgentsView already does well

Option C: Hybrid — implement natively + import from AgentsView

• Build our own search natively for Claude Code sessions (our core use case)
• Optionally import/sync from AgentsView's SQLite database to pull in Cursor, Codex, and other agent sessions
• Pros: self-contained for the common case, but can leverage AgentsView's multi-agent indexing when available
• Cons: two code paths to maintain

MCP server vs REST API

Today's workflow used curl against a REST API, but the more powerful approach would be exposing search as an MCP server. This would let Claude Code agents search past conversations natively via tool calls instead of shelling out to curl.

Approach	How an agent uses it	Pros	Cons
REST API only	Agent uses curl via Bash tool	Simple, works today, any HTTP client can use it	Requires the agent to know the URL, parse JSON manually, extra tool call overhead
MCP server	Agent calls search_conversations, get_session_messages as native tools	First-class tool integration, discoverable, typed params/responses, no curl gymnastics	Requires MCP server implementation, must be registered in Claude Code settings
Both	MCP for agents, REST for the dashboard UI	Best of both — dashboard uses REST, agents use MCP	Two interfaces to maintain (though MCP can just wrap the same backend)

The MCP approach is likely the right call long-term. The dashboard already needs a REST API for the web UI, and the MCP server would be a thin wrapper that calls the same search/retrieval logic. Claude Code agents would then have tools like:

• search_conversations(query, project?, sort?, date_from?, date_to?) — full-text search
• list_sessions(project?, date?, date_from?, date_to?) — browse sessions
• get_session_messages(session_id) — retrieve full conversation

Multi-agent coverage

AgentsView supports 12+ agents out of the box: Claude Code, Cursor, Codex, OpenCode, and others. Command Center currently only indexes Claude Code sessions. This is worth considering:

• If we only ever need to search Claude Code conversations, native implementation is fine
• If we want to search across Cursor, Codex, etc. (e.g., "what did I do in Cursor last Tuesday?"), AgentsView already solves this
• A practical middle ground: build native search for Claude Code (our primary use case), and document how to point at an AgentsView instance for cross-agent search if needed

API surface needed (any approach)

Endpoint / Tool	Purpose
search(q, sort=relevance|recency, project?)	Full-text search across message content
list_sessions(date?, date_from?, date_to?, project?)	Filter sessions by date range
get_session_messages(session_id)	Retrieve all messages for a specific session

Key requirements

• Full-text search over message content, not just session titles/first messages
• Date range filtering on sessions
• Message-level access to read through a specific conversation
• Accessible from Claude Code agents — either via MCP tools (preferred) or REST API + curl
• Search should be fast (FTS5 handles this well for local data)

Context

This came up organically: I needed to find 4 outstanding Jira items from a Friday conversation. A Claude Code agent used AgentsView's API to search "discord feedback", found the exact session, pulled the messages, and reconstructed the full list of deferred items. This is the kind of "agent memory" that makes multi-session workflows practical.

Related

• AgentsView repo: https://github.com/wesm/agentsview
• AgentsView API source: internal/server/search.go, internal/server/sessions.go