Contrôle du répertoire de travail

Le répertoire de lancement définit le projet

Quand vous tapez vibe, l’agent adopte le répertoire courant comme répertoire de travail. Ce choix n’a rien d’anodin : c’est de cet emplacement que découle tout le contexte projet, puisque Vibe y scanne l’arborescence, y lit les fichiers de configuration et en déduit le type de projet.

cd /home/user/projets/mon-api
vibe
# → Vibe analyse le projet mon-api

Lancer Vibe depuis votre répertoire personnel plutôt que depuis le dépôt donne donc un agent qui ne comprend rien à votre code — non par incapacité, mais parce qu’il regarde au mauvais endroit. Le cd fait partie de la commande, en pratique.

Travailler ailleurs sans se déplacer

Il arrive que le cd soit impossible ou peu commode. L’option --workdir désigne alors explicitement le répertoire cible :

vibe --workdir /home/user/projets/mon-api

Le comportement est strictement celui d’un lancement depuis ce dossier : scan du projet, résolution des chemins de fichiers et commandes shell prennent tous ce répertoire pour base. Cette option rend service dans les scripts d’automatisation, où vous ne maîtrisez pas le répertoire courant, quand vous jonglez entre plusieurs projets sans vouloir changer de terminal, et en CI/CD pour pointer vers le dépôt fraîchement cloné. Le cas du script est le plus démonstratif, puisqu’il permet de traiter une série de projets en une boucle :

# Dans un script
for projet in api frontend worker; do
  vibe --workdir "/projets/$projet" \
       --prompt "Vérifie les vulnérabilités npm" \
       --output json > "audit-$projet.json"
done

Organiser le travail multi-projets

En interactif, la méthode la plus propre reste un terminal — ou un onglet tmux, ou un screen — par projet :

# Terminal 1 : API backend
cd /projets/api-backend
vibe

# Terminal 2 : Frontend
cd /projets/frontend-react
vibe

# Terminal 3 : Infrastructure
cd /projets/infra-terraform
vibe

Chaque instance possède alors son contexte, sa session et son historique, ce qui vous évite de retrouver des raisonnements Terraform mêlés à du React.

Cette séparation gagne à descendre jusque dans la configuration. Un fichier .vibe/config.toml déposé dans chaque projet adapte le comportement de l’agent à la codebase concernée. Pour une API Python :

# Projet API Python
# /projets/api-backend/.vibe/config.toml
cat > .vibe/config.toml << 'EOF'
active_model = "devstral-2"
system_prompt_id = "python_expert"

[tools.bash]
permission = "ask"
EOF

Et pour un front React, avec un serveur MCP en plus :

# Projet Frontend React
# /projets/frontend-react/.vibe/config.toml
cat > .vibe/config.toml << 'EOF'
active_model = "devstral-2"
system_prompt_id = "react_expert"

[[mcp_servers]]
name = "fetch"
transport = "stdio"
command = "uvx"
args = ["mcp-server-fetch"]
EOF

La règle d’arbitrage est simple à mémoriser : la configuration projet (./.vibe/config.toml) l’emporte sur la configuration globale (~/.vibe/config.toml). Chaque dépôt peut ainsi imposer son modèle, son prompt système et ses serveurs MCP, sans que vous ayez à modifier quoi que ce soit lorsque vous passez de l’un à l’autre.

Les dossiers de confiance

Le répertoire de travail détermine aussi ce que Vibe s’autorise à faire sans vous demander. Le système de dossiers de confiance repose sur ~/.vibe/trusted_folders.toml, qui liste les emplacements où certaines actions automatiques — l’auto-approve en particulier — sont permises.

# ~/.vibe/trusted_folders.toml
trusted = [
  "/home/user/projets/mon-api",
  "/home/user/projets/frontend",
]

Si vous activez l’auto-approve dans un répertoire absent de cette liste, Vibe vous avertit qu’il n’est pas considéré comme de confiance. C’est exactement le garde-fou souhaité le jour où vous clonez un dépôt inconnu pour dépanner un collègue.

Désigner les fichiers, et changer de dossier en cours de route

Dans vos échanges, @ accepte aussi bien un chemin relatif au répertoire de travail qu’un chemin absolu, et l’autocomplétion fonctionne dans les deux cas.

# Chemin relatif (recommandé)
Explique le code dans @src/api/routes.ts

# Chemin absolu
Explique le code dans @/home/user/projets/mon-api/src/api/routes.ts

Préférez le relatif : il se lit mieux et reste valable quel que soit l’utilisateur ou la machine, ce qui compte dès que vous partagez un prompt avec un collègue.

Enfin, rien n’interdit de naviguer ailleurs pendant une session, au moyen d’une commande shell :

!cd /autre/projet && ls

Sachez toutefois ce que vous obtenez : le contexte projet issu du scan initial reste celui du répertoire de lancement, et Vibe ne re-scanne pas automatiquement le nouveau dossier. L’agent verra les fichiers listés, mais raisonnera toujours sur l’architecture du projet de départ. Pour un vrai changement de contexte, ouvrez une nouvelle session.

Points clés à retenir

• Vibe utilise le répertoire courant comme contexte de projet au lancement
• --workdir permet de spécifier un répertoire sans s’y déplacer
• Un terminal par projet est l’approche la plus propre pour le multi-projet
• .vibe/config.toml par projet personnalise le comportement pour chaque codebase
• Le système Trust Folder sécurise l’auto-approve par répertoire
• Les chemins relatifs avec @ sont recommandés pour la lisibilité