Aller au contenu principal

Exécuter des commandes shell

Mis à jour le 29 juillet 2026

Un shell complet dans la session

Vibe embarque un terminal bash stateful. Le mot important est stateful : l’état persiste d’une commande à l’autre, ce qui signifie que les variables d’environnement que vous exportez, le répertoire courant dans lequel vous vous placez et les alias que vous définissez restent valables pour les commandes suivantes. Vous ne repartez pas de zéro à chaque appel, contrairement à ce qui se passe avec un outil qui lancerait un sous-shell jetable.

L’agent se sert de ce terminal dès qu’il en a besoin — lancer des tests, vérifier un statut, installer une dépendance — mais vous restez libre d’invoquer vous-même des commandes.

Le préfixe ! pour aller droit au but

Quand vous savez exactement ce que vous voulez exécuter, le plus rapide est le préfixe ! :

!ls -la src/
!git log --oneline -10
!npm run test -- --watch

Ce ! indique à Vibe que la suite est une commande shell à exécuter telle quelle, sans interprétation par l’agent. Le résultat s’affiche immédiatement, et vous restez dans le mode interactif.

L’autre voie consiste à laisser l’agent traduire votre intention. Demandez-lui de lancer les tests unitaires, d’installer la dépendance axios ou de vérifier que le serveur de développement démarre correctement : il détermine la commande adaptée à votre projet — npm, pip, cargo — et vous la propose pour approbation. C’est la voie à privilégier quand vous découvrez un projet dont vous ne connaissez pas encore les conventions d’outillage.

L’approbation, et comment l’assouplir

Par défaut, chaque commande shell exige votre feu vert. Vibe affiche exactement ce qu’il compte exécuter, puis attend :

L'agent souhaite exécuter :
  npm run test

Approuver ? (y/n)

Ce mécanisme est le garde-fou principal de l’outil. Un rm -rf proposé par erreur reste sans le moindre effet tant que vous ne l’avez pas approuvé — c’est la différence entre un incident et une ligne de texte que vous refusez d’un n.

Ce comportement se règle dans config.toml, avec des permissions fines par outil :

[tools.bash]
permission = "ask"  # Toujours demander (défaut)

# Ou pour un agent de confiance :
# permission = "always"  # Exécuter sans demander

Le même assouplissement existe à la volée : Shift+Tab bascule en mode auto-approve, dans lequel Vibe exécute les commandes sans confirmation. C’est confortable pendant une session de développement intensif où vous suivez l’agent pas à pas, mais à manier avec précaution, puisque vous renoncez justement au garde-fou décrit plus haut. Le système de Trust Folder vient limiter le risque : seuls les répertoires explicitement marqués comme sûrs dans ~/.vibe/trusted_folders.toml autorisent l’auto-approve. Un dépôt cloné pour dépannage et jamais déclaré n’en bénéficiera donc pas.

Enchaîner, référencer, rédiger

Le préfixe @ fonctionne aussi lorsqu’il s’agit de commandes : référencer un fichier en injecte le contenu dans le contexte, ce qui permet à l’agent de comprendre avant d’agir.

Lance le script @scripts/deploy.sh et explique-moi ce qu'il fait

L’agent lit d’abord le script, l’analyse, puis l’exécute si vous approuvez — un ordre particulièrement rassurant sur un script de déploiement dont vous n’êtes pas l’auteur.

Pour une séquence d’opérations, composez un message sur plusieurs lignes avec Ctrl+J ou Shift+Enter :

Exécute ces commandes dans l'ordre :
1. git stash
2. git pull origin main
3. git stash pop
4. npm install
5. npm run build

Vibe déroule les étapes séquentiellement, s’arrête si l’une échoue et vous montre le résultat de chacune, ce qui vous évite de découvrir l’échec du stash pop seulement après un build inutile. Et si le message à rédiger devient long ou structuré, Ctrl+G ouvre votre éditeur externe, celui défini par $EDITOR : vous rédigez confortablement, vous sauvegardez, vous fermez, et le contenu part vers Vibe.

Ce que ces commandes permettent au quotidien

La gestion des dépendances se prête bien à l’enchaînement automatique : « Mets à jour toutes les dépendances npm et vérifie qu’il n’y a pas de vulnérabilités » déclenche npm update, puis npm audit, et vous obtenez un résumé plutôt qu’un mur de sortie. C’est toutefois sur les tests que l’apport est le plus net, avec une demande comme « Lance les tests, et s’il y en a qui échouent, analyse les erreurs et propose des corrections » : exécution, diagnostic et proposition de correctif tiennent dans un seul échange.

Le même principe s’applique au reste de la chaîne : demander de builder le projet en mode production et de vérifier l’absence d’erreurs TypeScript, ou de lister les conteneurs Docker en cours d’exécution et d’afficher les logs du conteneur api. Dans tous ces cas, vous décrivez l’objectif, l’agent choisit les commandes, et vous gardez la main au moment d’approuver.

Points clés à retenir

  • Le préfixe ! exécute une commande shell directement depuis le mode interactif
  • L’agent peut aussi déterminer et exécuter les commandes appropriées en langage naturel
  • Chaque commande nécessite une approbation par défaut (modifiable dans config.toml)
  • Le terminal est stateful : variables et répertoire courant sont préservés
  • Le mode auto-approve (Shift+Tab) supprime les confirmations — à utiliser avec précaution
  • Le système Trust Folder sécurise l’auto-approve par répertoire