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 working directory and the directories added with --add-dir, unless every tool call is auto-approved (auto-approve agent or --auto-approve). To refuse these calls instead, see Access outside the working directory. It also asks before a tool reads or edits .env and .envrc files, even when the tool's permission is always. A path listed in the tool's allowlist skips both checks.

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

Smart approve is rolling out gradually. If it doesn't appear when you press Shift+Tab, start Vibe with one of the commands above or set default_agent = "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.

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 with a config.toml file or an agents/, skills/, prompts/, plugins/, or tools/ subdirectory
• An .agents/skills/ 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 that you haven't trusted, Vibe asks whether to trust it. If you choose Don't trust, Vibe asks again next time.
• The trust dialog lists the trustable files it detected. Choose Trust folder, Trust full repo (offered when you start Vibe in a subdirectory of a git repository), or Don't trust. The dialog doesn't analyze these files, so review them yourself.
• 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 "Summarize the project structure"

# Trust the current project for one run, then exit
vibe --trust --prompt "Summarize the project structure"

--worktree also trusts its worktree for the run. Vibe loads project configuration from directories added with --add-dir without asking for trust, so only add directories you trust.

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, edit, bash, etc.) as well as MCP tools and connector tools.

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

# Only allow reading files and loading skills
enabled_tools = ["read_file", "skill"]

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

# Only allow reading files and loading skills
enabled_tools = ["read_file", "skill"]

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

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

[tools.read_file]
permission = "always"

[tools.bash]
permission = "ask"

[tools.write_file]
permission = "never"

[tools.read_file]
permission = "always"

[tools.bash]
permission = "ask"

[tools.write_file]
permission = "never"

For the bash tool, you can also allow or block specific commands by prefix. Some read-only commands (ls, pwd, cat, git status, etc.) are auto-allowed by default. Set allowlist and denylist to choose the commands Vibe always runs or always blocks. Each setting replaces its default list, so include the defaults you want to keep:

[tools.bash]
permission = "ask"
allowlist = ["git status", "pnpm test"]
denylist = ["rm -rf"]

[tools.bash]
permission = "ask"
allowlist = ["git status", "pnpm test"]
denylist = ["rm -rf"]

By default, Vibe asks before a file or shell tool reaches a path outside the working directory, even through a symbolic link. Set outside_workdir = "deny" to refuse these calls instead: the agent gets an error and keeps working. Set it for every tool, or per tool:

outside_workdir = "deny"

[tools.read_file]
outside_workdir = "ask"

outside_workdir = "deny"

[tools.read_file]
outside_workdir = "ask"

Paths in a tool's allowlist and directories added with --add-dir stay allowed. Shell tools only check paths written in the command, not paths a script builds, so keep a shell tool that must stay inside the working directory on ask.

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 ask or a plan agent for unfamiliar code. Review each action, or agree on a plan, before granting broader 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.