Mistral Vibe Auto-Approve: Automate the Keystrokes, Keep Approval on the Record
What auto-approve actually does in Mistral Vibe, how to turn it on (agents, Shift+Tab, --auto-approve and --yolo), what still asks, and the sane setup — plus the half nobody configures: where the run's decisions get recorded.

"Auto approve" in Mistral Vibe is not one switch. It is a dial with four positions, a flag for unattended runs, and a set of exceptions that keep asking even when you think you have turned the questions off. This guide walks the whole mechanism — what each setting actually approves, how to turn it on, where the boundaries stay — and then covers the half that the settings page cannot: once the agent runs free, where do its decisions get recorded?
The four positions of the dial
In Vibe, the active agent defines what gets auto-approved. Agents are configuration overrides — they can bundle a system prompt, a tool selection and the approval rules — and four are built in:
| Agent | What it auto-approves | What still asks |
|---|---|---|
ask | Nothing | Every tool call |
accept-edits (default) | File edits | Shell commands and other sensitive tools |
smart-approve | Tool calls a classifier model judges safe | Calls judged risky — a risky call never runs without your confirmation |
auto-approve | Every tool execution, including shell commands | Nothing at the tool layer (exceptions below still apply) |
Two notes worth knowing before you reach for the extremes. smart-approve is rolling out gradually, and Mistral's documentation is blunt about what it is: a classifier, not a sandbox — a call it judges safe runs with the full access of your own account. And auto-approve carries the vendor's own warning label: trusted, sandboxed environments only.
How to turn it on
In an interactive session, cycle agents with Shift+Tab — the mode label on the input box shows which agent is active — or start in the mode you want:
vibe --agent auto-approve
To make a mode your default, set default_agent in your Vibe configuration. You can also approve case-by-case from the prompt itself: 1/y allows once, 2 for the rest of the session, 3 always, 4/n denies.
In programmatic mode (vibe --prompt …) the rules change, because nobody is there to answer. Vibe uses your default agent, and any tool call that needs approval is simply denied. To approve every call in an unattended run:
vibe --prompt "…" --auto-approve
--yolo is an alias for the same flag. Two limits: Mistral's docs attach the same condition to it — sandboxed environments only — and if your administrator has set enable_auto_approve = false, Vibe ignores both flags entirely.
What still asks (and what stays blocked)
Auto-approve is broad, but it is not the only layer. These controls sit alongside the agent modes:
- Outside the working directory. A tool reaching outside the working directory (or directories added with
--add-dir) triggers a confirmation unless every call is auto-approved. Settingoutside_workdir = "deny"refuses such calls outright instead of asking. .envfiles. Vibe asks before a tool reads or edits.envand.envrcfiles even when that tool's permission is set toalways. A path placed in the tool'sallowlistis the documented exception that skips these checks — which makes the allowlist itself a security decision, not a convenience.- Per-tool permissions. In
config.tomleach tool — built-in, MCP or connector — can be set to ask, always allow, or never allow. Thebashtool additionally takes command-prefix allowlists and denylists. - Your permission rules run first. Whatever the agent mode, allowlisted commands run and denylisted commands stay blocked.
A sane setup
Mistral's own guidance, plus the obvious conclusion from the mechanism:
- Daily work: stay on
accept-edits, orsmart-approveif it has reached you. Keep MCP and connector tools — anything that touches external systems — atpermission = "ask"even here. - Unfamiliar code: drop to
ask, and commit before risky runs, sogit reset --hardis your rollback. auto-approve: reserve it for disposable environments — containers, CI runners, ephemeral VMs. Never on a machine holding SSH keys, cloud credentials or production access. That sentence is Mistral's, not ours.- Version-control your
.vibe/configuration, so the team's safety decisions are reviewed and reproducible like code.
The other half: you approved the execution — where is the record?
Approval in Vibe governs the moment a tool runs. It is, by design, ephemeral: session approvals reset, classifications leave a note, and when the terminal closes, what remains is the code diff. But a long auto-approved run produces more than code. It produces decisions — why this migration shape, which workaround was accepted, what the agent concluded about your system — and in most setups those evaporate with the session. The next run, or the next teammate, starts from the code and guesses the reasoning again.
That is the same distinction our knowledge base for Mistral Vibe is built around: trusting a folder is not approving its output. Run Vibe as free as the environment safely allows — and give what it produces a place where facts land as records, where the consequential ones wait as change requests with a diff for a person to accept, and where the rules the agent should follow next time live as skills it reads before acting. Vibe connects to that layer over MCP (see the setup guide). Automate the keystrokes. Keep approval on the record.
FAQ
Is --yolo different from --auto-approve? No. Mistral's documentation lists --yolo as an alias of --auto-approve for programmatic mode. Both approve every tool call; both are ignored when an administrator disables auto-approve.
Does auto-approve make Vibe safe to run unattended on my work machine? No — and the docs say so. Auto-approve removes the prompts, not the risk: calls run with your account's full access. Unattended runs belong in sandboxed, disposable environments, with per-tool denylists for anything destructive.
If I use smart-approve, do I still need per-tool permissions? Yes. Smart approve classifies calls one by one; per-tool permissions are standing policy that applies before classification. The two layers compose — policy first, judgment second — and for external-facing tools, permission = "ask" remains the right standing policy.