Gemini CLI YOLO mode, read from the source: why settings.json can't turn it on

TL;DR

• Start YOLO with gemini --approval-mode=yolo, or press Ctrl+Y in a running session. --yolo / -y still work but are deprecated, and combining --yolo with --approval-mode is an error.
• You cannot make YOLO the default in settings.json. That's a deliberate design choice, and the code that enforces it is three lines long.
• YOLO only removes approval prompts. The sandbox (Seatbelt, Docker, Podman, gVisor, LXC) is a separate switch, and in the current source YOLO never turns it on.
• In an untrusted folder, any mode other than default gets forced back to default. If security.disableYoloMode or admin secure mode is set, asking for YOLO is a fatal config error, not a silent downgrade.

Everything below was checked against the Gemini CLI source (google-gemini/gemini-cli, 0.65.0-nightly.20261006) and its docs, on October 7–8, 2026.

Who is this even for in late 2026?

Short version: Gemini CLI users with a Gemini Code Assist Standard or Enterprise license.

Since June 18, 2026, Gemini CLI no longer serves Google AI Pro, Ultra or free Code Assist users. Google moved them to the Antigravity CLI (agy), which has a different YOLO story (it's agy --dangerously-skip-permissions, and there's no --yolo at all). Gemini CLI is still developed, though, and the approval code is worth reading on its own. It's one of the cleaner permission designs among coding agents.

What does Gemini CLI actually do with an approval mode?

There are four modes: default, auto_edit, plan and yolo. Here's how the CLI picks one at startup, in order:

1. --approval-mode <x> on the command line
2. else --yolo / -y, which maps to yolo
3. else general.defaultApprovalMode from settings, unless its value is yolo, in which case it's skipped
4. else default

Step 3 is the interesting one. The resolver doesn't reject a "yolo" value in settings. It just reads past it, as if the key weren't there. The settings schema says it outright: YOLO "can only be enabled via command line".

Two gates come after the mode is resolved:

• Kill switch. If security.disableYoloMode or admin.secureModeEnabled is set and the resolved mode is YOLO, startup throws a FatalConfigError. It doesn't quietly drop you to default. You asked for something that's banned, and the CLI tells you so.
• Folder trust. If the current folder isn't trusted, any mode other than default gets forced back to default, with a warning. This one applies to auto_edit and plan too, not just YOLO.

Why can't I just put "yolo" in settings.json?

The threat model is a cloned repo.

Gemini CLI merges settings from several layers, and one of them is the workspace's own .gemini/settings.json. If a project file could set defaultApprovalMode: "yolo", then git clone evil-repo && cd evil-repo && gemini would hand an attacker-controlled GEMINI.md an agent that never asks before running a shell command. Prompt injection plus auto-approval is the worst combination in agent security.

So the rule is: YOLO has to come from a human typing a flag (or a key) in this process. Settings can make you more cautious (disableYoloMode, secureModeEnabled, folder trust), but never less. If you want YOLO every time, the supported answer is a shell alias:

alias gemini-yolo='gemini --approval-mode=yolo --sandbox'

Compare that with Qwen Code, Gemini CLI's fork, which does allow tools.approvalMode: "yolo" in settings. It pushes the protection down to folder trust instead.

Does YOLO turn the sandbox on?

Not in the current code, whatever one older config page says.

Gemini CLI has two independent layers:

Layer	What it gates	Switch
Approval mode	Whether a human confirms each tool call	--approval-mode, Ctrl+Y, Shift+Tab
Sandbox	What a tool call can touch once it runs	--sandbox, GEMINI_SANDBOX, tools.sandbox

The sandbox resolver never reads the approval mode. With nothing set, it returns "no sandbox". Here's what you get when you turn it on:

• macOS, sandbox: true: sandbox-exec (Seatbelt) is picked first. The default profile is permissive-open. Despite the name, it starts from (deny default), allows file reads anywhere, and allows writes only to the project dir, temp, cache, ~/.npm, ~/.cache and any --include-directories. It also explicitly blocks the Docker socket and writes to ~/.gemini credential files (oauth_creds.json, mcp-oauth-tokens.json, …). Pick another built-in profile with SEATBELT_PROFILE: permissive-* and restrictive-* come in -open, -closed and -proxied network flavors, and strict-* in -open and -proxied. Anything not on that list is rejected, which also stops path traversal through the variable.
• Linux/other, sandbox: true: Docker, then Podman, whichever exists.
• Explicit only: runsc (gVisor, Linux only, run via Docker's --runtime=runsc), lxc (needs a container you already have running, so it's never auto-detected) and windows-native (Windows only).

A wrong value fails fast. GEMINI_SANDBOX=runsc on a Mac, or true with neither Docker nor Podman installed, is a fatal error, not a silent run without a sandbox.

The point: YOLO plus a sandbox is a reasonable setup. YOLO without one means "run anything with my user's full privileges". Pass --sandbox yourself.

How do Ctrl+Y and Shift+Tab interact?

• Ctrl+Y toggles between YOLO and default. This is the only in-session way into YOLO.
• Shift+Tab cycles default → auto_edit → plan (plan only if it's enabled). It never lands on YOLO. If you're in YOLO and press it, you drop to auto_edit.

Small design choice, sensible result: the key you hit all the time can't take you to the dangerous mode by accident.

One more thing: --yolo together with --approval-mode doesn't pick a winner. It's a validation error. Ambiguous intent fails at the door.

What happens in CI and headless runs?

This edge case trips people up. In non-interactive mode (gemini -p "…") there's nobody to answer a prompt, and the policy engine handles that by translating ask_user decisions into deny. So in headless default mode, a tool call that would have asked simply doesn't run.

Belt and braces: the CLI also removes ask_user, the tool the model uses to ask you a question, from the toolset in headless and ACP modes. The source comment says why: so that "it can never be allowed via a high-priority policy rule when no human is present". In ACP mode the IDE or client does the asking instead.

So headless, your options are:

• --approval-mode=yolo, ideally with --sandbox
• --approval-mode=auto_edit, plus policy rules that allow the shell commands you need
• or a policy file that says allow for exactly the tools the job uses

What are the halfway options?

• auto_edit approves file edits and still asks before shell commands.
• tools.allowed lists tool patterns that skip the prompt, such as run_shell_command(git).
• The policy engine is the recommended route: TOML files in ~/.gemini/policies/ with allow / deny / ask_user rules, which can be scoped to a mode (including YOLO). --allowed-tools on the command line is deprecated in its favour.

For the Gemini Code Assist extension in VS Code, set "geminicodeassist.agentYoloMode": true in user settings and reload the window. Note the familiar rule again: it only works in a trusted workspace. In IntelliJ, the matching option is Auto-approve changes.

How do I turn on YOLO per task or per workspace with AgentRQ?

Gemini CLI's switch is per process: you either started with --approval-mode=yolo or you didn't. AgentRQ moves that decision onto the task.

1. Connect Gemini CLI. It goes through the ACP Gateway. The Gemini CLI setup guide and the step-by-step post have the details:

npx @agentrq/acp-gateway@latest --agent gemini

Start it without --approval-mode=yolo. The gateway also moves each new session out of any mode that would approve on its own and into one where Gemini CLI asks a person.

2. Answer from anywhere. Each permission request shows up in the AgentRQ task, on the web, on your phone or in Slack, along with the command or edit it's asking about. You answer Allow Once, Always Allow (adds the tool to the workspace's auto-approved list) or Deny. If nobody answers within 30 minutes, the gateway cancels the turn instead of guessing. --permission-timeout changes that limit.

3a. YOLO for one task. Flip the YOLO toggle on a task, or when you create it. Every permission request in that task is approved automatically, while every other task in the workspace still asks. The flag lives on the task, so it persists across agent disconnects and reconnects. Scheduled tasks, event triggers and workflow steps have the same switch.

3b. YOLO for the whole workspace. Workspace settings has YOLO Mode (Execute All) (UI warning: "Agent will not ask for permission"). Under the hood it's a default, not a global override: the approval check reads the task's own YOLO flag, and the workspace switch decides what that flag starts as. New tasks you create in the web form open with the YOLO toggle already on (you can still switch it off per task), and tasks the agent creates for itself over the workspace MCP server inherit it. Flipping the switch doesn't rewrite tasks that already exist.

Or let a model approve and deny for you, from plain-English rules. Between "ask me every time" and "approve everything" there's a third option: an AgentRQ desktop extension that reviews each permission request before it reaches you. Extensions are trusted Node modules loaded by the AgentRQ desktop app. One registers a reviewer with ctx.hooks.add({ id, review(request) { ... } }) and is handed the pending call: the tool name, the argument preview the harness sent, and the workspace. It answers { behavior: 'deny', reason }, { behavior: 'allow' }, or nothing at all to abstain. Point review() at an external decision API such as TypeSafe's Jev, a "System One" model that returns a typed choice with calibrated probabilities and a confidence in milliseconds instead of generating text. Send the tool call as the state, and your workspace's rules in plain English ("git push is fine on feature branches, never on main", "never read anything under ~/.aws") as a Choice question over allow / deny / ask me. Then threshold it: approve only on a high-confidence allow, refuse on a confident deny, and abstain on everything else so the request lands on your phone as usual. The rules can live on a per-workspace settings tab the extension draws itself; the bundled guardrail example does exactly that with literal patterns.

The review contract is built on one asymmetry: refusing costs a tool call, approving costs whatever the tool call does. So one refusal settles a request; silence (an abstain, an exception, or a reviewer that misses its 5-second deadline) is never an allow, the request just stays in front of you; and an extension needs the decide consent level to approve, while deny consent can only refuse. The install screen starts every extension at none. Reviews only happen while the desktop app is open and signed in, so treat this as a fast first pass, not a security boundary.

The trade-off. Per-task YOLO is scoped trust: it ends when the job you vetted ends, and an unattended nightly job can run in YOLO while your interactive work stays supervised. Workspace-wide YOLO is easier, but it outlives any single decision you made, and every new task inherits it. The setup that holds up: leave the workspace switch off, use per-task YOLO, keep GEMINI_SANDBOX=true (or "tools": {"sandbox": true}) so the auto-approved commands still run in a container, start from a clean git tree, and read the tool call history afterwards. More on the per-task model: AgentRQ YOLO mode.

FAQ

Is gemini --yolo still a thing? It works, but it's deprecated. Use --approval-mode=yolo, and don't pass both.

Can I make YOLO the default in settings.json? No. The resolver skips "yolo" in defaultApprovalMode. Use a shell alias.

What does Ctrl+Y do? It toggles YOLO ↔ default in the running session.

Does YOLO enable the sandbox? Not in the current source. Add --sandbox or set GEMINI_SANDBOX.

Why does Gemini CLI refuse to start with --yolo? security.disableYoloMode or admin.secureModeEnabled is set. That's a fatal error by design. If it starts but drops you to default, the folder isn't trusted.

Why do my tool calls silently not run in gemini -p? Headless mode turns "ask" into "deny". Use YOLO (with a sandbox), auto_edit, or allow rules in a policy file.

For every other agent, see what YOLO mode is and how to turn it on in every coding agent.

---

Over to you: do you think "YOLO only from a flag, never from settings" is the right call, or should a tool trust your user-level config the way Qwen Code does? And if you run Gemini CLI in CI, which sandbox backend did you end up on? 👇

Originally published on AgentRQ.