claude-devtools : relire ce que Claude Code ne montre plus

Le problème que l'outil prend pour cible

Depuis la version 2.1.20 de Claude Code, la sortie du terminal a été remplacée par des résumés du type « Read 3 files » ou « Searched for 1 pattern ». Le README de claude-devtools cite le billet de blog symmetrybreak.ing et un fil Hacker News pour documenter la réaction des utilisateurs. Le chemin des fichiers lus, le contenu, les numéros de ligne et le motif recherché ne sont plus affichés. L'alternative officielle est l'option --verbose, qui déverse du JSON brut, des prompts système internes et des milliers de lignes. Le README résume la situation par une phrase : il n'existe pas de juste milieu.

Le projet s'adresse donc à un public précis. Pas aux équipes qui découvrent Claude Code, mais à celles qui l'utilisent assez souvent pour qu'une session échouée représente un coût. Quand un agent modifie le mauvais fichier ou boucle sur un outil sans raison apparente, le terminal ne fournit presque rien pour reconstituer ce qui s'est passé. claude-devtools part du principe que la matière première existe déjà sur le disque et qu'il suffit de la rendre lisible.

D'où viennent les données et comment elles sont relues

L'outil ne s'interpose pas entre Claude Code et le modèle. Il ne passe par aucun proxy, n'exige aucune clé d'API et ne modifie pas la configuration de Claude Code. Il lit les journaux de session et les transcripts que Claude Code écrit dans ~/.claude/ sur la machine, puis reconstruit à partir de ces fichiers ce que le terminal masque. Le README insiste sur ce point : l'outil fonctionne avec toutes les sessions déjà exécutées, pas seulement les nouvelles.

Le résultat est présenté comme une interface structurée, filtrable et navigable. Les appels d'outils sont dépliés avec leur entrée et leur sortie réelles. Les modifications de fichiers apparaissent sous forme de diffs en ligne avec surlignage des ajouts et des suppressions. Les sous-agents produisent un arbre d'exécution par agent, avec les traces d'outils, les tokens, la durée et le coût. La réflexion étendue est affichée, alors qu'elle est invisible dans le terminal. Le README décrit aussi la lecture de MEMORY.md comme un index cliquable de couches, chaque couche pouvant être ouverte dans votre éditeur.

Un détail d'architecture ressort de la description : la reconstruction se fait après coup, à partir de fichiers, et non en flux temps réel. Cela simplifie beaucoup de choses, mais cela signifie aussi que l'outil dépend entièrement de la stabilité du format des transcripts. Le README ne documente pas ce format, et rien dans le matériel fourni ne permet de savoir comment le projet gère une évolution de schéma côté Claude Code.

L'attribution des tokens, tour par tour

C'est la partie la plus intéressante du projet, et aussi celle qui se distingue le plus clairement de ce qu'offre le terminal. Claude Code affiche une barre de progression à trois segments pour la fenêtre de contexte. claude-devtools répartit les tokens consommés par tour sur sept catégories : CLAUDE.md (global, projet, répertoire), skills, fichiers mentionnés avec @, entrées et sorties d'outils, réflexion, surcharge liée à l'équipe, et texte utilisateur. Le README mentionne également une visualisation de la compaction.

L'intérêt pratique est limité à un cas précis : comprendre pourquoi une session longue finit par saturer la fenêtre de contexte. Une barre à trois segments ne dit pas si le poids vient des fichiers joints, de la mémoire projet ou des allers-retours d'outils. Une répartition par catégorie le dit. Cela reste une lecture a posteriori : l'outil vous montre où les tokens sont partis, il ne vous empêche pas de les dépenser. Le README ne décrit aucun mécanisme d'alerte ou de seuil, donc ne comptez pas dessus pour prévenir une dérive en cours de session.

Installer et lancer

Sur macOS, la voie la plus courte passe par Homebrew :

brew install --cask claude-devtools

Sinon, les releases GitHub fournissent un .dmg arm64 ou x64 selon l'architecture, à glisser dans Applications. Le README signale qu'au premier lancement il faut faire un clic droit puis Open, ce qui indique une application non notariée. Sur Linux, les formats .AppImage, .deb, .rpm et .pacman sont proposés. Sur Windows, un installateur .exe classique, avec un avertissement SmartScreen que le README décrit : More info puis Run anyway.

Le déploiement Docker se fait avec docker compose up, puis l'interface est accessible sur http://localhost:3456. C'est la seule voie qui ne suppose pas un accès direct au système de fichiers de l'utilisateur depuis une application de bureau. Le README ne précise pas comment les journaux sont montés dans le conteneur, donc ce point est à vérifier dans le fichier compose avant de compter sur cette option. Le README ne mentionne aucune clé de configuration ni fichier de réglages : la promesse est « zéro configuration ».

Ce que l'outil ne fait pas

Trois limites méritent d'être posées avant l'installation.

La première concerne la plateforme et le mode de distribution. Le README décrit une application de bureau Electron, avec des binaires par architecture et par système. Sur un serveur de build sans affichage, ou dans un conteneur où ~/.claude/ n'est pas monté, l'application de bureau ne sert à rien. Le mode Docker existe, mais le README renvoie à une section de déploiement sans détailler le montage des volumes.

La deuxième concerne le périmètre. claude-devtools lit des fichiers, il ne les produit pas. Si une session n'a pas été journalisée, ou si les journaux ont été purgés, il n'y a rien à reconstruire. Le README ne décrit aucune fonction d'export, d'archivage ou de rétention. La durée de conservation des transcripts dépend donc entièrement de Claude Code, pas de cet outil.

La troisième concerne l'usage en automatisation. Rien dans le matériel fourni n'indique une interface en ligne de commande, une API locale ou un format de sortie exploitable par un script. Si votre besoin est de vérifier automatiquement qu'une session n'a pas touché un fichier interdit, cet outil n'est pas le bon point d'entrée. C'est un outil d'inspection visuelle, pas un composant de CI.

Face à --verbose et aux visionneuses de transcripts

L'alternative immédiate est l'option --verbose de Claude Code, déjà présente. La différence n'est pas une question de complétude : --verbose montre probablement plus de matière brute que claude-devtools, puisqu'il inclut les prompts système internes. La différence est le coût de lecture. --verbose produit un flux JSON continu, sans regroupement par tour ni hiérarchie entre agent parent et sous-agents. claude-devtools applique une structure : un tour, ses appels d'outils, ses tokens, ses éventuels sous-agents. Le compromis est réel : vous échangez l'accès au brut contre une vue organisée, et vous perdez ce que l'interface ne juge pas utile d'afficher.

Une autre famille d'alternatives existe : les visionneuses de transcripts qui lisent les mêmes fichiers ~/.claude/ et les affichent en texte. La différence tient à la reconstruction. Afficher un transcript, c'est rendre le JSON lisible. Reconstruire, c'est recalculer des relations que le fichier ne contient pas explicitement : quel appel d'outil appartient à quel sous-agent, quelle part du contexte vient de CLAUDE.md à ce tour précis. C'est cette étape de calcul qui justifie une application avec interface plutôt qu'un simple visualiseur. Le README ne décrit pas la méthode de calcul, donc il faut prendre cette distinction comme une lecture de l'architecture annoncée, pas comme une garantie.

Licence, maintenance et coût de mise à jour

Le projet est publié sous licence MIT. Concrètement, cela autorise la réutilisation, la modification et la redistribution du code, y compris dans un contexte commercial, à condition de conserver l'avis de copyright et le texte de la licence. Le README ne mentionne aucune clause additionnelle, aucun CLA et aucune restriction sur les contributions. Cela ne constitue pas un avis juridique : si vous redistribuez l'outil dans un produit, faites relire les fichiers LICENSE et les mentions de ressources tierces, notamment les polices et les icônes, qui ne sont pas détaillées dans le matériel fourni.

Le rythme de publication est soutenu. Trois versions en trois semaines : v0.4.15 le 30 avril 2026, v0.4.16 le 6 mai, v0.5.0 le 13 mai. Le numéro reste en 0.x, ce qui signale que l'API interne et le format de données ne sont pas figés. Pour un utilisateur, cela veut dire deux choses. Les mises à jour sont fréquentes, donc la compatibilité avec un changement de format de Claude Code est traitée rapidement. Mais une version 0.x peut casser entre deux publications mineures, et rien dans le matériel fourni n'indique une politique de compatibilité ou un canal de versions LTS. Si vous installez via Homebrew, la mise à jour se fait avec la commande de mise à jour habituelle de Homebrew. Sur les autres plateformes, il faut retélécharger le binaire depuis les releases, ce qui suppose de suivre le dépôt manuellement.

Conclusion éditoriale

À adopter si vous déboguez régulièrement des sessions Claude Code qui échouent sans explication, et si installer une application de bureau sur votre machine ne pose pas de problème. À éviter si votre travail se fait dans un conteneur sans accès à ~/.claude/, ou si vous voulez automatiser l'analyse dans un pipeline. Avant de vous engager, vérifiez deux choses : que le format des transcripts produits par votre version de Claude Code est bien celui que l'outil sait lire, et que le paquet de votre distribution est disponible dans la dernière release.

Sources officielles

1. License: MIT
2. matt1398/claude-devtools on GitHub
3. Project website
4. README
5. Releases