ai-memory : mémoire partagée pour Claude Code et Codex

Contexte

La plupart des agents de code intègrent désormais une forme de mémoire. Claude Code prend des notes, Cursor retient certains éléments, et d'autres plateformes ajoutent des fonctions voisines. Ces mémoires partagent pourtant une limite : les notes restent sur une seule machine et appartiennent à un seul agent. Si vous changez d'outil, ou si vous confiez la tâche à un collègue, elles disparaissent du champ de vision. Il faut alors réexpliquer l'architecture, énumérer les pistes déjà abandonnées et rappeler les questions encore ouvertes.

ai-memory vise précisément cette faille. C'est un projet open source écrit en Rust, avec un fichier rust-toolchain.toml, des versions publiées, un site aimemory.sh et une licence ouverte. Sur GitHub, il approche les dix mille étoiles. Il ne cherche pas à devenir un agent de plus. Il se place sous tous les agents et forme une couche commune de mémoire à long terme.

L'objectif affiché est simple. Vous quittez Claude Code au milieu d'une tâche, puis vous lancez OpenAI Codex dans le même répertoire. Codex doit pouvoir poursuivre le travail sans nouveau briefing. Ce scénario résume le produit.

Analyse approfondie

Comment ai-memory permet-il à Claude Code et à Codex de partager une mémoire unique ? La réponse tient en quatre éléments, chacun correspondant à un choix de conception motivé. Le premier est la couverture inter-agents. Plus de vingt harness alimentent la même mémoire, dont Claude Code, Codex, Cursor, Gemini CLI, OpenCode, Grok, Devin, Kimi et Kiro. L'avancement circule par un protocole de passation typé. Chaque passation a un propriétaire et ne peut être réclamée qu'une seule fois. Elle consigne où en était l'agent précédent, ce qui a échoué et ce qui reste à résoudre. La règle de la réclamation unique compte : deux agents ne peuvent pas reprendre le même travail par accident.

Le deuxième élément est la commande `ai-memory run`, qui lance un agent en emportant la session elle-même, et pas seulement un résumé. Après avoir quitté Claude Code, vous pouvez exécuter `ai-memory run codex`. Codex reçoit le flux de travail partagé, plus une projection locale privée et temporaire de l'historique natif visible par Claude. Cette projection comble les détails exacts que le paquet de démarrage a dû tronquer. Le serveur distant ne reçoit que l'identifiant du harness et celui de la session. Il ne reçoit ni le chemin ni le contenu des transcriptions locales. Le troisième élément est le format des données. La source de vérité est un wiki géré par git, composé de simples fichiers .md. Vous pouvez les parcourir avec grep, les ouvrir dans Obsidian, les modifier à la main ou les copier avec rsync. La base de données n'est qu'un index dérivé, reconstructible à tout moment depuis les fichiers. Il n'y a pas de base vectorielle à entretenir, et rien n'est enfermé dans un binaire. Le quatrième élément est la capture silencieuse. Des crochets de cycle de vie enregistrent les invites, les appels d'outils et les limites de session. Une frontière de confidentialité typée nettoie les données avant leur stockage, puis le serveur les met en forme en pages lisibles. Le chemin par défaut ne fait aucun appel à un LLM. La capture, la recherche et la passation n'exigent aucune clé d'API. La mémoire s'estompe aussi selon un calendrier par niveaux que vous pouvez régler, sans recours à un LLM.

Impact sur l'industrie

Le projet couvre quatre usages concrets. Le plus typique est le changement d'outil en cours de tâche. Vous travaillez dans Claude Code et vous rencontrez un problème de quota ou de préférence. Vous poursuivez dans Codex, et l'agent suivant reçoit directement la note de passation. Le deuxième usage concerne les préférences entre projets. Un petit profil personnel consigne votre gestionnaire de paquets habituel, l'organisation de vos tests et vos habitudes d'architecture. Il est livré au début d'une session dans un nouveau dépôt. Sa priorité reste inférieure aux fichiers de règles de chaque dépôt, il sert donc de valeur par défaut. Il est activé d'office pour un utilisateur seul. Sur un serveur partagé, il faut l'activer soi-même, et il est isolé par personne. Les détails figurent dans docs/cross-project-profile.md.

Le troisième usage est le travail entre machines. La mémoire vit sur un serveur que vous exploitez vous-même : le même ordinateur portable, un serveur domestique ou un autre hôte. Un projet interrompu sur un poste fixe se poursuit sur un portable, avec les mêmes connaissances et les mêmes questions ouvertes. Le quatrième usage est le partage d'équipe. Tout le monde pointe vers le même serveur, et ce qu'apprend la session d'une personne devient interrogeable par tous les agents. Le savoir est partagé par projet, tandis que les passations personnelles restent privées. L'authentification multi-utilisateur, l'attribution par personne et les journaux d'audit sont intégrés. Ils ne relèvent pas d'une offre payante. Pour l'industrie, le sens est un déplacement de propriété. La mémoire cesse d'être une fonction privée d'un éditeur et devient une infrastructure maîtrisée par l'équipe d'ingénierie. Plus on multiplie les agents, plus il devient courant d'en changer, et personne ne veut rester prisonnier d'un seul. Placer la source de vérité dans du texte brut et dans git rend la mémoire relisible, portable et compatible avec la gestion de versions existante. Cela convient aux équipes attachées à la traçabilité. La conception de la confidentialité mérite aussi d'être saluée : la frontière typée et l'envoi des seules identités en mode run montrent une retenue nécessaire face à du code sensible.

Perspectives

Plusieurs points demandent de la prudence. Couvrir plus de vingt harness impose de suivre dans la durée les crochets et les formats de session de chaque éditeur. Le coût de maintenance de la compatibilité n'est pas négligeable. En mode équipe partagé, les utilisateurs doivent eux-mêmes décider quels contenus seront interrogeables et comment répartir les droits. Le README, tel que résumé ici, ne décrit qu'une partie des fonctions. Des détails comme la politique d'estompage doivent être vérifiés dans la documentation officielle.

Deux questions méritent d'être suivies. La première : d'autres outils adopteront-ils ce protocole de passation comme standard de fait ? La seconde : comment le chemin par défaut sans LLM se comporte-t-il en recherche sur de gros dépôts, où la recherche dans des fichiers bruts doit passer à l'échelle sans base vectorielle ? Pour les particuliers et les équipes qui combinent déjà plusieurs agents de code, ai-memory apporte une réponse concrète et inspectable au problème de la réexplication. Sa valeur réelle se verra à l'usage, à la fréquence avec laquelle un second agent pourra vraiment reprendre le travail du premier sans nouveau briefing.