Barre d'état Claude Code : la boucle de feedback la plus économique que vous n'utilisez pas

Par défaut, la barre d'état de Claude Code est vide. C'est un canal gâché. C'est la seule bande d'écran que l'agent met à jour gratuitement à chaque tour, et presque personne ne la câble. Cet article explique exactement comment fonctionne le mécanisme, puis décortique la véritable barre d'état Claude Code que nous livrons, pour vous montrer ce qui y a sa place et ce qui n'est que du bruit.

Ce qu'est réellement une barre d'état Claude Code

Une barre d'état Claude Code est un script que Claude Code exécute et affiche sous votre invite. Il transmet au script un payload JSON sur stdin (le modèle, l'espace de travail avec le répertoire courant, le coût, la fenêtre de contexte) et affiche textuellement, sur la barre d'état, tout ce que le script écrit sur stdout. C'est tout le contrat. N'importe quel langage fonctionne, car l'interface se résume à ceci : stdin en entrée, une ligne de texte en sortie.

Comme le payload transporte l'état vivant de la session, la barre d'état est le moyen le plus économique de garder cet état à l'écran. Sans elle, vous interrompez l'agent pour lui demander « quel est ce modèle » ou « combien cela a-t-il coûté ». Avec elle, la réponse se trouve déjà sous votre invite, mise à jour lors des mêmes événements que la session déclenche de toute façon.

Comment Claude Code appelle le script

Claude Code lance le processus de la barre d'état lors de mises à jour événementielles : après chaque message de l'assistant, lors d'un /compact et lors des changements de mode de permission, avec un debounce de 300 ms. Il ne fait pas de polling sur un timer, sauf si vous définissez refreshInterval. Le stdout du script est un pipe, pas un tty : il doit donc déterminer la couleur à partir de l'environnement plutôt que via isTTY.

Ces deux faits dictent des choix concrets dans notre script. Nous laissons volontairement refreshInterval non défini, car tout ce que la ligne affiche change précisément lors des événements sur lesquels Claude Code se rafraîchit déjà. Un timer ne ferait que lancer un processus Node pour redessiner une ligne identique. Voici le câblage, écrit dans settings.json à l'installation :

Ce détail de chemin absolu n'est pas du pinaillage. Nous câblons chaque script du moteur avec un chemin Node explicite, car une simple commande node échoue en silence lorsque le shell lancé par Claude Code possède un PATH différent, et une barre d'état qui échoue en silence est pire que pas de barre d'état du tout. Si vous en êtes encore à la configuration, notre guide d'installation détaille l'environnement dont tout ceci dépend.

Lecture de notre véritable barre d'état Claude Code

Notre barre d'état fait 74 lignes et son rôle est d'être le navigateur : toujours à l'écran, jamais dans le chemin. Elle lit le JSON sur stdin, récupère le répertoire courant, charge la configuration du kit et le parcours du projet, puis affiche une seule ligne. Sa colonne vertébrale ressemble à ceci :

Les choix de conception sont visibles dans le code. S'il n'y a pas de plan, elle affiche ready · /start to plan : une barre d'état qui indique aussi au débutant le prochain geste. Si un plan existe, elle affiche le nom du projet, une barre de progression, step N of M, et le titre de l'étape courante tronqué à 24 caractères. Quand toutes les étapes sont terminées, elle indique all N steps done · time to /ship. La ligne pointe toujours vers l'action suivante, jamais seulement vers l'état.

Elle ajoute deux autres éléments, uniquement lorsqu'ils sont vrais. Si le moteur de clarté est armé, elle ajoute · asking first en corail, pour que vous voyiez d'un coup d'œil que l'agent demandera avant de construire. Si le tuteur est désactivé, elle affiche en grisé · tutor off. Rien de statique n'est jamais rendu. C'est la règle d'une barre d'état : chaque caractère doit mériter sa place, car il coûte de l'attention à chaque tour.

Fail open, toujours

Une barre d'état ne doit jamais casser le terminal. La nôtre est encapsulée de sorte qu'une configuration manquante, un parcours absent ou n'importe quelle erreur levée se résolvent en une ligne vide plutôt qu'en une trace d'appels sous votre invite. Tout le rendu tient dans un try qui avale les échecs :

La barre d'état n'est qu'une partie du moteur

La barre d'état est la partie émergée d'un système plus vaste. Le kit câble huit scripts de hook sur huit événements du cycle de vie : début de session, soumission de l'invite, pré-compactage, démarrage du sous-agent, pré-utilisation d'outil, post-utilisation d'outil, arrêt et fin de session. Le verrou de clarté qui force l'agent à demander d'abord, la vérification anti-slop qui tourne après les modifications, le tuteur qui se déclenche au bon moment : tout cela vit dans les hooks. La barre d'état est l'endroit où leur état devient visible.

C'est cette intégration qui rend la ligne rentable. asking first n'est pas une décoration. C'est le hook de clarté qui signale qu'il est armé. La barre de progression, c'est le parcours chargé par le hook de début de session. La barre d'état est une fenêtre en lecture seule sur le moteur, ce qui est l'usage honnête de cette surface : montrer l'état, pas l'inventer.

Ce que cela coûte, mesuré

Nous avons mené un benchmark en environnement isolé du kit face à Claude Code sans le kit, et nous ne cachons pas les défaites. Sur le « demander d'abord », le kit a obtenu 5 sur 5 contre 2 sur 5 sans le kit, en produisant environ 40 pour cent de code en moins pour le même résultat. Mais les hooks qui alimentent la barre d'état ne sont pas gratuits. Sur une simple application de liste de tâches, le kit était environ deux fois plus lent et environ 75 pour cent plus cher pour un résultat quasi identique, et sur l'ensemble de la suite, les tokens de contexte des hooks ont ajouté un surcoût moyen d'environ 25 pour cent. Ce surcoût est réel et assumé. Il achète les garde-fous et le navigateur que vous voyez sur la ligne.

La leçon n'est pas que l'instrumentation coûte cher. C'est que l'instrumentation que vous ne regardez jamais est un coût pur. Une barre d'état est le seul élément qui se rembourse à chaque tour, car elle transforme un état que vous auriez interrompu l'agent pour obtenir en quelque chose de déjà affiché. Câblez-la. Affichez le modèle, le répertoire, le coût, l'étape. Laissez tout le reste de côté.

Questions fréquentes

Qu'est-ce qu'une barre d'état Claude Code ? C'est un script que vous enregistrez dans settings.json. Claude Code l'exécute, lui passe un payload JSON sur stdin contenant le modèle, l'espace de travail, le coût et la fenêtre de contexte, puis affiche tout ce que le script écrit sur stdout sur la ligne située sous votre invite. Elle se rafraîchit lors d'événements comme chaque message de l'assistant.

Comment configurer une barre d'état Claude Code ? Ajoutez une clé statusLine dans settings.json avec le type command et la commande pointant vers votre script, puis lisez le JSON sur stdin et écrivez une seule ligne sur stdout. Utilisez un chemin node absolu et explicite pour que le script ne meure pas en silence lorsque le shell de Claude Code utilise un PATH différent.

Que doit afficher une barre d'état Claude Code ? Un état que vous devriez sinon demander et qui change au fil de votre travail : le modèle, le répertoire de travail, le coût cumulé, et le plan ou l'étape en cours. Laissez de côté tout ce qui est statique et tout ce que vous voyez déjà dans l'invite. Une barre d'état coûte de l'attention, alors dépensez-la pour du signal.