{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreideko2tomcaezhljouebv7u7xvr36gs5z7fzydazejet6ruatsfk4",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mpsltyr2zlz2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreicneotp3t76xttbldoe55aaiffu6vmt2s27u4pagq4jh6wdax575i"
    },
    "mimeType": "image/webp",
    "size": 83430
  },
  "path": "/valpere/session-indexer-giving-claude-code-a-memory-that-doesnt-die-with-the-project-next-door-3b76",
  "publishedAt": "2026-07-04T07:54:57.000Z",
  "site": "https://dev.to",
  "tags": [
    "claudecode",
    "go",
    "developertools",
    "ai",
    "https://github.com/valpere/session-indexer"
  ],
  "textContent": "I come back to a project after a week off, and the first ten minutes always go the same way: scrolling through old sessions, trying to remember _what we actually decided about X_.\n\nA simple rolling log — \"here's what we did yesterday\" — solves half of that. It doesn't solve \"what have we discussed about this topic, across every session, ever?\"\n\n`session-indexer` is my attempt at the second half.\n\nIt's a small Go tool that indexes Claude Code session transcripts for each project into a local SQLite database and retrieves relevant chunks by semantic similarity when a new session starts.\n\n##  Why not just use a centralized memory tool?\n\nTools like mempalace or agentmemory keep one shared store across every project and every agent. That architecture has one fatal flaw: **if the central store dies, everything dies. **** A corrupted vector index or a crashed MCP server takes down memory for every project you have, simultaneously, and recovery is not trivial.\n\n`session-indexer` does the opposite. `.claude/sessions.db` lives inside the project's own `.claude/` directory. Append-only. If one project's DB gets corrupted, the fix is to delete it and rerun `mine` on the JSONL transcripts already on disk. Nothing else is affected.\n\n##  How it works\n\nTwo hooks, wired into Claude Code's lifecycle:\n\n  * **Stop hook** (`session-index.sh`) — when a session ends, mines the JSONL transcript into `.claude/sessions.db`, embedding each chunk via `bge-m3` (Ollama) if it's available.\n  * **SessionStart hook** (`session-recall.sh`) — when a new session opens, derives a search query from the current git branch name and recent commit messages, searches the index, and injects the top matching chunks as context. No manual query needed — it just knows roughly what you're about to work on.\n\n\n\nManual search works too, any time:\n\n\n\n    session-indexer search \"config validation approach\" --db .claude/sessions.db\n    # or from inside Claude Code:\n    /recall config validation approach\n\n\n##  The CLI\n\n\n    session-indexer mine   <jsonl-path> --db .claude/sessions.db\n    session-indexer search <query>      --db .claude/sessions.db [--limit N] [--json]\n    session-indexer embed               --db .claude/sessions.db\n    session-indexer stats               --db .claude/sessions.db\n\n\n`mine` runs with a 50-second deadline — storage is fast and unconditional; embedding respects the deadline, so it never blows past Claude Code's Stop-hook timeout. Chunks that miss the deadline are stored but flagged for backfill via `embed` — nothing silently disappears.\n\n##  Search quality\n\nWhen Ollama + `bge-m3` are available, search ranks by cosine similarity over 1024-dimension multilingual embeddings — English and Ukrainian both score well, which matters when half my sessions are in one language and half in the other.\n\nWhen Ollama isn't running, or the store has zero embeddings yet, search automatically falls back to FTS5 BM25 keyword matching. No configuration, no hard dependency on an external service that might not be running.\n\n##  Stack\n\n  * **Go 1.26** — single static binary\n  * **SQLite** (`modernc.org/sqlite`, pure Go, no CGO) — one file per project\n  * **Ollama + bge-m3** — optional vector embeddings\n  * **Cobra** — CLI\n  * **FTS5** — automatic fallback\n\n\n\n##  Setup\n\n\n    go install ./cmd/session-indexer\n\n    # wire the hooks (one-time, per project)\n    # copies session-index.sh + session-recall.sh into .claude/hooks/\n    # updates .claude/settings.local.json\n\n\nFull hook-wiring steps are in the README — it's a few JSON entries in `settings.local.json`, nothing exotic.\n\n##  Why this matters to me\n\nMost AI coding assistants either forget everything the moment the session ends, or bolt on a centralized memory service that becomes a single point of failure for your entire workflow. I wanted the boring option: per-project, append-only SQLite. The same architectural instinct that makes Git itself reliable — if it breaks, it breaks alone, and it heals by re-mining transcripts that are already on disk.\n\nOpen source, MIT licensed.\n\nGitHub: **https://github.com/valpere/session-indexer**\n\nIf you're already piling up weeks of Claude Code sessions per project and re-deriving the same decisions from scratch every time you come back, this might save you the ten minutes of scrolling.\n\n_Valentyn Solomko — Ukrainian software engineer_",
  "title": "session-indexer: giving Claude Code a memory that doesn't die with the project next door"
}