The config.toml File — Mistral Vibe: AI Coding CLI

Lesson updated November 2, 2026 based on Vibe Code documentation: integrated model Mistral Medium 3.5 (plus Devstral 2), enable_update_checks (the enable_auto_update key no longer has an effect), edit tool (formerly search_replace), and the removed [safety] section replaced by default_agent. Sources: Configuration · Configuration reference.

Where is config.toml located?

Vibe looks for its configuration file in two places, in this order:

Project configuration: ./.vibe/config.toml (in the current directory)
Global configuration: ~/.vibe/config.toml (in your home directory)

Project configuration takes precedence over global configuration. This mechanism makes the tool practical for a developer’s daily workflow: your global configuration reflects your habits, while a client’s repository enforces its own rules within its directory without requiring you to manually switch settings.

File structure

The config.toml file uses the TOML format, a readable and unambiguous configuration format. Here is a complete commented example containing everything you will need:

# ~/.vibe/config.toml

# Active model: the built-in model, or an alias for a [[models]] preset
active_model = "mistral-medium-3.5"

# Default agent (accept-edits if the key is missing)
default_agent = "ask"

# Custom system prompt (~/.vibe/prompts/my_custom_prompt.md)
system_prompt_id = "my_custom_prompt"

# Theme: auto follows the terminal; use /theme to choose
theme = "auto"

# Daily check for new versions
enable_update_checks = true

Choosing the model

The active_model parameter determines which model Vibe uses for generation. It expects an alias: either the built-in model, Mistral Medium 3.5, or an alias for a [[models]] preset you have declared (covered in the next lesson).

active_model = "mistral-medium-3.5"

You do not have to edit the file to change models: the /model command switches models mid-session and displays the list of available options. Use the file to set your default choice, and the command for one-off tests.

Customizing the system prompt

The system prompt defines Vibe’s behavior. By default, it is configured to be an effective coding assistant, but you can specialize it. This is often the setting that yields the most visible gain: an agent that knows your conventions in advance stops proposing code that needs reformatting.

Prompts are Markdown files stored in ~/.vibe/prompts/. Create your own; here is an example for a team working with Python and FastAPI:

mkdir -p ~/.vibe/prompts
cat > ~/.vibe/prompts/mon_prompt.md << 'EOF'
Tu es un assistant de développement spécialisé en Python et FastAPI.
Tu écris du code propre, typé, avec des docstrings.
Tu privilégies les approches fonctionnelles quand c'est possible.
Tu réponds toujours en français.
EOF

Then reference it in config.toml using the filename without its extension:

system_prompt_id = "mon_prompt"

Configuring agents

Agents go further than prompts alone: they are complete configuration profiles where each agent has its own model, system prompt, and tool permissions. You create them in ~/.vibe/agents/. The clearest example is a code review agent:

# ~/.vibe/agents/code_review.toml

system_prompt_id = "code_reviewer"
disabled_tools = ["write_file", "edit", "bash"]

[tools.bash]
permission = "never"

Launch it on demand:

vibe --agent code_review

This agent can only read: it cannot write files or execute commands. You can therefore let it scan a colleague’s branch without fearing accidental modifications, making it the ideal mode for safe code reviews.

Tool control

This tool filtering also applies to the main configuration. Two lists are available: one to allow only specific tools, and another to forbid them:

# Enable only specific tools
enabled_tools = ["read_file", "grep", "edit"]   # edit: formerly search_replace

# Disable specific tools
disabled_tools = ["bash", "write_file"]

Typing every name by hand becomes tedious when an MCP server exposes twenty tools. MCP tools are named {server}_{tool}, and filters accept wildcards and regular expressions (prefix re:). This lets you reason by family rather than by individual tool:

# Enable all tools from an MCP server named serena (glob pattern)
enabled_tools = ["serena_*"]
# ... or the same thing with a regular expression:
# enabled_tools = ["re:^serena_.*$"]

# Disable all tools from the fetch_server MCP server
disabled_tools = ["fetch_server_*"]

Theme and configuration location

Set the theme in the same file, or on the fly via the /theme command:

theme = "auto"

Available themes vary by version; use /theme in interactive mode to see the full list and preview each option before locking in your choice.

Finally, Vibe stores its configuration in ~/.vibe/ by default, but you can change this location via an environment variable:

export VIBE_HOME="/chemin/vers/mon/dossier/vibe"

This is useful if your home directory is on a slow network drive where every configuration read would incur latency, or if you share a configuration across multiple machines via a synchronization service.

Project-specific configuration

Returning to the opening scenario: for project-specific settings, create .vibe/config.toml at the project root:

mkdir -p .vibe
cat > .vibe/config.toml << 'EOF'
system_prompt_id = "python_expert"

[tools.bash]
permission = "ask"
allowlist = ["git status", "git diff", "pytest"]
EOF

Vibe loads this file only if you declared the folder trusted on first launch. As a precaution before committing: add .vibe/ to your .gitignore if the file contains sensitive information, such as variable names or internal URLs you do not want pushed to the repository.

Key takeaways

config.toml exists in global (~/.vibe/) and project (./.vibe/) versions
Project configuration takes precedence over global configuration
Agents are complete profiles with model, prompt, and permissions; set the default agent with default_agent
Tools can be filtered using wildcards or regex
The VIBE_HOME variable lets you change the configuration directory