Configuration Admin

La configuration administrateur, aussi appelée configuration gérée, permet aux administrateurs d'Organization et d'espace de travail de distribuer les paramètres de Vibe Code CLI et de l'extension VS Code à tous les utilisateurs. Vous la définissez une fois dans l'Admin Panel, puis les deux clients l'appliquent aux utilisateurs de l'Organization ou de l'espace de travail. Utilisez-la pour distribuer des modèles, des fournisseurs, des serveurs MCP et des politiques d'outils sans demander aux utilisateurs de modifier config.toml.

Contrairement à config.toml, la configuration administrateur n'est pas modifiée sur la machine de l'utilisateur. La CLI la récupère en HTTP au démarrage d'une session et en conserve une copie dans ~/.vibe/managed_config_cache.json, pour l'utiliser si la récupération suivante échoue. Elle n'écrit jamais la configuration administrateur dans config.toml.

La configuration administrateur est disponible à deux niveaux :

• Niveau Organization : configurez-la dans Admin Panel›Vibe›Preferences ↗. Elle s'applique aux utilisateurs de chaque espace de travail qui ne définit pas sa propre configuration.
• Niveau espace de travail : ouvrez Admin Panel›Administration›Workspaces ↗, sélectionnez un espace de travail, puis ouvrez Settings. Un espace de travail peut utiliser la configuration définie au niveau de l'Organization, la remplacer par la sienne ou désactiver la configuration administrateur pour ses utilisateurs.

Le serveur ne fusionne pas les deux configurations. Chaque utilisateur en reçoit une, choisie par son espace de travail :

La prise en charge de la configuration administrateur commence avec les versions suivantes :

Les versions antérieures ne demandent pas la configuration administrateur et n'appliquent pas ses paramètres. Mettez à niveau tous les clients avant de distribuer une configuration administrateur.

1. Dans Admin Panel›Vibe›Preferences ↗, ou dans les Settings d'un espace de travail, saisissez une configuration TOML sous Vibe Code Clients managed config.
2. Au démarrage d'une session, la CLI appelle l'endpoint de configuration gérée avec la clé API Mistral de l'utilisateur et attend la réponse, quelques secondes au maximum. /reload la récupère à nouveau.
3. Si la configuration administrateur est activée, ses valeurs ont priorité sur toutes les autres sources de configuration. La session les suit dès son premier message : agent de départ, connecteurs, serveurs MCP et outils.

La gestion de la configuration administrateur nécessite l'autorisation de contrôle d'accès basé sur les rôles (RBAC) manage_code_config au niveau de l'Organization. Les administrateurs d'Organization peuvent déléguer cette gestion sans accorder un accès administrateur complet.

Les administrateurs d'espace de travail peuvent gérer la configuration de leur propre espace de travail.

Le processus d'activation dépend du type de déploiement :

La configuration administrateur est la couche prioritaire. Elle prévaut sur les options de ligne de commande, les variables d'environnement, ainsi que les deux fichiers config.toml, celui du projet et celui de l'utilisateur :

admin config  >  agent settings  >  CLI flags  >  VIBE_* env vars  >  project config.toml  >  user config.toml

admin config  >  agent settings  >  CLI flags  >  VIBE_* env vars  >  project config.toml  >  user config.toml

Cette priorité signifie que les valeurs fournies par l'administrateur s'appliquent aux utilisateurs par défaut, sans qu'ils aient à mettre à jour leur propre config.toml.

La configuration Admin accepte la plupart des mêmes clés que config.toml, par exemple :

• Modèle actif, modèles et providers.
• Les serveurs MCP, et la possibilité même pour les utilisateurs d'utiliser des serveurs MCP.
• La possibilité pour les utilisateurs d'approuver automatiquement tous les appels d'outils.
• Connecteurs, ainsi que les outils, agents et skills activés ou désactivés.
• L'agent de départ.
• Les interrupteurs de télémétrie, de vérification des mises à jour et de notifications.

active_model = "mistral-medium-3.5"
enable_update_checks = false
disabled_tools = ["bash"]

active_model = "mistral-medium-3.5"
enable_update_checks = false
disabled_tools = ["bash"]

Un cas d’usage courant consiste à fournir à toute l’organisation des modèles prêts à l’emploi dès le départ. Au lieu de laisser chaque utilisateur configurer manuellement les fournisseurs et les modèles, les Admin livrent une fois le modèle et le fournisseur appropriés, pointés vers votre endpoint d’entreprise avec le bon backend, l’URL de base et les en-têtes corrects. Les utilisateurs obtiennent une configuration fonctionnelle au premier lancement, sans rien avoir à configurer.

active_model = "mistral-large-enterprise"

[[providers]]
name = "acme-enterprise"
backend = "mistral"
api_base = "https://mistral.acme.internal/v1"
api_key_env_var = "ACME_MISTRAL_API_KEY"
api_style = "openai"

[providers.extra_headers]
"x-acme-tenant" = "engineering"

[[models]]
name = "mistral-large-2411"
provider = "acme-enterprise"
alias = "mistral-large-enterprise"

active_model = "mistral-large-enterprise"

[[providers]]
name = "acme-enterprise"
backend = "mistral"
api_base = "https://mistral.acme.internal/v1"
api_key_env_var = "ACME_MISTRAL_API_KEY"
api_style = "openai"

[providers.extra_headers]
"x-acme-tenant" = "engineering"

[[models]]
name = "mistral-large-2411"
provider = "acme-enterprise"
alias = "mistral-large-enterprise"

Ici, le modèle mistral-large-2411 est accessible via le fournisseur acme-enterprise, exposé aux utilisateurs sous l'alias mistral-large-enterprise, défini comme modèle actif. Les identifiants sont toujours fournis localement via la variable d'environnement ACME_MISTRAL_API_KEY.

Utilisez la clé de premier niveau allowed_models pour limiter les modèles que les utilisateurs peuvent sélectionner. Elle accepte une liste de motifs. Chaque motif correspond au nom canonique du modèle au niveau de l'API : le champ name d'un préréglage [[models]] ou l'identifiant d'un modèle intégré. Il s'agit du nom de modèle envoyé à l'API d'inférence : donner un alias différent à un modèle ne change donc pas les motifs qui correspondent.

Les patterns prennent en charge trois modes de correspondance :

Lorsque la liste contient au moins un pattern, seuls les modèles correspondants peuvent être sélectionnés dans le sélecteur de modèles. Cette restriction s'applique à la fois à la CLI Vibe Code et à l'extension VS Code. Une liste vide ou absente n'a aucun effet.

active_model = "mistral-large-enterprise"
allowed_models = ["mistral-vibe-cli-*"]

[[models]]
name = "mistral-vibe-cli-latest"
provider = "mistral"
alias = "mistral-large-enterprise"

active_model = "mistral-large-enterprise"
allowed_models = ["mistral-vibe-cli-*"]

[[models]]
name = "mistral-vibe-cli-latest"
provider = "mistral"
alias = "mistral-large-enterprise"

Combinez allowed_models avec les modèles que vous distribuez : livrez les préréglages [[models]] dont les utilisateurs ont besoin, et excluez tous les autres modèles.

Une liste mcp_servers vide dans la configuration administrateur ne supprime pas les serveurs que les utilisateurs ajoutent eux-mêmes. Pour bloquer les serveurs MCP, définissez enable_mcp sur false :

enable_mcp = false

enable_mcp = false

Avec enable_mcp = false, les clients Vibe Code :

• Refusent d'ajouter, de supprimer, d'activer ou de désactiver des serveurs MCP, par exemple avec vibe mcp ou /mcp.
• Refusent de se connecter aux serveurs MCP OAuth ou de s'en déconnecter.
• Ne chargent aucun outil depuis les serveurs MCP, y compris les serveurs fournis par des plugins.

Les utilisateurs qui tentent l'une de ces actions voient un message indiquant que leur administrateur a désactivé les serveurs MCP. Les clients appliquent ce paramètre ; comme le reste de la configuration administrateur, il ne constitue pas une frontière de sécurité. Il nécessite Vibe Code CLI 3.0 ou une version ultérieure. Les Connecteurs disposent d'un paramètre distinct, enable_connectors.

Pour bloquer tous les connecteurs, y compris la recherche sur le Web intégrée, définissez enable_connectors sur false :

enable_connectors = false

enable_connectors = false

Pour bloquer un connecteur, ajoutez une entrée [[connectors]] avec le nom du connecteur, tel qu'il apparaît dans /connectors :

[[connectors]]
name = "web_search"
disabled = true

[[connectors]]
name = "web_search"
disabled = true

Pour bloquer seulement certains outils d'un connecteur, listez-les dans le champ disabled_tools de l'entrée, sans le préfixe du connecteur :

[[connectors]]
name = "web_search"
disabled_tools = ["weather_search"]

[[connectors]]
name = "web_search"
disabled_tools = ["weather_search"]

Dans les clés de premier niveau enabled_tools et disabled_tools, et dans les blocs [tools.<tool_name>], un outil de connecteur porte le nom connector_<connector>_<tool> :

disabled_tools = ["connector_web_search_*"]

[tools.connector_web_search_weather_search]
permission = "ask"

disabled_tools = ["connector_web_search_*"]

[tools.connector_web_search_weather_search]
permission = "ask"

Définissez default_agent pour choisir l'agent dans lequel chaque session démarre, et enabled_agents ou disabled_agents pour limiter les agents vers lesquels les utilisateurs peuvent basculer. Les deux listes acceptent des motifs de nom d'agent : noms exacts, globs ou expressions régulières précédées de re:.

default_agent = "ask"
disabled_agents = ["auto-approve"]

default_agent = "ask"
disabled_agents = ["auto-approve"]

Les sessions ne s'exécutent jamais dans un agent que la configuration administrateur exclut. Si un utilisateur en demande un, par exemple avec --agent, la session démarre dans default_agent à la place.

Pour empêcher les utilisateurs de contourner les demandes d'approbation avec le mode d'approbation automatique, définissez enable_auto_approve sur false :

enable_auto_approve = false

enable_auto_approve = false

Avec enable_auto_approve = false, la CLI Vibe Code :

• Masque l'agent auto-approve et tout agent personnalisé ayant safety = "yolo". Si le --agent ou le default_agent d'une session désigne l'un d'eux, elle démarre plutôt dans un autre agent, comme pour tout agent que la configuration administrateur exclut.
• Ignore --auto-approve et --yolo, et affiche un avertissement indiquant que les demandes d'approbation restent actives. Il ignore aussi bypass_tool_permissions = true.

Les autorisations par outil s'appliquent toujours : un outil défini sur always dans [tools.<tool_name>], ou une commande de son allowlist, s'exécute toujours sans approbation. Comme le reste de la configuration administrateur, ce paramètre ne constitue pas une frontière de sécurité. Il nécessite Vibe Code CLI 3.0.1 ou une version ultérieure.

La configuration Admin ne contient jamais de secrets en clair. Les champs d’identifiants doivent référencer une variable d’environnement, par exemple api_key_env_var = "MISTRAL_API_KEY", jamais la clé elle-même. Les clés API, tokens ou mots de passe en clair sont rejetés par le serveur.

Lorsque la configuration administrateur est active, les utilisateurs de Vibe Code CLI voient les éléments suivants :

• Les paramètres gérés par l'administrateur sont en lecture seule dans /config : les utilisateurs ne peuvent pas les modifier ni les réinitialiser. Le panneau Où c'est défini de l'éditeur de paramètres indique l'administrateur comme source.
• Il n'y a ni bannière de démarrage ni indicateur global.
• Le démarrage d'une session attend la configuration administrateur, quelques secondes au maximum. La CLI n'écrit jamais la configuration administrateur dans le config.toml local.
• Si la récupération échoue, la session utilise la dernière configuration administrateur reçue au cours des 7 derniers jours, ou s'exécute sans configuration administrateur.
• /reload récupère à nouveau la configuration administrateur. Les modifications de l'agent de départ et des connecteurs s'appliquent à partir de la session suivante.
• Si la CLI ne trouve pas de clé API Mistral, elle ignore la configuration administrateur.
• Si la configuration administrateur ne peut pas être appliquée, la CLI tente la dernière configuration administrateur reçue, puis revient à la configuration locale de l'utilisateur, sans aucune configuration administrateur. Elle affiche : Your administrator-managed configuration could not be applied: <reason>. Cela arrive quand la configuration administrateur est invalide ou ne correspond pas à la configuration de l'utilisateur, par exemple une entrée [[models]] dont le provider n'est pas défini, ou un system_prompt_id que le projet de l'utilisateur ne fournit pas.

Pour arrêter d'appliquer la configuration administrateur, soumettez une configuration vide. Les utilisateurs qui ne peuvent pas atteindre l'endpoint de configuration gérée conservent la dernière configuration reçue pendant au maximum 7 jours.

Si les utilisateurs de déploiements dédiés ou auto-hébergés ne reçoivent pas la configuration administrateur, vérifiez les endpoints et les domaines.

Le client doit accéder à deux endpoints authentifiés :

• <console_base_url>/api/vibe/whoami renvoie les domaines Vibe et API du tenant dans vibe_base et api_base.
• <vibe_base_url>/api/v1/code/managed-config renvoie la réponse de configuration administrateur. Le client déduit vibe_base_url de la valeur vibe_base renvoyée par /whoami.

Définissez les URL du déploiement de l'utilisateur, vérifiez que MISTRAL_API_KEY est disponible dans l'environnement, puis exécutez les deux requêtes depuis cet environnement :

CONSOLE_BASE_URL="https://console.mistral.ai"
VIBE_BASE_URL="https://chat.mistral.ai"

curl --silent --show-error --fail-with-body \
  --header "Authorization: Bearer ${MISTRAL_API_KEY}" \
  "${CONSOLE_BASE_URL}/api/vibe/whoami"

curl --silent --show-error --fail-with-body \
  --header "Authorization: Bearer ${MISTRAL_API_KEY}" \
  "${VIBE_BASE_URL}/api/v1/code/managed-config"

CONSOLE_BASE_URL="https://console.mistral.ai"
VIBE_BASE_URL="https://chat.mistral.ai"

curl --silent --show-error --fail-with-body \
  --header "Authorization: Bearer ${MISTRAL_API_KEY}" \
  "${CONSOLE_BASE_URL}/api/vibe/whoami"

curl --silent --show-error --fail-with-body \
  --header "Authorization: Bearer ${MISTRAL_API_KEY}" \
  "${VIBE_BASE_URL}/api/v1/code/managed-config"

Pour les déploiements dédiés et auto-hébergés, remplacez les deux URL par les origines de la console et de Vibe propres au déploiement.

• Si une requête ne peut pas se connecter, vérifiez la configuration DNS, TLS et réseau du déploiement. Contactez votre équipe de compte ou le support Mistral si l'endpoint reste indisponible.
• Si une requête renvoie 401 ou 403, vérifiez la clé API et l'accès de l'utilisateur.
• Si les deux requêtes renvoient un code HTTP de succès, vérifiez les domaines.

La réponse de /whoami doit contenir les origines vibe_base et api_base attendues. Le client enregistre une valeur vibe_base valide sous vibe_base_url dans le fichier config.toml de l'utilisateur. Il l'utilise pour construire l'URL de configuration gérée.

Si /whoami renvoie un domaine incorrect, contactez le support Mistral pour corriger la configuration du serveur. Si la réponse est correcte mais que le client ne récupère pas la configuration administrateur, examinez le client Vibe Code.