Ce qui s’est passé. Mindwalk est un visualiseur local qui lit les logs de session de Claude Code et Codex et les rejoue sur une carte 3D du dépôt : chaque fichier devient un point dans l’espace, et l’activité de l’agent (recherche, lecture, modification) illumine cette zone de la carte. Un binaire Go téléchargeable, entièrement local, aucune donnée n’est envoyée hors de ta machine. Le projet est sur GitHub sous licence MIT.

Pourquoi ça te concerne. Quand tu délègues une tâche à un agent de coding, le log JSONL te dit ce qu’il a fait, pas comment il a compris le problème : quelles parties du dépôt il a explorées, où il s’est concentré, si son chemin correspond à celui que tu avais en tête. Mindwalk transforme cette séquence en une forme que tu peux voir d’un coup d’œil : la compréhension de la tâche par l’agent devient une carte thermique sur la codebase. Si l’agent a touché des fichiers qui n’ont rien à voir, ou s’il a sauté ceux qui sont essentiels, tu le vois immédiatement. C’est utile pour déboguer les agents qui échouent (où s’est-il perdu ?) et pour améliorer tes prompts (lui ai-je donné assez de contexte sur la structure ?).

Si tu veux l’essayer. Le dépôt contient un script d’installation qui vérifie la signature et installe le binaire dans ~/.local/bin. Une fois installé, mindwalk sans arguments lit les dossiers de Claude Code et Codex et ouvre l’interface web en local. L’UI a une timeline en histogramme (actions d’observation vs mutation), des contrôles play/pause et scrub, et un inspector qui montre l’historique des visites de chaque fichier cliqué.

En détail

Le contexte

Les agents de coding — Claude Code, Codex, Cursor en mode agent — produisent des logs détaillés de chaque action (fichiers ouverts, recherches, modifications, exécutions). Mais lire un JSONL ligne par ligne ne répond pas à la question la plus importante : l’agent a-t-il compris le problème comme tu te l’imaginais ? A-t-il exploré les bonnes parties du dépôt, ou s’est-il concentré sur des zones qui n’ont rien à voir ?

Mindwalk part de l’idée que la compréhension d’une tâche par l’agent a une forme spatiale : on peut la représenter comme une carte de lumière et d’ombre sur la codebase. Où l’agent a cherché, lu et modifié, la carte s’illumine ; tout le reste reste sombre.

Comment ça marche

L’outil a deux modes principaux :

• Mode serve (mindwalk sans arguments) : scanne les dossiers de Claude Code (~/.claude/projects) et Codex (~/.codex/sessions), génère les cartes des dépôts impliqués, lance un serveur local sur un port aléatoire et ouvre le navigateur. De là, tu peux choisir une session dans la liste et voir son replay.
• Mode open (mindwalk open <session.jsonl>) : ouvre une session spécifique sans scanner le tout.

La représentation visuelle offre deux vues : Tree (arbre radial de la structure des dossiers) et Terrain (treemap plane, chaque fichier est un rectangle dimensionné par nombre de visites). Chaque fichier porte un état de touch qui évolue avec la session : seen (vert mousse, fichier rencontré dans une recherche), read (blanc lunaire, fichier ouvert), edited (ambre chaud, fichier modifié), unvisited (sombre). L’état garde trace du niveau le plus profond atteint.

L’histogramme de la timeline sous la carte montre l’activité de la session en buckets temporels sur un spectre froid/chaud : les actions d’observation (search, read, exec) restent froides, les mutations (edit, verify) se réchauffent. Les phases d’édition ressortent visuellement. Sur la timeline apparaissent des marqueurs cliquables : compactages de contexte (◇), lancements de sous-agents (○), tours d’utilisateur (›).

L’HUD en haut résume des signaux de friction : taux d’erreur, fichiers modifiés plusieurs fois (churn), modifications après la dernière vérification. L’inspector sur le côté s’ouvre en cliquant sur un fichier et affiche son historique de visites avec timestamps ; chaque ligne saute la playhead à ce moment.

Les limites

Mindwalk fonctionne uniquement sur les logs que les outils produisent. Si un agent entretient des conversations internes ou fait des raisonnements qui ne finissent pas dans le log structuré, ceux-ci restent invisibles. La carte montre où l’agent est allé, pas pourquoi : pour reconstruire le raisonnement tu dois quand même relire les messages de la session.

L’outil pour l’instant supporte uniquement Claude Code et Codex. D’autres agents de coding (Cursor, Windsurf, Zed AI) produisent des logs dans des formats différents : il faudra un parser pour chacun, ou un standard partagé (qui n’existe pas encore).

Enfin, la visualisation 3D est utile pour des dépôts de taille petite à moyenne. Sur les énormes monorepos (milliers de fichiers) la carte devient difficile à naviguer : l’outil ne scale pas encore bien au-delà d’un certain seuil.

Qu’en faire

Mindwalk ne te dit pas si l’agent a fait du bon travail : il te dit s’il a compris le problème comme toi. Si une tâche de refactoring a touché seulement la moitié des fichiers que tu savais être impliqués, tu as découvert un problème dans le brief ou dans le contexte passé. Si l’agent a modifié des fichiers de config qui n’avaient rien à voir, tu as découvert un outil appelé au mauvais moment ou un prompt ambigu.

C’est un outil de débogage du prompt, pas du code produit. Après avoir vu la carte, tu retournes au brief de l’agent et tu le réécris avec le contexte manquant, ou tu délimites mieux les frontières des outils.

Pour ceux qui construisent des agents custom ou expérimentent avec des orchestrations multi-agent, Mindwalk peut devenir partie du cycle de développement : tu lances la tâche, tu regardes la carte, tu corriges, tu relances. C’est la même boucle que tu fais avec un profiler de performance, mais appliquée à la compréhension de la tâche au lieu du temps d’exécution.