Spool est une bibliothèque locale pour retrouver, épingler et fouiller ses sessions Claude Code, Codex, Gemini et OpenCode. Mon verdict court : ça vaut le test si vous utilisez souvent des agents de code, surtout pour la recherche et le scan de secrets, mais il faut accepter un produit encore jeune.
Spool, c’est quoi ?
Spool part d’un problème très concret : les agents IA de développement produisent vite une masse d’historique. Une discussion Codex sur un incident, une session Claude Code sur une migration, un vieux prompt où l’on a collé un bout de log, tout cela finit dans des fichiers locaux, mais rarement dans un endroit agréable à consulter.
Le projet propose donc une couche d’indexation locale. Il lit les répertoires de sessions de Claude Code, Codex, Gemini et OpenCode, crée une base SQLite avec FTS5, puis expose une application desktop Electron et une CLI spool.
La promesse importante, côté sécurité, est simple : rien ne quitte la machine. Le scanner de secrets intégré travaille en local, avec des règles regex déterministes. Dans mon contexte de freelance sécu et DevOps, c’est exactement le genre de détail qui compte, parce que les transcripts d’agents contiennent souvent des chemins internes, des bouts de configuration, des noms de clients et parfois des secrets.
| Élément | Détail observé |
|---|---|
| Version testée | 0.5.2 depuis le dépôt GitHub |
| Stack | TypeScript, Electron, React, SQLite, FTS5, better-sqlite3 |
| Interfaces | Desktop app et CLI officielle |
| Données | Stockage local dans ~/.spool ou SPOOL_DATA_DIR |
| Sources | Claude, Codex, Gemini, OpenCode |
| Sécurité | Scan local de secrets et PII via @spool-lab/redact |
Installation de Spool
J’ai cloné le dépôt dans /tmp, lu le README, les packages CLI, core et app, puis installé les dépendances avec pnpm. Le premier essai dans /tmp a échoué par manque d’espace disque pendant l’installation des dépendances lourdes. J’ai donc gardé le clone d’inspection dans /tmp, puis utilisé un dossier scratch temporaire sous la racine demandée pour l’installation, supprimé à la fin.
Les commandes utiles :
git clone --depth 1 https://github.com/paperboytm/spool /tmp/spool-scout
pnpm install --frozen-lockfile
pnpm --filter @spool-lab/redact build
pnpm --filter @spool-lab/core build
pnpm --filter @spool-lab/cli build
pnpm --filter @spool-lab/core test
Le build du moteur et de la CLI est passé. Les tests du coeur ont aussi tourné pour de vrai : 44 fichiers de test passés, 394 tests passés et 1 ignoré. Le module natif better-sqlite3 a été reconstruit pour Node avant les tests, comme le README le recommande.
Point à noter : Spool ne m’a pas demandé de clé LLM pour ce scénario. J’avais bien préparé les variables OpenAI et OpenRouter vers le proxy local demandé, mais la partie testée, indexation, recherche, doctor et scan local, n’en a pas eu besoin.
Spool à l’usage
Pour éviter de scanner un vrai historique privé, j’ai créé un mini historique réaliste : une session Claude Code sur un audit de configuration Stripe et une session Codex sur la rotation de clés GitHub. Les fichiers étaient au format JSONL attendu par les parseurs de Spool, avec un projet commun /workspace/client-api.
J’ai ensuite isolé la base avec SPOOL_DATA_DIR, puis lancé :
spool sync
spool status
spool search "rotation" -n 3
spool projects
spool list -n 5
spool show 11111111-1111-4111-8111-111111111111
spool pin <uuid>
spool pinned
spool doctor
Ce que Spool a produit :
- une base SQLite locale
spool.db, environ 244 à 256 KB dans ce test ; - 2 sessions indexées, 1 Claude et 1 Codex ;
- un regroupement de projet
client-api; - une recherche plein texte qui retrouve la session Codex sur le mot
rotation; - une commande de reprise adaptée, par exemple
codex resume <uuid>; - une vue détaillée des messages avec rôles, dates, modèle et outils utilisés ;
- un pin persistant visible via
spool pinned; - un
spool doctorpropre, 13 contrôles OK, 0 warning, 0 erreur.
La recherche est le point fort immédiat. Sur ma requête rotation, Spool n’a pas seulement dit qu’il avait trouvé quelque chose. Il a affiché la source, le projet, le titre de session, la date, l’UUID et l’extrait pertinent. Pour retrouver une décision technique prise trois jours avant dans une session d’agent, c’est exactement le bon niveau de détail.
Spool Security Scan, ça marche vraiment ?
J’ai aussi testé le scanner de secrets, pas seulement lu la doc. Pour cela, j’ai injecté dans les transcripts des valeurs factices mais avec une forme crédible : une variable d’environnement de type secret et une clé API au format reconnu. Puis j’ai appelé l’API core de scan avec le provider regex local utilisé par Spool.
Résultat observé : 2 sessions scannées, 2 findings actifs. Spool a classé les deux en sévérité haute : un env-var et un api-key, avec le provider regex. Les valeurs ressortent masquées dans le résultat, ce qui est le comportement attendu pour un outil de revue de secrets.
Ce test est important. Beaucoup d’outils annoncent une détection de secrets, mais se contentent d’un scan superficiel ou d’un appel cloud. Ici, le pipeline est local, reproductible et relié aux sessions indexées. Pour un poste de dev ou une machine d’admin, c’est rassurant.
Ce que j’aime dans Spool
D’abord, l’approche local-first est cohérente. Les sessions d’agents sont des données sensibles par nature, donc les indexer localement dans SQLite est un bon choix.
Ensuite, la CLI est réellement utile. Même sans lancer l’application desktop, j’ai pu synchroniser, chercher, afficher, épingler et diagnostiquer la base. Pour un profil DevOps, c’est presque plus important qu’une jolie interface.
J’aime aussi la prise en charge de plusieurs agents. Dans beaucoup d’équipes, l’historique est fragmenté entre Claude Code, Codex, Gemini et parfois OpenCode. Le fait de regrouper par projet, plutôt que seulement par outil, rend la bibliothèque plus proche du vrai flux de travail.
Enfin, spool doctor est propre. Il vérifie l’environnement, la base, l’intégrité SQLite, les clés étrangères, le WAL, la configuration et le module natif. Pour un produit desktop avec un moteur local, c’est une bonne pratique.
Les limites de Spool
La première limite est la maturité. Le README prévient que Spool est early stage, et ça se voit dans l’installation source : gros monorepo, Electron, better-sqlite3, reconstruction native, dépendances nombreuses. Ce n’est pas dramatique, mais ce n’est pas encore l’expérience d’un petit binaire autonome.
La deuxième limite, dans mon test, est que je n’ai pas validé la fenêtre Electron en session graphique. Le sandbox Docker n’était pas l’environnement idéal pour une app desktop. J’ai donc testé le moteur réel et la CLI officielle, ce qui couvre l’indexation, la recherche, le pin, le doctor et le scan de secrets, mais pas l’ergonomie complète de l’interface.
Troisième limite : la qualité dépend forcément des parseurs. Si un outil change son format de session, il faut que Spool suive. Les tests du repo couvrent déjà Claude, Codex, Gemini et OpenCode, mais c’est un point de maintenance permanent.
Faut-il adopter Spool ?
Mon verdict : essayer, clairement, mais adopter progressivement.
Si vous utilisez un seul agent une fois par semaine, Spool est probablement trop spécialisé. Si vous travaillez tous les jours avec Claude Code, Codex ou OpenCode, il devient intéressant très vite. La recherche plein texte fait gagner du temps, et le scanner de secrets apporte une vraie couche de sécurité locale.
Pour un freelance sécu ou DevOps, je le mettrais dans la catégorie des outils à garder sous surveillance. Pas encore un standard évident, mais déjà assez solide pour indexer un historique local, retrouver une décision, épingler une session importante et repérer des fuites dans des transcripts.
FAQ
Spool envoie-t-il mes sessions dans le cloud ?
Non, pour les fonctions testées ici, tout reste local. La base SQLite et le scanner de secrets tournent sur la machine.
Peut-on utiliser Spool sans l’application desktop ?
Oui. La CLI officielle permet déjà de synchroniser, chercher, afficher, épingler et diagnostiquer les sessions.
Spool est-il prêt pour une équipe entière ?
Pas encore comme plateforme d’équipe. Il est surtout pensé comme bibliothèque locale personnelle, avec une base par machine et une approche prudente sur la confidentialité.