Gemini CLI yolo mode: what it auto-approves, and how to make it less dangerous

The short answer

Yolo mode auto-approves all actions. The --yolo flag is deprecated; the current form is --approval-mode=yolo.¹ Under the hood, yolo adds a high-priority rule to Gemini CLI’s policy engine that allows all tools.² It’s reasonable inside a container with nothing valuable mounted. On your own machine, pair it with the sandbox, which on macOS confines writes to the project directory by default, and with deny rules at a higher priority than yolo’s.⁴ Teams can block it outright with security.disableYoloMode.³

One context note: Gemini CLI’s docs say it was replaced by Antigravity CLI for unpaid-tier and Google One users on 18 June 2026.⁴ The settings below are from Gemini CLI’s current docs; check your tool’s version if you’ve moved.

The four approval modes

--approval-mode takes default, auto_edit, yolo or plan.¹ The cheatsheet lists the values without describing each. An older Gemini CLI we had installed (0.6.1) describes three of them in gemini --help: “default (prompt for approval), auto_edit (auto-approve edit tools), yolo (auto-approve all tools)”; plan came later. The middle columns below follow those descriptions plus our reading of plan; check on your version:

The jump from auto_edit to yolo is the big one. File edits in a git repository are reversible. A shell command can delete outside the repository, push to remotes, call cloud CLIs and reach databases.

What yolo actually changes

Gemini CLI’s tool calls go through a policy engine. Each rule has a decision (allow, deny or ask_user) and a priority, and the highest-priority matching rule wins.² Yolo mode doesn’t switch the engine off. It adds “a high-priority rule” that allows all tools.²

That detail is what makes yolo tunable. The docs don’t state outright whether a deny rule still applies in yolo mode; they state the general rule that the highest-priority match wins.² So a deny placed at a higher priority than yolo’s allow should still win. Test that with a harmless command before relying on it.

The policy engine: rules that outrank yolo

Rules live in TOML files:²

Higher tiers override lower ones; within a file, priority runs from 0 to 999. Rules match on toolName, on commandPrefix (shorthand for the shell tool with a command that starts with a given string) or on argsPattern, a regex over the arguments as JSON.²

A sketch of a deny rule for destructive database commands, written to the documented fields (check the exact file format on the page before use):

Code A settings file: the rules a tool reads before it acts.

[[rule]]
toolName = "run_shell_command"
argsPattern = "(prisma migrate reset|dropdb|DROP TABLE|TRUNCATE)"
decision = "deny"
priority = 900

The docs also note an inconsistency in their own tier numbers (one table puts User at 4 and Admin at 5; examples use 3 and 4).² Put rules you need to hold in the admin tier, where they’re above everything else either way.

Regex rules match text. bash -c "$(echo ...)" and scripts that run SQL from files slip past them, as every text-matching guard does. Treat deny rules as a net for the common case, not a wall.

The sandbox: limits on what “yes” can do

Rules decide which commands run. The sandbox decides what a running command can touch, which is the protection that survives a command you didn’t anticipate. Turn it on with -s or --sandbox, the GEMINI_SANDBOX environment variable, or "sandbox": true in settings.json.⁴ On macOS the default Seatbelt profile confines writes to the project directory while allowing broad reads and network; stricter profiles restrict reads and route network through a proxy. Containers (Docker or Podman) are the cross-platform choice.⁴

For yolo, the sandbox is the difference between “the agent can change this repository without asking” and “the agent can change anything I can without asking.” Our Gemini CLI lost-files write-up is a case where a sandbox would have kept files in the project.

Turning yolo off for a team

Administrators can set:

Code Data in JSON, the format software uses to pass records and settings.

{
  "security": {
    "disableYoloMode": true
  }
}

The enterprise docs call this highly recommended in an enterprise environment to prevent unintended tool execution.³ Put it in the system overrides file (/etc/gemini-cli/settings.json on Linux, /Library/Application Support/GeminiCli/settings.json on macOS), which has the final say over user and workspace settings.³ The same page describes mcp.allowed, an allowlist of MCP server names; without it, any server a user defines is allowed.³

A safer yolo setup

If you want hands-off runs, here’s the order we’d build it in:

1. A container or sandbox profile with only the project mounted, and no cloud credentials or .env with live keys inside it.
2. Admin-tier deny rules for destructive commands you know about.
3. A before-tool hook as a second check. Gemini CLI hooks can allow or deny, with no ask.⁵ Our hooks post shows where it goes.
4. Checkpointing on, so file changes can be rolled back with /restore.
5. --approval-mode=yolo last, once the above are in place.

If you can’t do step 1, use auto_edit instead of yolo, so file edits flow and shell commands still ask. That keeps a person in the loop for the actions with the biggest blast radius.

To see which destructive commands an agent on your machine could run without a prompt, paste its config into the check page or run npx deedglass scan (how the grade works); to try rules on tool calls in your browser, open the playground.

Questions people ask

Is –yolo still supported in Gemini CLI?

It’s marked deprecated; the docs point to --approval-mode=yolo.¹

Does yolo mode turn on the sandbox?

The docs list sandboxing as a separate option (--sandbox, GEMINI_SANDBOX or settings).⁴ Turn it on yourself.

Can an admin stop users from using yolo?

Yes, with security.disableYoloMode: true in system settings.³

Written with AI assistance and checked against our claims register.