TL;DR : codebase-memory-mcp indexe votre dépôt dans un graphe de connaissances persistant afin que votre agent de codage réponde aux questions structurelles à partir du graphe au lieu de rechercher et de lire son chemin. Le projet mesure cinq requêtes structurelles à environ 3 400 jetons via le graphe contre environ 412 000 via l'exploration fichier par fichier, une réduction de 99,2 %. Écrit en C, livré sous forme d'un seul binaire natif sans runtime et sans clé API, couvre plus de 160 langages, et fonctionne entièrement sur votre machine. 41 536 étoiles au 1er septembre 2026, sous licence MIT. Si vous installez une seule chose de la vague d'outils d'agents de 2026, que ce soit celle-ci.
Ceci est une analyse approfondie d'un outil de notre tour d'horizon des cinq outils d'agents IA open source à installer en 2026.
Demandez à votre agent où une fonction est appelée et observez ce qui se passe. Il cherche. Il lit trois fichiers. Il cherche à nouveau avec un motif différent. Il lit quatre fichiers supplémentaires. Finalement, il répond, correctement, après avoir brûlé des dizaines de milliers de jetons en remplissant son contexte de code source qu'il oubliera dès la fin de la session.
Ensuite, vous posez une question de suivi et il recommence tout le processus.
Cette boucle est ce qui consomme la majeure partie de votre limite d'utilisation lors d'une longue session, et c'est aussi pourquoi la qualité des réponses se dégrade au fil de l'après-midi : une fenêtre contextuelle remplie de contenu de fichiers laisse moins de place au raisonnement. codebase-memory-mcp s'attaque à ces deux problèmes avec la même approche.
Ce qu'il fait
Il analyse votre dépôt en un graphe de connaissances persistant de fonctions, de classes, de chaînes d'appels, de routes HTTP et de liens inter-services, puis répond aux questions structurelles à partir de ce graphe.
L'analyse s'effectue via l'analyse AST de tree-sitter pour plus de 160 langages, avec une couche LSP hybride ajoutant la résolution sémantique des types pour un groupe de base que le badge README compte comme dix : Python, la famille TypeScript et JavaScript incluant JSX et TSX, PHP, C#, Go, C, C++, Java, Kotlin, Rust et Perl. La distinction est importante. L'analyse AST vous dit qu'une méthode nommée save est appelée ; la résolution de type vous indique à quelle classe elle appartient.
Le résultat est exposé sous forme de 15 outils MCP couvrant la recherche, le traçage de chaînes d'appels, la vue d'ensemble architecturale, l'analyse d'impact, les vérifications de couverture d'index, les requêtes Cypher sur le graphe, la détection de code mort, la liaison HTTP inter-services et la gestion ADR. Tout client qui parle le Model Context Protocol peut l'utiliser, et le projet liste 45 interfaces d'agents supportées, y compris Claude Code, Codex, Cursor, Windsurf, OpenCode, Gemini CLI, Aider et Kilocode.
Les chiffres
Deux ensembles indépendants, et tous deux méritent d'être lus attentivement.
La propre mesure du projet : cinq requêtes structurelles ont consommé environ 3 400 jetons via le graphe contre environ 412 000 jetons via une exploration fichier par fichier. Cela représente une réduction de 99,2 %, soit environ 120 fois moins de jetons pour les mêmes réponses.
La version académique se trouve dans un prépublication, Codebase-Memory: Tree-Sitter-Based Knowledge Graphs for LLM Code Exploration via MCP, évaluée sur 31 dépôts réels. Elle rapporte une qualité de réponse de 83 %, 10 fois moins de jetons et 2,1 fois moins d'appels d'outils par rapport à l'exploration fichier par fichier.
L'écart entre 120x et 10x est la partie honnête. Le chiffre de 120x correspond à cinq requêtes structurelles, ce qui est le meilleur cas du graphe, car les questions structurelles sont exactement ce à quoi un graphe est destiné. Le chiffre de 10x est un mélange plus large sur 31 dépôts, ce qui est plus proche de ce que vous verrez en utilisation quotidienne. Les deux sont importants. Prenez le 10x comme chiffre de planification et considérez tout ce qui est mieux comme un bonus.
La vitesse est l'autre moitié. L'indexation du noyau Linux, 28 millions de lignes sur 75 000 fichiers, prend trois minutes. Un dépôt moyen s'indexe en quelques millisecondes. Les requêtes structurelles sont renvoyées en moins d'une milliseconde. Le pipeline est axé sur la RAM avec compression LZ4, SQLite en mémoire et correspondance de motifs Aho-Corasick fusionnée, et la mémoire est libérée après l'indexation.
L'écriture en C plutôt qu'en TypeScript ou Python est la raison d'être de ces chiffres, et c'est aussi pourquoi il n'y a pas de runtime à installer.
Installation
macOS et Linux :
curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash
Windows, avec les étapes recommandées par le projet plutôt qu'une commande unique aveugle :
Invoke-WebRequest -Uri https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.ps1 -OutFile install.ps1
notepad install.ps1 # lisez-le d'abord
Unblock-File .\install.ps1
.\install.ps1
Les options incluent --skip-config pour le binaire seul sans configuration d'agent, et --dir=<path> pour un emplacement personnalisé. L'installateur détecte automatiquement les agents de codage installés et écrit leurs entrées MCP documentées, ainsi que les instructions, les compétences et les hooks de cycle de vie lorsque le client les supporte. Sur macOS, il supprime les attributs de quarantaine et signe le binaire ad-hoc, donc pas de travail manuel avec xattr ou codesign.
Ensuite, redémarrez votre agent et demandez-lui d'indexer le projet.
Deux drapeaux de configuration à définir dès le premier jour :
# indexer automatiquement les nouveaux projets lors de la première connexion
codebase-memory-mcp config set auto_index true
codebase-memory-mcp config set auto_index_limit 50000
# visualisation du graphe, intégrée au binaire
codebase-memory-mcp --ui=true --port=9749
L'interface utilisateur sur localhost:9749 rend le graphe de connaissances en 3D. Elle est vraiment utile pour repérer une structure dont vous ignoriez l'existence, et c'est une bonne vérification de la cohérence de l'index avec ce que vous attendiez.
Si vous travaillez sur de nombreux dépôts, auto_watch false empêche une session d'enregistrer son projet auprès du veilleur en arrière-plan, et watcher_enabled false désactive complètement le fil de sondage. Ce dernier est lu une seule fois au démarrage du démon, alors arrêtez le démon après l'avoir modifié.
Deux choses à vérifier avant de l'exécuter
Les deux sont documentées par le projet, ce qui est un bon signe, et les deux méritent trente secondes de votre attention.
Microsoft Defender peut signaler un binaire de version comme Trojan:Script/Wacatac.B!ml. Le projet documente cela comme un faux positif connu, note que généralement 61 des quelque 62 moteurs renvoient un résultat propre, et souligne que la même famille de détection affecte la CLI de GitHub, llama.cpp, Godot et la propre chaîne d'outils Go de Microsoft. Chaque version est scannée sur VirusTotal avant publication et les notes de version lient les résultats. C'est une posture plus transparente que la plupart des projets, et le problème sous-jacent est un problème heuristique bien connu avec les petits binaires natifs non signés.
Il lit votre base de code et écrit dans vos fichiers de configuration d'agent. C'est son travail, et le projet le dit clairement plutôt que de le cacher. Les mesures d'atténuation sont réelles : le code source complet est disponible sous licence MIT, les versions portent une scorecard OpenSSF et une provenance SLSA de niveau 3, et le traitement est entièrement local. Le projet déclare également qu'il n'effectue aucune requête réseau de lui-même, ne vérifie pas les mises à jour en arrière-plan et ne se connecte pas à un serveur distant. Les mises à jour s'exécutent à partir du script d'installation placé à côté du binaire plutôt que depuis le processus en cours, ce qui est un choix de conception délibéré expliqué en détail dans le README.
La bonne réponse aux deux est la même : lisez le script d'installation avant de le passer à bash, et vérifiez vous-même l'affirmation de fonctionnement local uniquement si cela vous importe. Un grand nombre d'étoiles est une indication de popularité, pas un audit.
Pourquoi c'est celui-ci qu'il faut installer en premier
Chaque autre outil de la vague actuelle d'agents modifie votre flux de travail. Les personas changent la façon dont vous posez des questions. Les arborescences de travail parallèles changent la façon dont vous organisez le travail. L'accès au Web change ce que vous demandez.
Celui-ci ne change rien à votre façon de travailler et rend chaque session moins chère et meilleure. Il n'y a pas de nouvelle habitude à apprendre. Vous l'installez, indexez le projet, et votre agent arrête de brûler du contexte sur des boucles de grep. Lors d'un long refactoring, la différence entre atteindre votre limite à 14h et terminer la journée n'est pas subtile.
L'effet sur la qualité est la moitié sous-estimée. Un agent qui passe 400 000 jetons à lire des fichiers a d'autant moins de place pour réellement réfléchir à votre problème, et sa mémoire de ce qu'il a lu en début de session se dégrade. Répondre à partir d'un graphe maintient le contexte libre. La même dynamique s'applique à ce que vos outils renvoient dans ce contexte, ce qui est le sujet des fenêtres contextuelles de réponse des outils d'agents, et c'est le même échec qui rend les réponses d'API gonflées coûteuses dans les flux de travail des agents.
Les outils que vous utiliserez réellement
Quinze outils MCP, cela peut sembler beaucoup à apprendre. En pratique, vous n'en apprenez aucun, car l'agent choisit. Ce qui est utile de savoir, c'est quelles questions ont maintenant une réponse peu coûteuse, afin que vous commenciez à les poser.
L'analyse d'impact est la plus précieuse et la moins utilisée. Avant de modifier la signature d'une fonction, demandez ce qui sera cassé. Le graphe trace chaque appelant dans le dépôt en moins d'une milliseconde, là où la version grep manque les appels dynamiques et abandonne tout ce qui est indirect. Cela transforme « Je pense que c'est sûr » en une liste.
Le traçage de la chaîne d'appels répond à la question de savoir comment l'exécution atteint réellement un morceau de code. Utile sur les dépôts inconnus et bien meilleur que de lire en remontant cinq fichiers en espérant trouver le point d'entrée.
La vue d'ensemble de l'architecture fournit une carte structurelle sans que l'agent ait à lire l'arbre entier. C'est ce qui rend l'intégration à une base de code inconnue différente, et cela se marie bien avec une persona d'exploration en lecture seule.
La détection de code mort trouve ce qui n'est jamais appelé. Exécutez-la avant un sprint de nettoyage plutôt que d'en débattre.
La liaison HTTP inter-services trace un appel dans un service vers le gestionnaire dans un autre. Sur une base de code de microservices, c'est la différence entre un agent qui comprend un dépôt et un qui comprend le système. C'est aussi précisément là qu'apparaît l'écart contractuel ci-dessous.
Les requêtes Cypher sont l'échappatoire. Lorsque vous voulez quelque chose de spécifique que les autres outils ne couvrent pas, vous pouvez interroger le graphe directement.
Le changement pratique réside dans la manière dont vous formulez vos requêtes. Les questions que vous évitiez auparavant parce qu'elles coûtaient 50 000 jetons et deux minutes sont désormais presque gratuites, alors posez-les. « Qui appelle ceci ? » avant chaque refactoring. « À quoi ressemble le chemin de requête pour ce point de terminaison ? » avant le débogage. L'outil modifie l'économie de la curiosité, ce qui est plus important que toute autre fonctionnalité.
Ce que le graphe sait, et ce qu'il ne sait pas
Voici la limite, et elle est nette et mérite d'être comprise avant de faire trop confiance à l'outil.
Le graphe est construit à partir de votre code. Il sait ce que votre code est. Parmi les 15 outils, il y a la liaison HTTP inter-services, qui trace un appel dans un service vers le gestionnaire dans un autre, et c'est une chose vraiment utile à savoir pour un agent.
Ce qu'il ne peut pas vous dire, c'est ce que le contrat dit. Il sait que la route /v1/invoices/{id} existe et quelle fonction la gère. Il ne sait pas que le point de terminaison renvoie un 409 avec une enveloppe d'erreur différente lorsqu'une clé d'idempotence est réutilisée, que le champ status a exactement cinq valeurs valides, que le curseur est opaque plutôt qu'un offset, ou qu'un champ est déprécié et disparaît le trimestre suivant. Rien de tout cela n'est dérivable de la source du gestionnaire, car la plupart de ces informations sont le fruit d'un accord plutôt que d'une implémentation.
Ainsi, l'agent, désormais doté d'une parfaite mémoire structurelle, devine toujours le contrat. Il écrit un client basé sur une forme inférée et effectue des tests avec un mock qu'il a inventé, et tout est vert jusqu'à la mise en staging.
C'est pourquoi Apidog et un outil comme celui-ci s'emboîtent plutôt que de se chevaucher :
- Le graphe répond à "où". Quel gestionnaire, quelle chaîne d'appels, ce qui est cassé si cette signature change.
- La spécification répond à "quoi". De vrais schémas, de vrais codes de statut, de vraies enveloppes d'erreur, lus par l'agent plutôt que reconstruits. Le raisonnement se trouve dans l'utilisation de votre spécification OpenAPI comme outils d'agent.
- Les mocks sont générés à partir de la spécification, y compris les branches d'erreur que l'agent n'aurait jamais pensé à simuler.
- Les tests de contrat échouent en CI lorsque l'implémentation et l'accord divergent, ce qui est le mode d'échec décrit dans ce qui se passe lorsque les changements d'API cassent les agents IA.
Il y a une symétrie plaisante. codebase-memory-mcp existe parce que la lecture du code source pour répondre à des questions structurelles est coûteuse et peu fiable. Il en va de même pour la lecture du code source afin d'inférer un contrat, et la réponse est la même : indexez la chose une fois, sous une forme conçue pour la question. Téléchargez Apidog si vos agents écrivent des clients API contre des formes que personne n'a écrites. Lié : concevoir des schémas d'outils API pour les agents et avez-vous toujours besoin d'un outil API à l'ère des agents IA.
La mémoire du code n'est pas la mémoire du travail
La deuxième limite est organisationnelle.
L'index réside dans un répertoire de cache sur une machine, sous un compte. Il est partagé entre vos sessions locales Claude Code, Codex et OpenCode via un démon de coordination, ce qui est une belle prouesse d'ingénierie, et il s'arrête à la limite de cette machine.
Plus important encore, le graphe est une mémoire de la base de code, pas une mémoire du travail. Il peut vous dire que l'aide au réessai appelle le client de paiement. Il ne peut pas vous dire pourquoi le délai a changé en juillet, qui a décidé cela, quelle était l'alternative, ou si quelqu'un l'a examiné. Cette histoire a existé dans une session de terminal qui a disparu.
Les équipes ressentent cela comme un étrange décalage : l'agent a une meilleure mémoire du code que n'importe quel humain de l'équipe, et aucune mémoire des décisions qui l'ont produit.
Sharkly couvre l'autre moitié en faisant de la tâche l'enregistrement durable plutôt que l'invite :
- Le travail se présente sous forme de tâches, et le résultat de l'agent apparaît sous forme de commentaires auxquels vous répondez. La progression et les appels d'outils sont diffusés vers la tâche. Le raisonnement survit à la session.
- Un Agent est une configuration sauvegardée. Instructions, runtime, compétences, dépôts, environnement. La configuration où votre agent dispose de l'index, de la spécification et des bonnes autorisations est réutilisée au lieu d'être reconstruite par machine.
- L'exécution est "apportez la vôtre". Vous connectez un ordinateur, qui peut être votre ordinateur portable, un serveur ou un conteneur, et Sharkly utilise le runtime déjà installé dessus. C'est directement pertinent ici, car l'index est par machine : savoir quel ordinateur contient le dépôt indexé fait la différence entre un graphe chaud et un démarrage à froid de trois minutes.
- Le travail sur le dépôt s'exécute dans un worktree distinct par tâche, de sorte que les tâches parallèles sur le même dépôt n'entrent pas en conflit.
- Une tâche en attente ne démarre pas d'exécution, donc le travail est préparé avant toute exécution.
- Une structure que l'équipe comprend déjà : espaces, projets, sprints, tâches, avec synchronisation Jira.
La mémoire du code plus la mémoire du travail, c'est la combinaison. Un outil donne à votre agent la mémoire du dépôt. L'autre donne à votre équipe la mémoire de ce que les agents y ont fait.
FAQ
Est-ce que cela fonctionne avec Cursor, Codex et OpenCode, ou seulement avec Claude Code ? C'est un serveur MCP, donc tout client MCP fonctionne. Le projet liste 45 interfaces d'agents prises en charge et l'installateur détecte automatiquement ce que vous avez. Si vous évaluez les clients agents pour le travail d'API, consultez notre aperçu des clients API dans Cursor et Copilot.
Mon code quitte-t-il ma machine ? Non. Le traitement est entièrement local, et le projet déclare qu'il n'effectue aucune requête réseau de lui-même et ne vérifie pas les mises à jour en arrière-plan. Le code source est sous licence MIT si vous voulez le vérifier plutôt que de le prendre pour acquis.
La réduction de 99 % des jetons est-elle réaliste pour mon dépôt ? Le chiffre de 99,2 % concerne cinq requêtes structurelles, ce qui est le cas le plus fort du graphe. Le chiffre évalué par des pairs sur 31 dépôts est de 10 fois moins de jetons et 2,1 fois moins d'appels d'outils. Prévoyez environ 10x. Un travail riche en questions structurelles le dépassera.
Quelle est la taille maximale de dépôt qu'il peut gérer ? Le cas limite annoncé est le noyau Linux à 28 millions de lignes et 75 000 fichiers en trois minutes. La limite d'indexation automatique par défaut est configurable à 50 000 fichiers. Les dépôts d'applications ordinaires s'indexent en quelques millisecondes.
Pourquoi Defender le signale-t-il ? Un faux positif connu par apprentissage automatique sur les petits binaires natifs non signés. Le projet le documente, note que 61 des quelque 62 moteurs renvoient un résultat propre, et fournit des liens vers les résultats VirusTotal pour chaque version. La même famille de détection affecte la CLI de GitHub et la propre chaîne d'outils Go de Microsoft.
Cela remplace-t-il la lecture du code ? Pour les questions structurelles, oui, et c'est ce que la plupart des agents demandent. Pour le comportement, les cas limites et l'intention, non. Et pour ce qu'une API renvoie, vous avez besoin d'une spécification plutôt que de l'un ou l'autre, ce qui est l'argument dans avez-vous toujours besoin d'un outil API à l'ère des agents IA.
Conclusion
C'est l'outil le moins tape-à-l'œil de la vague d'agents de 2026 et celui qui offre le meilleur retour. Pas de changement de flux de travail, pas de nouvelle habitude, un seul binaire natif et une réduction mesurée d'un ordre de grandeur des jetons que votre agent dépense à répondre à des questions qu'il ne devrait pas avoir à rechercher. Il est également le plus rentable lorsque plusieurs agents fonctionnent simultanément, ce qui est le cas pour Orca. Installez-le, indexez votre projet, réglez auto_index et ouvrez le visualiseur de graphe une fois pour voir ce qu'il a construit.
Ensuite, soyez clair sur les deux limites. Le graphe sait où se trouve votre code, mais pas ce que votre API promet, et cet écart est ce qu'Apidog comble avec une spécification, un mock et une suite de tests. Et il se souvient du dépôt, pas du travail, ce qu'Sharkly comble en faisant de la tâche l'enregistrement au lieu de l'invite.
Une mémoire parfaite du code est une base solide. Ce n'est pas la même chose que de savoir ce qui est vrai ou ce qui a été décidé.