Configuration

La CLI Vibe Code se configure via un fichier config.toml. Cette page explique où se trouve ce fichier, comment l’ouvrir et les paramètres les plus courants à personnaliser.

La CLI fusionne deux fichiers config.toml :

1. Au niveau du projet : le fichier .vibe/config.toml le plus proche, trouvé en remontant l'arborescence depuis le répertoire de travail, sans dépasser votre répertoire racine.
2. Au niveau utilisateur : ~/.vibe/config.toml.

Les paramètres du projet priment sur les paramètres utilisateur correspondants, et tout ce que le fichier du projet ne définit pas provient du fichier utilisateur. La configuration du projet n'est chargée que si son dossier est approuvé.

/config enregistre les modifications dans le fichier utilisateur par défaut. Dans l'éditeur de paramètres, utilisez Enregistrer dans pour enregistrer dans le fichier du projet ou uniquement dans la session en cours.

Ouvrez ~/.vibe/config.toml avec votre éditeur par défaut :

# macOS
open ~/.vibe/config.toml

# Linux
xdg-open ~/.vibe/config.toml

# Windows (PowerShell)
Invoke-Item ~\.vibe\config.toml

# macOS
open ~/.vibe/config.toml

# Linux
xdg-open ~/.vibe/config.toml

# Windows (PowerShell)
Invoke-Item ~\.vibe\config.toml

Vous pouvez également ouvrir le menu de configuration depuis une session avec la commande slash /config.

Par défaut, la CLI stocke sa configuration et son état dans ~/.vibe/. Modifiez l’emplacement avec la variable d’environnement VIBE_HOME :

export VIBE_HOME="/path/to/custom/vibe/home"

export VIBE_HOME="/path/to/custom/vibe/home"

VIBE_HOME détermine l’emplacement des éléments suivants :

• config.toml : configuration principale.
• .env : clés API et identifiants de fournisseurs.
• agents/ : profils d’agents personnalisés.
• prompts/ : prompts système personnalisés.
• skills/ : Skills personnalisées.
• plugins/ : plugins de niveau utilisateur.
• tools/ : outils personnalisés.
• logs/ : journaux des sessions et de l’application.

Utilisez --workdir pour pointer la CLI vers un projet qui n’est pas le dossier courant :

vibe --workdir /path/to/project

vibe --workdir /path/to/project

Utilisez --add-dir pour donner à l'agent l'accès à un répertoire supplémentaire le temps d'une session. Répétez l'option pour plusieurs répertoires. Vibe approuve chaque répertoire pour la session, charge son fichier AGENTS.md et sa configuration .vibe/, et permet à l'agent d'y lire et d'y modifier des fichiers sans déclencher le prompt d'accès hors du répertoire de travail.

config.toml accepte de nombreuses clés et sections principales. Les plus courantes sont listées ici, chacune renvoyant vers une page dédiée.

Définissez l'agent par défaut :

default_agent = "ask"

default_agent = "ask"

Cela s'applique aussi bien aux sessions interactives qu'aux sessions programmatiques. Si ce paramètre n'est pas défini, Vibe utilise accept-edits. Voir Les agents.

Définissez des préréglages de fournisseur, des préréglages de modèle et le modèle actif. Vibe est livré avec un modèle intégré, Mistral Medium 3.5 (alias mistral-medium-3.5), et /model ne liste que les modèles configurés pour vous. Il les regroupe selon leur provenance : la configuration administrateur de votre organisation, les expériences, le catalogue de modèles, puis votre propre configuration.

Les modèles conversationnels suivants sont disponibles via l'API de Mistral (la Plateforme). Utilisez l'ID du modèle comme valeur de name dans un bloc [[models]] avec provider = "mistral", puis sélectionnez-le avec /model ou active_model :

Vous pouvez aussi fixer une version précise en remplaçant -latest par un suffixe de date (par exemple, mistral-medium-3-5 ou codestral-2508). Consultez la présentation des modèles pour voir toutes les versions disponibles.

Pour utiliser un modèle via un fournisseur tiers comme OpenRouter, définissez un fournisseur personnalisé et un préréglage de modèle :

active_model = "codestral-openrouter"

[[providers]]
name = "openrouter"
api_base = "https://openrouter.ai/api/v1"
api_key_env_var = "OPENROUTER_API_KEY"
api_style = "openai"
backend = "generic"

[[models]]
name = "mistralai/codestral"
provider = "openrouter"
alias = "codestral-openrouter"

active_model = "codestral-openrouter"

[[providers]]
name = "openrouter"
api_base = "https://openrouter.ai/api/v1"
api_key_env_var = "OPENROUTER_API_KEY"
api_style = "openai"
backend = "generic"

[[models]]
name = "mistralai/codestral"
provider = "openrouter"
alias = "codestral-openrouter"

Voir Clés API et profils.

Ajoutez des serveurs Model Context Protocol sous mcp_servers. Voir Serveurs MCP.

Activez, désactivez ou ajoutez des chemins de Skills :

skill_paths = ["/path/to/custom/skills"]
enabled_skills = ["code-review", "test-*"]
disabled_skills = ["experimental-*"]

skill_paths = ["/path/to/custom/skills"]
enabled_skills = ["code-review", "test-*"]
disabled_skills = ["experimental-*"]

enabled_skills et disabled_skills interagissent comme suit :

• Si enabled_skills est défini et non vide, seules les Skills dont le nom correspond à un motif de cette liste sont disponibles.
• Sinon, toutes les Skills détectées sont disponibles, sauf celles dont le nom correspond à un motif de disabled_skills.

Voir Skills.

Restreignez les outils accessibles à l’agent :

enabled_tools = ["serena_*"]
disabled_tools = ["bash"]

enabled_tools = ["serena_*"]
disabled_tools = ["bash"]

Les filtres d’outils acceptent les noms exacts, les glob patterns et les regex avec le préfixe re:. Des autorisations spécifiques peuvent aussi être définies dans des blocs [tools.<tool_name>]. Voir Sécurité, validations et permissions.

Exécutez des commandes shell arbitraires avant ou après les appels d'outils, ou à la fin de chaque tour de l'assistant, afin de filtrer, auditer ou réécrire le comportement de l'agent. Déclarez les hooks dans un fichier hooks.toml séparé. Voir Hooks.

Contrôlez la vérification des mises à jour, les notifications et la télémétrie :

enable_update_checks = true
enable_notifications = true
enable_telemetry = true

enable_update_checks = true
enable_notifications = true
enable_telemetry = true

Par défaut, Vibe valide les certificats HTTPS par rapport à ses racines de certification intégrées. Depuis Vibe 3.0, il applique des règles de validation plus strictes : une autorité de certification (CA) privée dépourvue de certaines extensions standard peut donc être rejetée. Si votre organisation installe son autorité de certification dans le magasin d'approbations du système d'exploitation, indiquez à Vibe d'utiliser ce magasin :

enable_system_trust_store = true

enable_system_trust_store = true

Vibe charge également les certificats des variables d'environnement SSL_CERT_FILE et SSL_CERT_DIR comme ancres de confiance supplémentaires. Pour configurer un proxy et des certificats depuis une session, exécutez /proxy-setup.

Les administrateurs de votre Organization ou de votre espace de travail peuvent distribuer une configuration de Vibe Code CLI à tous les utilisateurs. Les paramètres gérés par un administrateur sont prioritaires sur les options de ligne de commande, les variables d'environnement et les fichiers config.toml du projet et de l'utilisateur.

Lorsque la configuration administrateur est active :

• Les paramètres gérés par un administrateur sont en lecture seule dans /config : vous ne pouvez ni les modifier ni les réinitialiser. Le panneau Où c'est défini de l'éditeur de paramètres liste votre administrateur comme source.
• Les sessions suivent la configuration administrateur dès leur premier message. La CLI ne l'écrit jamais dans votre config.toml local.
• Si la configuration administrateur ne peut pas être appliquée, par exemple parce qu'elle est invalide ou ne convient pas à votre projet, la session s'exécute avec votre configuration locale à la place. La CLI affiche : Your administrator-managed configuration could not be applied: <reason>.

Lorsque le même paramètre est défini à plusieurs endroits, la CLI les applique dans cet ordre (priorité décroissante) :

1. Configuration administrateur, lorsque votre Organization ou votre espace de travail en fournit une. Voir Configuration administrateur.
2. Les paramètres de l'agent actif, issus de son fichier d'agent. Voir Les agents.
3. Les options de ligne de commande (par exemple, --enabled-tools) et les modifications enregistrées dans la session en cours via /config.
4. Les variables d'environnement VIBE_<KEY>, qui priment sur la clé de configuration du même nom (par exemple, VIBE_ACTIVE_MODEL).
5. Projet .vibe/config.toml.
6. Utilisateur ~/.vibe/config.toml.