Un agent de code IA n'a pas besoin d'un dossier synchronisé. Il lui faut un package manager.

Un setup d’agent de code IA, ça finit toujours par devenir un vrai environnement de dev.

Ça se fait sans bruit. On ajoute un prompt, puis un skill, puis un plugin, puis un serveur MCP, puis un AGENTS.md. Puis un profil Codex, un réglage Claude Code, deux symlinks vers les dotfiles, un fichier généré, un cache, un override local, et un historique qu’on n’a aucune envie de pousser dans un repo public.

À un moment, tout marche. Et c’est presque pire — parce qu’on n’arrive plus à dire ce qui tient quoi.

C’est ce qui m’a poussé à écrire Agent Brain.

Le setup est devenu utile avant de devenir lisible

Mon propre setup a franchi cette ligne sans que je le voie passer. Des skills ici, des prompts là, des métadonnées de plugins ailleurs. Une config Codex qui ne ressemble en rien à la config Claude Code. Des règles par projet, des règles globales, des symlinks, des artefacts générés, des dossiers que je reconnaissais à peine, et de l’état local qui n’a aucune raison de quitter la machine.

Le risque, ce n’est pas qu’un fichier casse. C’est qu’on ne sache plus à qui il appartient.

Qui possède ce fichier ? Moi ? Claude Code ? Codex ? Un plugin ? Un script oublié ? Est-ce une source que j’ai écrite, une sortie d’outil, un cache, un secret, un historique, un réglage local — ou juste un résidu d’expérimentation ?

Tant qu’on n’a pas répondu à ça, synchroniser ne fait que déplacer le bazar.

Les dotfiles restent utiles. Ils ne voient pas assez loin.

J’aime les dotfiles. J’en utilise, et je vais continuer.

Mais les dotfiles répondent à une question de chemin : quels fichiers doivent exister sur cette machine ?

Pour les agents de code, la question intéressante est ailleurs : qu’est-ce que ce fichier veut dire ?

Parce qu’il n’y a rien de commun entre :

• un skill écrit à la main ;
• un prompt réutilisable ;
• un fichier produit par un outil ;
• un réglage que l’app doit posséder elle-même ;
• un cache ;
• un token ou une session ;
• un chemin local ;
• un fichier déjà géré par un autre système ;
• un reste inconnu à inspecter avant adoption.

Un outil de sync peut déplacer tout ça d’un bloc, mais il n’a aucun moyen de savoir ce qui mérite de devenir une source portable.

C’est aussi pour cette raison que .claude et .codex deviennent piégeux dès qu’on les traite comme de simples dossiers. Ces apps ont leurs propres conventions, leurs fichiers générés, leurs caches, leurs plugins, leurs règles projet, leurs zones sensibles. Copier le dossier en bloc, c’est s’assurer de préserver le chaos avec une fidélité parfaite.

Le dossier de l’app n’est pas la source de vérité

Agent Brain prend le problème dans l’autre sens.

La source de vérité n’est pas le contenu du dossier Claude Code ou Codex à un instant T. Ce sont des packages, des profils, de la provenance, des adaptateurs par app, des locks d’écriture, et une discipline de rollback.

Les packages décrivent des capacités portables : skills, prompts, plugins, définitions MCP, connecteurs, comportements d’agent — tout ce qu’on a envie de versionner pour de bon.

Les profils déclarent quelles capacités vont ensemble.

La provenance garde l’origine de chaque fichier : d’où il vient, quel adaptateur l’a vu, pourquoi il a été classé comme ça.

Les adaptateurs absorbent les différences entre Claude Code, Codex et les apps qui suivront. Pas question d’aplatir tout dans un modèle générique — ces apps ne font pas le même métier.

Les locks d’écriture consignent ce qu’Agent Brain a posé dans une app cible. C’est ce qui rend possible la vérification, l’explication, la reprise ou le rollback.

Dans ce modèle, les dossiers .claude et .codex deviennent des sorties, pas le produit.

Ce que la version publique fait aujourd’hui

Agent Brain est désormais public, sur npm sous le nom @leonardsellem/agent-brain et sur GitHub : leonardsellem/agent-brain.

Installation :

npm install -g @leonardsellem/agent-brain
agent-brain --help

La version actuelle couvre le workflow prudent que je tenais à stabiliser avant de solliciter des retours :

• rejouer le scénario sur des fixtures, sans toucher au vrai setup ;
• diagnostiquer des racines explicites comme .claude, .codex, .dotstate ou un dossier jetable ;
• importer les candidats portables dans un repo Agent Brain ;
• afficher le plan avant toute écriture ;
• confirmer le fingerprint exact avant apply ;
• prendre un snapshot avant modification ;
• écrire un lock de ce qui a été posé ;
• lancer verify derrière ;
• revenir en arrière à partir des métadonnées de snapshot ;
• reconstruire une autre cible depuis le repo Agent Brain.

Ce n’est ni un service de sync, ni une marketplace de plugins. C’est un outil local, pensé pour rendre un environnement d’agent lisible avant de chercher à le rendre portable, et réversible avant de l’automatiser.

La sécurité live

La sécurité est volontairement pénible.

Les commandes live partent de racines explicites. Pas de scan magique du home, pas de balade optimiste dans des dossiers privés.

Avant d’écrire, Agent Brain produit un plan : créations, mises à jour, déplacements, symlinks. Ce plan reçoit un fingerprint. Pour appliquer, il faut confirmer ce fingerprint précis — pas un « yes » générique.

Avant toute modification, Agent Brain prend un snapshot. Après, il écrit un lock et lance une vérification. Le rollback s’appuie sur ce snapshot, pas sur une reconstruction à l’estime de l’état précédent.

Les secrets, sessions, caches, historiques et réglages propres à une machine sont exclus par défaut. Les fichiers inconnus doivent être signalés, pas adoptés en silence.

C’est délibéré. Un outil qui touche aux dossiers d’agents doit d’abord gagner le droit d’y toucher.

Pourquoi le sortir maintenant

À ce stade, la question n’est pas de savoir si chaque règle d’adaptateur est parfaite. C’est de savoir si le modèle tient face à des setups réels.

Je veux qu’Agent Brain apprenne sur du bazar utile.

Pas des démos propres. Des setups qui ont vécu. Des bouts de dotfiles, des symlinks, des scripts, des skills précieux, d’anciens essais, des fichiers générés, des dossiers dont plus personne n’est sûr. Le genre de setup qui marche justement parce qu’il a été bricolé au fil du temps.

C’est sur ce terrain-là que le modèle a quelque chose à prouver.

Les retours que je cherche

Si vous avez un setup d’agent qui tourne mais que vous auriez du mal à redessiner proprement sur une feuille blanche, votre retour m’intéresse.

Quelques questions sur lesquelles j’aimerais des avis concrets :

• Est-ce que ce vocabulaire d’ownership colle à ce que vous vivez ?
• Qu’est-ce qui doit être portable dans Claude Code et Codex ?
• Quels fichiers ne devraient jamais être adoptés automatiquement ?
• Où faut-il respecter la logique propre à l’app plutôt que d’aplatir tout dans un format générique ?
• Qu’est-ce qui rendrait crédible un rapport dry-run, apply, verify, rollback ?
• Quel genre de setup mal en point mériterait de devenir une fixture ?

Agent Brain est ici : https://github.com/leonardsellem/agent-brain

Si votre setup marche mais que vous ne savez plus l’expliquer, c’est vous que je veux écouter.