Safety, approvals, and permissions

Vibe Code can read files, edit code, run shell commands, and call external tools on your behalf. To keep you in control of what runs and what changes, Vibe Code uses layered controls:

• Agents are configuration overrides: they bundle a system prompt, tool selection, and approval rules. They define what gets auto-approved.
• Trusted folders define whether Vibe can load project-level configuration, skills, and agent files from the current directory.
• Per-tool permissions let you tighten or loosen access for specific tools.

Vibe also asks for confirmation whenever a tool tries to read, write, or run a command outside the current working directory, regardless of the active agent.

This page explains how those controls work and how they interact.

The active agent defines how Vibe asks for approval before running tools, and more broadly, can override the system prompt, the compaction prompt, the model, the available tools, and other settings.

Use one of the built-in agents below. To switch, set a default, or create your own, see Agents in the CLI or the VS Code extension.

Many approval prompts are for actions you approve anyway. The smart-approve agent skips those prompts and still asks you before risky actions.

Select it with Shift+Tab, or start a session with it:

vibe --agent smart-approve
# or
vibe --smart-approve

vibe --agent smart-approve
# or
vibe --smart-approve

For each tool call that needs approval, Vibe goes through these steps in order:

1. Applies your permission rules first. Allowlisted commands run without a check, and denylisted commands stay blocked. See Per-tool permissions.
2. Reuses approvals you already gave for the same call in the current session.
3. Classifies the call. A model judges the call from your request and the tool arguments. Calls that it judges safe run immediately, with a note that explains why Vibe approved them.
4. Holds back risky calls. Vibe sends the reason back to the agent so that it can try a safer approach. Vibe asks you to confirm when the agent repeatedly makes risky calls, retries the same call, or when the classifier can't reach a verdict.

A call flagged as risky never runs without your confirmation. In programmatic mode, no one can confirm, so Vibe denies risky calls.

To start every interactive session with smart approve, set default_agent = "smart-approve" in config.toml.

Each classification is a separate model call, and it can use a different model from your session. Vibe picks the classifier model in this order:

1. The model you set with smart_approve in [utility_models].
2. Otherwise, a small, fast Mistral model, when your Mistral provider serves one.
3. Otherwise, your session's model, which can cost more per call.

Set smart_approve to the alias of one of your [[models]] presets, or to active to always use the session's model:

[utility_models]
smart_approve = "classifier"

[[models]]
name = "mistral-small-latest"
provider = "mistral"
alias = "classifier"

[utility_models]
smart_approve = "classifier"

[[models]]
name = "mistral-small-latest"
provider = "mistral"
alias = "classifier"

A smaller model adds less latency and cost to each tool call. A larger model can classify risk more accurately. If the alias doesn't match a configured model, or allowed_models excludes it, Vibe shows a warning and falls back to automatic selection.

For all the keys, see [utility_models] in the configuration reference.

A project can ship its own Vibe configuration (like agents, skills, MCP servers, and tool permissions) in a .vibe/ directory at the repository root. Because that configuration changes how Vibe behaves, Vibe will only load it from directories you have explicitly trusted.

Trustable content includes any of the following in the directory or its ancestors:

• A .vibe/ directory (configuration, agents, skills, prompts, hooks, and tools)
• An .agents/ directory (Agent Skills standard skills)
• An AGENTS.md file (project-level agent instructions)

How it works:

• When you start an interactive session in a directory that contains trustable content and trust state is unknown, Vibe asks whether to trust the directory.
• The trust dialog lists the trustable files it detected and flags any risks (such as MCP servers or tool permissions that grant broad access). It proposes the git repository root as the trust target when the directory is inside a git repo
• Trusted directories are remembered in ~/.vibe/trusted_folders.toml.
• If you decline or have not yet trusted a directory, project-level configuration is ignored and Vibe prints a warning. User-level configuration in ~/.vibe/ still applies.

The vibe --trust flag trusts the working directory for the current invocation only and does not persist.

Programmatic mode never prompts for trust. Use --trust to grant temporary trust when scripting Vibe.

# Trust the current project for one run, then exit
vibe --trust --prompt "Run the test suite and summarize failures"

# Trust the current project for one run, then exit
vibe --trust --prompt "Run the test suite and summarize failures"

Beyond agent modes, you can lock down or open up individual tools in config.toml. This applies to built-in tools (read_file, write_file, bash, grep, etc.) as well as MCP tools and connector tools.

Toggle tools globally using exact names, globs, or regex patterns:

# Only allow read-only and search tools
enabled_tools = ["read_file", "grep", "task"]

# Or disable a specific class of tools
disabled_tools = ["bash"]

# Only allow read-only and search tools
enabled_tools = ["read_file", "grep", "task"]

# Or disable a specific class of tools
disabled_tools = ["bash"]

Set when Vibe should ask before using a tool, or always allow it:

[tools.read_file]
permission = "always"

[tools.bash]
permission = "ask"

[tools.read_file]
permission = "always"

[tools.bash]
permission = "ask"

For the bash tool, you can also allow or block specific commands. Some safe commands (ls, pwd, cat, echo, etc.) are auto-allowed by default; add your own to extend the list:

[tools.bash]
permission = "ask"
allow = ["git status", "pnpm test"]
deny = ["rm -rf *"]

[tools.bash]
permission = "ask"
allow = ["git status", "pnpm test"]
deny = ["rm -rf *"]

MCP tools are addressed as {server_name}_{tool_name}. For example, to always allow a get tool exposed by an MCP server named fetch_server:

[tools.fetch_server_get]
permission = "always"

[tools.fetch_server_get]
permission = "always"

See MCP servers for the full configuration model and Configuration for the precedence between user and project settings.

The approval model is consistent across the CLI, the VS Code extension, and Vibe Code Web. How you act on approvals differs by surface:

• Start in plan for unfamiliar code. Explore and design before granting edit or shell access.
• Commit before risky runs. A clean baseline gives you an instant rollback (git reset --hard) when something goes wrong.
• Use accept-edits for scoped refactors and review the diff before committing.
• Use smart-approve to reduce approval prompts in day-to-day work. It still asks before risky actions, but it isn't a sandbox.
• Reserve auto-approve for disposable environments (containers, CI runners, ephemeral VMs). Never use it on machines that hold SSH keys, cloud credentials, or production access.
• Trust deliberately. Review a repo's .vibe/ configuration the first time, and again whenever it changes.
• Tighten MCP and connector tools. Anything touching external systems should be permission = "ask" even under accept-edits.
• Version-control your .vibe/ config so the team can review and reproduce the safety decisions.
• Revoke access you no longer need. Vibe Code Web GitHub connections, MCP credentials, and connector authorizations should be removed when a project ends.