Accueil / Fondamentaux et boucle d'agent

Exécuter des commandes shell

L'outil Bash exécute une vraie commande shell sur votre poste, pas une simulation, puis Claude Code lit la sortie standard et la sortie d'erreur pour poursuivre à partir de ce qui a réellement été produit. Une invite de permission s'affiche avant chaque commande nouvelle, sauf pour un jeu intégré de commandes en lecture seule.

L'outil Bash exécute une vraie commande shell sur votre poste, pas une simulation. Claude Code lit ensuite la sortie standard et la sortie d'erreur de cette commande pour poursuivre son raisonnement à partir de ce qu'elle a réellement produit, et non de ce qui était attendu.

Une invite avant chaque commande nouvelle

Avant qu'une commande shell nouvelle ne s'exécute, une invite de permission s'affiche à l'écran. La documentation officielle décrit ce comportement pour les commandes shell comme une confirmation demandée à chaque fois, sauf pour un jeu intégré de commandes en lecture seule qui s'exécutent directement. Répondre avec l'option qui mémorise le choix rend cette commande précise approuvée de façon permanente, mais seulement pour le dépôt en cours et pour cette commande précise : ce n'est pas une autorisation générale qui s'étendrait à toute commande shell future.

Le motif global qui réactive l'invite

Une commande déjà approuvée peut malgré tout redéclencher l'invite. Quand un motif global non protégé figure dans les arguments d'une commande à drapeaux capables d'écrire ou d'exécuter, par exemple find, sort, sed ou git, l'invite réapparaît même si la commande de base figure déjà sur la liste des commandes de confiance. Ce motif pourrait se développer, au moment de l'exécution, en un drapeau destructeur que personne n'avait approuvé. Ce garde-fou n'est pas un défaut, c'est une protection posée au-dessus de la liste de confiance elle-même.

Cet exemple autonome fabrique son propre fichier avant de le lire, plutôt que d'inspecter un fichier réel du projet :

mkdir -p /tmp/demo-bash
echo "erreur : connexion refusée" > /tmp/demo-bash/journal.txt
grep "erreur" /tmp/demo-bash/journal.txt

La dernière ligne rend le contenu trouvé, erreur : connexion refusée. C'est exactement ce que Claude reçoit en retour d'un appel à l'outil Bash, la sortie brute de la commande, rien de reconstitué et rien de supposé.

Cette lecture de la sortie réelle avant de poursuivre est ce qui fait tourner la boucle d'agent : réfléchir, appeler un outil, observer ce qu'il rend vraiment, recommencer. Le même principe d'approbation au cas par cas se retrouve dans la lecture d'un diff de modification de fichier, où seul le type d'action change.

Les guillemets sautent d'un shell à l'autre

Un script passé en argument à un autre programme arrive parfois déformé, sans message d'erreur clair. Dans l'exemple suivant, les accents graves dans une chaîne entre guillemets doubles sont exécutés par le shell avant que Node ne voie le texte :

node -e "console.log('dossier `echo REMPLACE` fini')"

dossier REMPLACE fini

Le texte écrit était « echo REMPLACE » entre accents graves, et Node a reçu le résultat de la commande. La parade tient en deux lignes : écrivez le script dans un fichier avec un délimiteur entre apostrophes, puis passez son chemin.

cat > note.js << 'EOF'
console.log('dossier `echo REMPLACE` fini')
EOF
node note.js

dossier `echo REMPLACE` fini

Le même risque existe entre PowerShell, cmd, ssh et Git Bash, qui se disputent chacun les guillemets. Dès qu'une commande contient des guillemets imbriqués, mettez-la dans un fichier, ou vérifiez l'écho de ce qui part avant de lancer.