Per-project semantic search over your Claude Code session history — not a shared or centralized memory store. Indexes JSONL transcripts into a local SQLite file, retrieves via bge-m3 embeddings (Ollama) with automatic FTS5 BM25 fallback, and auto-injects relevant past context at session start. Companion to session-end: session-end gives "where I left off," session-indexer gives "what we decided" — same Stop/SessionStart hooks. Apache 2.0, 75 passing tests, go install and nothing to deploy.
What's great
Solves a real problem with long Claude Code sessions - I've asked "why did we decide to do it this way" three weeks into a project more than once and had to scroll back through JSONL transcripts to find the answer. Being fully local (SQLite index, no shared backend) and pairing it with the same Stop/SessionStart hooks as session-end means it doesn't add any new workflow to remember, it just runs. Install was quick and the FTS5 fallback means it still works even without Ollama running.
What needs improvement
No visibility yet into what got indexed - a small CLI command to list or search what's actually in the local SQLite store would help build trust before relying on the auto-injected context, especially on a project with years of session history.
vs Alternatives
I looked at just grepping the raw JSONL files myself, and a couple of the "AI memory" tools that centralize everything in one shared store across projects. This felt like the better fit since it stays per-project and doesn't ship anything off my machine.
Ratings
Ease of use
Reliability
Value for money
Customization
Report
10 views
Thanks for the detailed review, especially the "vs alternatives" framing — that's exactly the tradeoff I built this around.
On visibility: `stats` already gets you partway there —
$ session-indexer stats --db .claude/sessions.db
Sessions indexed: 1
Chunks total: 13405
With embeddings: 13401 (4 pending)
Facts current: 28673
Oldest entry: 2026-06-12
Newest entry: 2026-08-26
DB size: 76.6 MB
and `search <query> --json` lets you inspect exactly what matches a given topic before trusting the auto-injected context.
What's genuinely missing, and what I think you're actually pointing at: there's no way to browse the store without already knowing what to search for — no "show me the last N chunks" or "dump everything from project X" command. `stats` gives you the aggregate, `search`/`facts search` need a query term, and there's nothing in between. That's a real gap, not just a documentation one. I'll add it to the roadmap.