Configuration

The Vibe Code CLI is configured through a config.toml file. This page explains where the file lives, how to open it, and the most common settings you'll touch.

The CLI merges two config.toml files:

1. Project-level: the closest .vibe/config.toml, found by walking up from the working directory, without going past your home directory.
2. User-level: ~/.vibe/config.toml.

Project settings override the same user settings, and anything the project file doesn't set comes from the user file. Project configuration is loaded only when its folder is trusted.

/config saves changes to the user file by default. Use Save to in the settings editor to save to the project file or to the current session only.

Open ~/.vibe/config.toml with your default editor:

# 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

You can also open the configuration menu from inside a session with the /config slash command.

By default, the CLI stores its configuration and state in ~/.vibe/. Override the location with the VIBE_HOME environment variable:

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

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

VIBE_HOME affects the location of:

• config.toml: main configuration.
• .env: API keys and provider credentials.
• agents/: custom agent profiles.
• prompts/: custom system prompts.
• skills/: custom skills.
• plugins/: user-level plugins.
• tools/: custom tools.
• logs/: session and application logs.

Use --workdir to point the CLI at a project that is not your current directory:

vibe --workdir /path/to/project

vibe --workdir /path/to/project

Use --add-dir to give the agent access to an extra directory for a single session. Repeat the flag for several directories. Vibe trusts each directory for the session, loads its AGENTS.md and .vibe/ configuration, and lets the agent read and edit files there without the outside-workdir prompt.

config.toml accepts many top-level keys and table sections. The most common ones are listed here, each one linking to a dedicated page.

Set the default agent:

default_agent = "ask"

default_agent = "ask"

This applies to both interactive and programmatic sessions. When unset, Vibe uses accept-edits. See Agents.

Define provider presets, model presets, and the active model. Vibe ships with one built-in model, Mistral Medium 3.5 (alias mistral-medium-3.5), and /model lists only the models configured for you. It groups them by where they come from: your organization's admin config, experiments, the model catalog, then your own configuration.

The following chat-capable models are available through Mistral's API (la Plateforme). Use the model ID as the name value in a [[models]] block with provider = "mistral", then select it with /model or active_model:

You can also pin to a specific version by replacing -latest with a date suffix (for example, mistral-medium-3-5 or codestral-2508). See the models overview for all available versions.

To use a model through a third-party provider such as OpenRouter, define a custom provider and model preset:

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"

See API keys and profiles.

Add Model Context Protocol servers under mcp_servers. See MCP servers.

Enable, disable, or add skill paths:

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 and disabled_skills interact as follows:

• If enabled_skills is set and non-empty, only skills whose name matches a pattern in that list are available.
• Otherwise, every discovered skill is available, minus any skill whose name matches a pattern in disabled_skills.

See Skills.

Restrict which tools the agent can use:

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

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

Tool filters support exact names, glob patterns, and regex with the re: prefix. Per-tool permissions can also be set in [tools.<tool_name>] blocks. See Safety, approvals, and permissions.

Run arbitrary shell commands before or after tool calls, or after each assistant turn, to gate, audit, or rewrite agent behavior. Declare hooks in a separate hooks.toml file. See Hooks.

Control update checks, notifications, and telemetry:

enable_update_checks = true
enable_notifications = true
enable_telemetry = true

enable_update_checks = true
enable_notifications = true
enable_telemetry = true

By default, Vibe validates HTTPS certificates against its bundled certificate roots. Since Vibe 3.0, it applies stricter validation rules, so a private certificate authority (CA) that lacks some standard extensions can be rejected. If your organization installs its CA in the operating system trust store, tell Vibe to use that store:

enable_system_trust_store = true

enable_system_trust_store = true

Vibe also loads the certificates in the SSL_CERT_FILE and SSL_CERT_DIR environment variables as additional trust anchors. To configure a proxy and certificates from inside a session, run /proxy-setup.

Your Organization or Workspace administrators can distribute a Vibe Code CLI configuration to all users. Admin-managed settings take precedence over command-line flags, environment variables, and the project and user config.toml files.

When admin config is active:

• Admin-managed settings are read-only in /config: you can't edit or reset them. The settings editor's Where it's set panel lists your administrator as a source.
• Sessions follow admin config from their first message. The CLI never writes it to your local config.toml.
• If admin config can't be applied, for example because it's invalid or doesn't fit your project, the session runs on your local configuration instead. The CLI shows: Your administrator-managed configuration could not be applied: <reason>.

When the same setting is defined in multiple places, the CLI applies them in this order, from highest to lowest priority:

1. Admin config, when your Organization or Workspace provides one. See Admin config.
2. The active agent's settings, from its agent file. See Agents.
3. Command-line flags (for example, --enabled-tools) and changes saved to the current session from /config.
4. VIBE_<KEY> environment variables, which override the config key of the same name (for example, VIBE_ACTIVE_MODEL).
5. Project .vibe/config.toml.
6. User ~/.vibe/config.toml.