Admin config

Admin config, also called managed config, lets Organization and Workspace administrators distribute settings for the Vibe Code CLI and the VS Code extension to all users. You define it once in the Admin Panel, and both clients apply it to users in the Organization or Workspace. Use it to distribute models, providers, MCP servers, and tool policies without requiring users to edit config.toml.

Unlike config.toml, admin config isn't edited on the user's machine. The CLI fetches it over HTTP when a session starts and keeps a copy in ~/.vibe/managed_config_cache.json, to use when the next fetch fails. It never writes admin config to config.toml.

Admin config is available at two scopes:

• Organization level: configure it in Admin Panel›Vibe›Preferences ↗. It applies to users in every Workspace that doesn't set its own.
• Workspace level: open Admin Panel›Administration›Workspaces ↗, select a Workspace, and open Settings. A Workspace can use the Organization-level configuration, replace it with its own, or turn admin config off for its users.

The server doesn't merge the two configurations. Each user receives one, chosen by the user's Workspace:

Support for admin config starts with these client versions:

Earlier clients don't request admin config or apply its settings. Upgrade every client before you distribute an admin config.

1. In Admin Panel›Vibe›Preferences ↗, or in a Workspace's Settings, enter a TOML configuration under Vibe Code Clients managed config.
2. When a session starts, the CLI calls the managed-config endpoint with the user's Mistral API key and waits for the answer, a few seconds at most. /reload fetches it again.
3. If admin config is enabled, its values take precedence over every other configuration source. The session follows them from its first message: starting agent, connectors, MCP servers, and tools.

Managing admin config requires the manage_code_config role-based access control (RBAC) permission at the Organization scope. Organization administrators can delegate admin config management without granting full administrator access.

Workspace administrators can manage the configuration of their own Workspace.

The activation process depends on the deployment type:

Admin config is the highest-priority layer. It takes precedence over command-line flags, environment variables, and both project and user config.toml:

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

This precedence means the admin-provided values take effect for users by default, without them needing to update their own config.toml.

Admin config accepts most of the same keys as config.toml, for example:

• Active model, models, and providers.
• MCP servers, and whether users can use MCP servers at all.
• Whether users can auto-approve every tool call.
• Connectors, and enabled/disabled tools, agents, and skills.
• The starting agent.
• Telemetry, update check, and notification toggles.

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"]

A common use is giving everyone in the organization ready-to-use models out of the box. Instead of each user manually setting up providers and models, admins ship the right model and provider once, pointed at your enterprise endpoint with the correct backend, base URL, and headers. Users get a working setup on first launch, with nothing to configure.

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"

Here the model mistral-large-2411 is served through the acme-enterprise provider, exposed to users under the alias mistral-large-enterprise, which is set as the active model. The credential is still supplied locally via the ACME_MISTRAL_API_KEY environment variable.

Use the top-level allowed_models key to limit which models users can select. It takes a list of patterns. Each pattern matches the model's canonical API name: the name field of a [[models]] preset or a built-in model ID. This is the model name sent to the inference API, so giving a model a different alias doesn't change what patterns match.

Patterns support three matching modes:

When the list contains at least one pattern, only matching models are selectable in the model picker. This restriction applies to both the Vibe Code CLI and the VS Code extension. An empty or missing list has no effect.

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"

Combine allowed_models with the models you distribute: ship the [[models]] presets users need, and filter out every other model.

An empty mcp_servers list in admin config doesn't remove the servers users add themselves. To block MCP servers, set enable_mcp to false:

enable_mcp = false

enable_mcp = false

With enable_mcp = false, the Vibe Code clients:

• Refuse to add, remove, enable, or disable MCP servers, for example with vibe mcp or /mcp.
• Refuse to sign in to or out of OAuth MCP servers.
• Load no tools from MCP servers, including servers provided by plugins.

Users who try one of these actions see a message that their administrator disabled MCP servers. The clients enforce this setting, so like the rest of admin config, it isn't a security boundary. It requires Vibe Code CLI 3.0 or later. Connectors have a separate setting, enable_connectors.

To block every connector, including the built-in web search, set enable_connectors to false:

enable_connectors = false

enable_connectors = false

To block one connector, add a [[connectors]] entry with the connector's name, as listed in /connectors:

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

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

To block only some of a connector's tools, list them in the entry's disabled_tools, without the connector prefix:

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

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

In the top-level enabled_tools and disabled_tools keys and in [tools.<tool_name>] blocks, a connector tool is named 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"

Set default_agent to choose the agent every session starts in, and enabled_agents or disabled_agents to limit the agents users can switch to. Both lists take agent name patterns: exact names, globs, or regular expressions prefixed with re:.

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

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

Sessions never run in an agent the admin config excludes. If a user asks for one, for example with --agent, the session starts in default_agent instead.

To stop users from skipping approval prompts with the auto-approve mode, set enable_auto_approve to false:

enable_auto_approve = false

enable_auto_approve = false

With enable_auto_approve = false, the Vibe Code CLI:

• Hides the auto-approve agent and every custom agent with safety = "yolo". A session whose --agent or default_agent names one of them starts in another agent instead, as for any agent the admin config excludes.
• Ignores --auto-approve and --yolo, and shows a warning that approval prompts stay on. It also ignores bypass_tool_permissions = true.

Per-tool permissions still apply: a tool set to always in [tools.<tool_name>], or a command in its allowlist, still runs without approval. Like the rest of admin config, this setting isn't a security boundary. It requires Vibe Code CLI 3.0.1 or later.

Admin config never contains literal secrets. Credential fields must reference an environment variable (for example, api_key_env_var = "MISTRAL_API_KEY"), never the key itself. Literal API keys, tokens, or passwords are rejected on the server.

When admin config is active, users in the Vibe Code CLI notice the following:

• Admin-managed settings are read-only in /config: users can't edit or reset them. The settings editor's Where it's set panel lists the administrator as a source.
• There is no startup banner or global indicator.
• Starting a session waits for admin config, a few seconds at most. The CLI never writes admin config to the local config.toml.
• If the fetch fails, the session uses the last admin config received in the past 7 days, or runs without admin config.
• /reload fetches admin config again. Changes to the starting agent and connectors apply from the next session.
• If the CLI can't find a Mistral API key, it skips admin config.
• If the admin config can't be applied, the CLI tries the last admin config it received, then falls back to the user's local configuration, with no admin config at all. It shows: Your administrator-managed configuration could not be applied: <reason>. This happens when the admin config is invalid or doesn't fit the user's setup, for example a [[models]] entry whose provider isn't defined, or a system_prompt_id the user's project doesn't provide.

To stop applying admin config, submit an empty configuration. Users who can't reach the managed-config endpoint keep the last configuration they received for up to 7 days.

If users in dedicated or self-hosted deployments don't receive admin config, check the endpoints and domain values.

The client needs to reach two authenticated endpoints:

• <console_base_url>/api/vibe/whoami returns the tenant's Vibe and API domains in vibe_base and api_base.
• <vibe_base_url>/api/v1/code/managed-config returns the admin config response. The client derives vibe_base_url from the vibe_base value returned by /whoami.

Set the URLs for the user's deployment, make sure MISTRAL_API_KEY is available in the environment, and run both requests from the user's environment:

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"

For dedicated and self-hosted deployments, replace both URL values with the deployment's console and Vibe origins.

• If either request fails to connect, check the deployment's DNS, TLS, and network configuration. Contact your account team or Mistral support if the endpoint remains unavailable.
• If either request returns 401 or 403, verify the user's API key and access.
• If both requests return a successful HTTP status, continue with the domain checks.

The /whoami response must contain the expected vibe_base and api_base origins. The client stores a valid vibe_base value as vibe_base_url in the user's config.toml and uses it to build the managed-config URL.

If /whoami returns an incorrect domain, contact Mistral support to correct the server configuration. If the response is correct but the client doesn't fetch admin config, investigate the Vibe Code client.