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
11 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.
Report
Dial
this is a real gap - I've had the "what did we decide about X" problem plenty of times across long-running Claude Code sessions. Curious how it behaves for a monorepo setup where frontend and backend live in separate directories but are logically one project - does the per-project indexing stay strictly siloed to each directory, or is there a way to point it at a shared index across a few related repos?
@galdayan For the frontend/backend-as-subdirectories case: you're already covered. Both hooks resolve the DB path via `git rev-parse --show-toplevel`, not cwd, so every session anywhere under that one repo writes to the same `.claude/sessions.db` at the root. No siloing there — it's effectively already a shared index for the whole monorepo.
For pointing it at a shared index across a few separate repos: not out of the box today — each repo's hooks resolve their own toplevel, so each gets its own DB by default. But `mine`/`search`/`embed`/`stats` all take an explicit `--db <path>`, so nothing in the tool itself enforces the isolation — you can point multiple repos' hooks at one shared file path manually (edit the `DB=` line in `.claude/hooks/*.sh`). It's just not a documented/first-class option yet. Worth exposing properly though — thanks for raising it, I'll think about an opt-in config value for it rather than making it the default, since per-project isolation is the whole point for people who do want strict siloing.