Un développeur peut passer une heure à reconstituer les raisons d’une modification du parseur, puis perdre tout ce raisonnement dès que la tâche suivante démarre dans un autre agent. Funes indexe les sessions localement, restitue les extraits d’origine avec leur provenance et permet de partager une même mémoire entre Claude Code, Codex, pi et Hermes. Attention toutefois à sa limite fondamentale : Funes retrouve l’historique, mais c’est toujours à l’agent de déterminer si une ancienne décision reste pertinente.
Ce guide présente une configuration concrète de Claude Code → Codex, l’utilisation d’une mémoire strictement locale, la synchronisation facultative avec Hugging Face, les clients MCP génériques et les contrôles nécessaires pour que l’historique retrouvé reste exploitable.
Définissez le périmètre de la mémoire avant l’installation
Commencez par une mémoire locale si vous évaluez Funes ou travaillez sur des dépôts sensibles. Ne liez un dataset Hugging Face que si vous devez retrouver le même historique depuis une autre machine ou le partager avec une équipe.
| Mode | Emplacement des données | Premier usage recommandé | Point de vigilance |
|---|---|---|---|
local | Dataset Lance local | Un développeur sur une seule machine | La mémoire ne vous suit pas automatiquement sur un autre hôte |
<org>/<repo> | Données Lance locales et dépôt Dataset Hugging Face | Passer d’un agent ou d’une machine à l’autre | Les traces de session peuvent contenir du code sensible, des prompts, des chemins ou des identifiants |
La politique de sécurité de Funes précise que l’analyse, le découpage, la génération des embeddings et le reranking sont effectués localement par défaut. Les données quittent la machine via funes push ou via une intégration de mémoire partagée qui publie les données à la fin d’une session. Une mémoire adossée au Hub est un dépôt de dataset : vérifiez donc sa visibilité avant le premier push.
Pour un premier test, utilisez local. Vous pourrez modifier ce choix plus tard en relançant funes add <agent> <memory>.
Installez Funes et créez le premier index
L’dépôt officiel de Funes fournit un installateur shell qui détecte la plateforme, télécharge un binaire tagué, vérifie le checksum de la release et place par défaut l’exécutable dans votre PATH, généralement sous ~/.local/bin :
curl -fsSL https://huggingface.co/buckets/huggingface/funes/resolve/install.sh | sh
Ouvrez un nouveau shell si funes n’est pas trouvé immédiatement, puis vérifiez l’installation :
funes status
Le dépôt liste des binaires tagués pour Linux x86_64, Linux aarch64 et macOS Apple Silicon. Si votre plateforme n’apparaît pas dans cette liste, suivez les instructions de compilation depuis les sources du projet au lieu de supposer que l’installateur précompilé la prend en charge.
Le démarrage en cinq minutes
Exécutez les commandes suivantes dans l’environnement où se trouvent déjà les sessions d’agent à conserver :
funes add claude
Avec Claude Code, cette commande peut créer le premier index, enregistrer les outils de lecture, installer l’automatisation d’intégration et continuer à indexer les tours terminés. La première passe privilégie le texte et le raisonnement avant les sorties d’outils volumineuses ; après confirmation, sa durée est documentée comme étant d’environ une minute. (Documentation de configuration de Funes)
Vérifiez ensuite l’état de l’installation :
funes status
Pour initialiser ou actualiser manuellement les sessions Claude, utilisez :
funes index --harness claude
Sans chemin, funes index peut rechercher les emplacements de session standards de Claude, Codex, pi et Hermes, notamment ~/.claude/projects et ~/.codex/sessions. Avec --harness claude, l’analyse se limite à Claude Code. Le guide d’indexation documente également un budget d’environ 60 secondes, centré sur le texte, pour les actualisations sans chemin ; les anciennes sessions et les sorties d’outils volumineuses pourront nécessiter des passes ultérieures.
L’indexation de Funes est incrémentale : relancer la commande ne génère donc pas de nouveaux embeddings pour les chunks déjà écrits. Les chemins de transcript explicites et les dépôts de traces sur le Hub sont indexés intégralement, sans utiliser le budget prévu pour les recherches sans chemin. (Détails de l’indexation)
Reliez Funes à Claude Code
Pour utiliser une mémoire Claude Code locale, lancez :
funes add claude local
funes status
Vous pouvez omettre local, qui est le mode par défaut. Si un token HF est disponible dans le terminal, Funes peut proposer de configurer un dépôt <user>/funes-memory appartenant à l’utilisateur ; refusez cette proposition pour un premier test strictement local.
L’intégration Claude repose sur un plugin limité aux hooks et sur une inscription MCP distincte. Funes ne modifie pas le fichier settings.json de Claude Code : son automatisation indexe les tours terminés, tandis qu’une configuration de mémoire partagée ajoute la publication à la fin des sessions. (Fonctionnement de l’automatisation)
Ouvrez Claude Code et testez une décision historique connue, plutôt que de juger l’installation sur sa seule réussite :
Find the previous decision about the streaming parser. Use Funes recall if the repository history does not explain it, and cite the session you used.
Un bon résultat renvoie vers un passage antérieur, identifie sa session et distingue une ancienne expérimentation de l’état actuel du dépôt.
Pour désactiver l’intégration sans supprimer les données stockées, lancez :
funes remove claude
La documentation de désinstallation précise que cette commande supprime le raccordement à Funes, mais conserve la mémoire locale, les transcripts originaux, les caches et la mémoire publiée.
Partagez la même mémoire avec Codex
Une fois Claude Code opérationnel, ajoutez Codex à la même mémoire locale :
funes add codex local
funes status
Pour utiliser une mémoire partagée sur le Hub, indiquez le même identifiant de dépôt pour les deux agents :
funes add claude <org>/<repo>
funes add codex <org>/<repo>
Codex comporte une étape de confiance facile à oublier. Funes écrit ses hooks dans ~/.codex/hooks.json ; dans Codex, lancez /hooks, examinez les entrées Funes et faites-leur confiance. Tant que ces hooks ne sont pas approuvés, Codex les ignore : aucun nouveau tour n’est alors indexé et aucune mémoire n’est publiée. Le workflow documenté de liaison d’une mémoire nécessite Codex 0.151.0. (Prérequis de l’automatisation Codex)
Testez un vrai passage de relais entre agents
Choisissez une décision distinctive, présente dans une session mais pas dans l’autre :
- Dans Claude Code, retrouvez la décision concernant le parseur et notez un terme caractéristique de la discussion.
- Terminez la session pour laisser l’indexation et l’automatisation de fin de session s’exécuter.
- Dans Codex, posez une question sur ce terme et demandez le raisonnement précédent.
- Vérifiez que la réponse identifie Claude comme harness source et renvoie vers la session ou le tour d’origine.
Vous pouvez examiner directement les éléments de preuve depuis un terminal :
funes recall "why did we switch away from the streaming parser"
recall renvoie des passages classés, et non un résumé généré. Chaque résultat contient des informations de source ainsi qu’une commande get générée ; copiez cette commande pour récupérer les tours environnants.
Si Codex ne renvoie rien, vérifiez la version, l’état de confiance via /hooks, le résultat de funes status et le fait que la session Claude ne soit pas antérieure à l’intégration. Réessayez ensuite avec un terme caractéristique de la discussion d’origine.
Connectez pi, Hermes ou un autre client MCP
Funes prend directement en charge pi et Hermes, en plus de Claude Code et Codex. Pi utilise des événements d’extension ; Hermes s’appuie sur des hooks shell et son indexation à chaque tour est documentée comme bêta. (Détails sur les agents pris en charge)
Pour un client compatible MCP qui ne fait pas partie de ces quatre agents, exécutez Funes comme serveur stdio local :
{
"mcpServers": {
"funes": {
"command": "funes",
"args": ["mcp"]
}
}
}
Pour relier le serveur à une mémoire partagée, ajoutez le dépôt après mcp :
{
"mcpServers": {
"funes": {
"command": "funes",
"args": ["mcp", "<org>/<repo>"]
}
}
}
La documentation MCP expose recall, get et status. funes mcp fonctionne en lecture seule : la commande n’indexe pas les sessions et ne publie aucune donnée. Pour ces opérations, utilisez funes index, funes push ou une intégration funes add prise en charge.
Une mémoire indiquée dans un appel MCP individuel prend le dessus sur la liaison définie au niveau du serveur. Si aucune mémoire n’est précisée, Funes utilise la mémoire locale.
Utilisez recall sans renoncer aux preuves
Funes propose trois workflows distincts :
| Commande | Résultat | À utiliser quand |
|---|---|---|
funes recall "…" | Passages originaux classés avec leur provenance | Vous voulez examiner les éléments de preuve |
funes get … | Le tour cité et son contexte environnant | Un résultat semble pertinent mais incomplet |
funes ask <agent> "…" | Une réponse en langage naturel fondée sur les sources | Vous voulez obtenir rapidement une réponse de Claude ou Codex sans installer d’intégration |
Les valeurs par défaut documentées pour recall sont de 8 résultats, un pool de 30 candidats rerankés, une demi-vie de récence de 30 jours et 1 chunk voisin. (Options et valeurs par défaut de recall)
Pour déboguer proprement, procédez ainsi :
- Lancez
funes recallavec l’erreur, le nom du composant ou la formulation de la décision recherchée. - Suivez la commande
getgénérée pour récupérer le tour complet. - Comparez la décision retrouvée avec l’état de la branche actuelle.
- Effectuez la modification ou lancez l’expérimentation.
- Relancez une recherche avec le résultat obtenu afin que la prochaine session puisse le retrouver.
funes ask est plus limité. La commande commence par effectuer la recherche, puis transmet les passages sélectionnés et votre question à Claude ou Codex pour obtenir une réponse unique. L’agent enfant ne reçoit ni outils, ni stdin, ni serveurs MCP, et ne peut pas relancer la recherche si le premier résultat est mauvais. Même si la recherche est locale, la question et les passages retrouvés sont envoyés au fournisseur configuré pour l’agent sélectionné. La documentation de ask recommande donc funes recall pour les contenus que vous ne souhaitez pas transmettre à ce fournisseur.
Gardez une mémoire fiable et opérationnelle
Funes conserve les passages sources et leur provenance, mais ne peut pas déterminer si chaque contournement historique s’applique encore aujourd’hui.
« Les agents de code deviennent beaucoup moins étranges quand la mémoire reste une infrastructure ennuyeuse : index local, provenance exacte, confidentialité par défaut. » — @TheArtemisHunts sur X
Une petite checklist pour la production
| Situation | Vérification | Action |
|---|---|---|
| Codex ne retrouve rien | Confiance accordée aux hooks et version | Lancez /hooks, approuvez les entrées Funes et vérifiez que Codex est en version 0.151.0 |
| Des sessions anciennes manquent | Périmètre et niveau d’indexation | Lancez funes index --harness claude ou --harness codex ; laissez les passes suivantes compléter les sorties volumineuses |
| Un push distant est bloqué | TruffleHog et portée du token | Installez TruffleHog ou définissez FUNES_TRUFFLEHOG ; utilisez un token d’écriture finement limité uniquement sur les machines qui effectuent les push |
| Un résultat contient un secret | Nettoyage local | Lancez funes scrub, puis effectuez à nouveau le push ; les transcripts sources ne sont pas modifiés |
| Une mémoire distante est partagée | Visibilité et confiance | Gardez le dataset privé, sauf si le partage public est intentionnel, et considérez les textes tiers retrouvés comme des entrées d’agent non fiables |
| La dernière session n’est pas sur le Hub | Moment de publication | Lancez funes push <org>/<repo> avant de mettre la machine hors service |
Funes masque les identifiants pendant l’indexation et effectue un scan TruffleHog en mode fail-closed avant toute publication. La documentation du push précise que l’absence de scanner bloque la publication ; si un identifiant actif atteint un dataset distant, révoquez-le immédiatement, car nettoyer un commit ultérieur ne peut pas effacer l’historique du dépôt.
Appliquez le principe du moindre privilège aux tokens Hugging Face : utilisez une portée d’écriture sur les machines qui publient et une portée en lecture seule pour les coéquipiers ou hôtes qui ne font que consulter. Deux machines qui publient dans la même mémoire distante peuvent également entrer en concurrence ; la documentation de l’automatisation ne garantit pas de sérialisation entre machines.
Le choix pratique
Choisissez l’un de ces points de départ plutôt que d’installer toutes les intégrations en même temps :
| Workflow | Configuration recommandée | Pourquoi |
|---|---|---|
| Un développeur qui évalue une mémoire persistante | funes add claude local | Risque de partage minimal et retour arrière simplifié |
| Claude Code pour la planification, Codex pour l’implémentation ou la revue | Lier les deux à la même mémoire local | Conserve le raisonnement entre les agents sur un même hôte |
| Des agents sur plusieurs machines | Lier les deux à la même mémoire privée <org>/<repo> | Permet à la mémoire de suivre le développeur via le dataset du Hub |
| Historique d’un projet d’équipe | Dataset privé et tokens en lecture seule pour les lecteurs | Sépare l’autorité de publication de l’accès en consultation |
| Agent MCP non pris en charge | funes mcp [memory] | Ajoute l’accès en lecture tout en laissant l’indexation explicite |
| Sources sensibles | Mémoire locale et recall | Évite la publication distante et la transmission ponctuelle au fournisseur |
FAQ sur la mémoire Funes pour les agents de code
Funes fonctionne-t-il en local ?
Funes traite et stocke la mémoire localement par défaut. Il privilégie le local, mais n’est pas automatiquement limité à la machine : les push, les hooks de mémoire partagée et ask peuvent envoyer des données hors du processus local.
Funes fonctionne-t-il avec Claude Code et Codex ?
Oui. funes add prend en charge Claude Code et Codex, ainsi que pi et Hermes. La liaison d’une mémoire Codex nécessite la version 0.151.0 et des hooks approuvés.
Funes indexe-t-il automatiquement les sessions ?
Après funes add, les intégrations prises en charge installent une automatisation qui indexe les tours au fil de l’eau. Le bootstrap initial est limité : les anciennes sessions et les sorties d’outils volumineuses peuvent donc nécessiter des passes ultérieures.
Comment partager une mémoire entre Claude Code et Codex ?
Utilisez le même argument <org>/<repo> avec funes add claude et funes add codex. Funes conserve l’index de travail en local et publie le dataset partagé à la fin des sessions.
Que faire si Funes retrouve une décision obsolète ?
Examinez-la avec funes recall, développez-la à l’aide de la commande get générée et comparez-la à la branche actuelle avant d’agir. Reformulez la requête si le premier résultat n’est pas pertinent.
funes ask conserve-t-il les données sur ma machine ?
La recherche et le reranking sont locaux, mais ask envoie la question et les passages retrouvés au fournisseur Claude ou Codex configuré. Utilisez recall pour les éléments sensibles.
Puis-je supprimer Funes sans effacer la mémoire ?
Oui. funes remove claude, funes remove codex, funes remove pi et funes remove hermes suppriment le raccordement aux intégrations tout en conservant la mémoire indexée et les transcripts sources.