benydev
Architecture

J'ai construit un MCP server pour indexer 212 sessions Claude Code

Comment j'ai transformé 212 sessions de travail avec Claude Code en une base de données searchable, avec Electron, SQLite et le protocole MCP — architecture, décisions techniques et retours après 3 mois d'utilisation.

Le problème

Depuis fin 2025, j'utilise Claude Code au quotidien pour tout : architecture, debug, refactoring, stratégie produit. Au bout de 3 mois, j'avais accumulé 212 sessions — soit des milliers d'échanges contenant des décisions techniques, des snippets, des retours d'expérience.

Le problème : impossible de retrouver quoi que ce soit. "Dans quelle session j'avais résolu ce bug Prisma ?" → impossible à retrouver nativement.

Ma solution : construire un Claude Session Manager — une app Electron qui indexe toutes les sessions et expose un MCP server pour les interroger depuis Claude Code lui-même.

Architecture générale

claude-session-manager/
├── main/                    # Process Electron (Node.js)
│   ├── mcp-server.ts        # MCP server (stdio transport)
│   ├── indexer.ts           # Parse et indexe les .jsonl
│   └── db.ts                # SQLite via better-sqlite3
├── src/                     # Process renderer (Next.js)
│   ├── app/sessions/        # UI de recherche
│   └── components/terminal/ # Terminal PTY intégré
└── electron.ts              # Entry point Electron

La stack : Electron 33, Next.js 15 (renderer), SQLite (better-sqlite3, synchrone), MCP SDK (@modelcontextprotocol/sdk).

Le MCP server

MCP (Model Context Protocol) est un protocole créé par Anthropic pour brancher des outils sur Claude. Le transport utilisé ici est stdio : Claude Code lance le process MCP comme un subprocess, et ils communiquent via stdin/stdout en JSON-RPC.

5 outils exposés :

const tools = [
  'list_sessions',          // Liste les sessions récentes
  'get_session',            // Détails d'une session
  'get_session_messages',   // Messages d'une session
  'search_sessions',        // Recherche full-text (SQLite FTS5)
  'get_recent_sessions',    // Sessions des N derniers jours
]

La config côté .claude/settings.json :

{
  "mcpServers": {
    "claude-session-manager": {
      "command": "node",
      "args": ["/path/to/claude-session-manager/dist/mcp-server.js"]
    }
  }
}

L'indexation SQLite FTS5

Les sessions Claude Code sont stockées dans ~/.claude/projects/*/*.jsonl — un fichier JSON-Lines par session. Chaque ligne est un message (user, assistant, tool result…).

J'utilise SQLite FTS5 (Full-Text Search) pour indexer le contenu :

CREATE VIRTUAL TABLE session_fts USING fts5(
  session_id,
  content,
  tokenize = 'porter unicode61'
);

Le tokenizer porter fait du stemming anglais — "building" matche "built". Pour du français, c'est imparfait, mais suffisant pour du contenu technique mixte FR/EN.

Résultat : recherche full-text en < 10ms sur 212 sessions, 50k+ messages.

Le terminal PTY intégré

Bonus inattendu utile : j'ai ajouté un terminal PTY (pseudo-terminal) dans le renderer Electron, via node-pty. Ça permet de reprendre des sessions Claude directement depuis l'app (claude -r <session-id>) sans switcher de fenêtre.

// main process
import * as pty from 'node-pty'

const shell = pty.spawn('zsh', [], {
  name: 'xterm-color',
  cols: 80, rows: 30,
  cwd: process.cwd(),
  env: process.env,
})

La communication renderer ↔ main passe par IPC Electron (ipcMain/ipcRenderer), avec un canal dédié par tab de terminal.

Ce que j'ai appris

1. Electron + Next.js, c'est pas magique Next.js est pensé pour le web. Electron ajoute un process Node.js natif séparé. Faire cohabiter les deux demande une config build non triviale : le renderer compile en mode export (statique), le main en CommonJS Node.js.

2. SQLite synchrone, c'est intentionnel J'ai failli utiliser Prisma. Erreur. Prisma avec SQLite en Electron = complications d'accès concurrent entre le renderer et le main process. better-sqlite3 est synchrone, mono-process, zero config. Parfait pour ce cas d'usage.

3. MCP, protocole simple mais puissant Le protocole est surprenamment simple à implémenter (JSON-RPC over stdio, une poignée de types). Le SDK officiel gère les détails. La vraie valeur est dans la réflexivité : Claude Code peut maintenant interroger sa propre mémoire de travail.

Résultat après 3 mois

  • 212 sessions indexées, recherche en < 10ms
  • Retrouver une décision architecturale prise il y a 2 mois : < 5 secondes
  • Utilisé quotidiennement comme outil de second cerveau technique
  • Bonus : l'outil est devenu un produit — je l'ai packagé en standalone

Le code source est privé pour l'instant, mais je prévois de le publier en open source.