How do I enable yolo mode in Gemini CLI?

Start it with --approval-mode=yolo. The older --yolo and -y flags still work but are deprecated, and you cannot combine them with --approval-mode. Yolo cannot be saved as the default in settings.json; Gemini rejects it there on purpose, so it is chosen per session.

Does Gemini CLI yolo mode disable the sandbox?

No. Approval mode and sandboxing are independent in Gemini CLI. The sandbox is simply off by default, so unless you started with -s, --sandbox or GEMINI_SANDBOX set, a yolo session runs commands directly on your machine with your user's access.

What is auto_edit mode in Gemini CLI?

The middle setting. auto_edit approves file edits automatically and still asks before running shell commands, which removes most of the prompts on a coding task while keeping a human in front of anything that executes.

Why does Gemini CLI ignore my --yolo flag?

Usually because the folder is not trusted, in which case Gemini resets the approval mode to default. On a managed install, an administrator may also have set security.disableYoloMode, which makes the flag do nothing.

Is it safe to run Gemini CLI in yolo mode with API keys in my environment?

Not on a default install. Without the sandbox, every command Gemini approves on its own runs with your environment, and with the macOS permissive-open profile it can still read widely and reach the network. Keep keys out of the environment entirely, for example by brokering them through [Forkbench's Vault](/security#the-vault), so there is nothing for an approved command to send.

Blog

Gemini CLI yolo mode: --yolo, --approval-mode and the sandbox that was never on

Gemini CLI's yolo mode does less than people fear and more than they think. It only removes approvals, but on a default install the approvals were the only thing there.

16 October 2026

Quick Answer

In Gemini CLI, --approval-mode=yolo (or the deprecated --yolo and -y) auto-approves every tool call, including shell commands. It does not touch the sandbox, because the sandbox is a separate switch, and on a default install that switch is off, so a bare yolo session has no operating-system isolation at all. Turn the sandbox on with -s or GEMINI_SANDBOX before you turn approvals off. Forkbench adds the part neither covers: a key used through Vault is never in Gemini's environment.

What --yolo changes

Gemini CLI has four approval modes, set with --approval-mode: default asks before tools act, auto_edit approves file edits and still asks before shell commands, plan is read-only, and yolo approves everything.

--yolo and its short form -y still work, but Google's CLI reference marks them deprecated in favour of --approval-mode=yolo. Passing both is a hard error rather than a silent pick, which saves you guessing which one won.

Note what is not on that list. Approval mode is about whether you are asked. It says nothing about what a command can reach once it runs.

The sandbox is a separate switch, and it starts off

A common claim online is that --yolo also disables Gemini's sandbox. It does not. In the source, approval mode and sandboxing are independent settings, and neither one reads the other.

The catch is the default. Gemini CLI's sandbox is off unless you enable it with -s, --sandbox or the GEMINI_SANDBOX environment variable, which takes docker, podman, sandbox-exec and a few others. So the question is not whether yolo disables the sandbox. On most machines there was never one running.

When you do enable it on macOS without Docker, Gemini uses Seatbelt with a profile called permissive-open. It confines writes to the project folder and still allows broad reads and outbound network. That is useful, and it is worth knowing it is a write fence, not a read fence.

Three things that quietly override yolo

Gemini is more defensive about yolo than most CLIs, and these surprise people who expect the flag to be the last word.

It cannot be saved. general.defaultApprovalMode in settings.json accepts default, auto_edit and plan, and rejects yolo on purpose, so it has to be asked for each session.
Untrusted folders reset it. If the folder is not trusted, Gemini forces approval mode back to default regardless of what you passed.
Admins can lock it out. security.disableYoloMode turns the flag into a no-op for a managed install, and tools.confirmationRequired always beats an allow entry.

Where Gemini CLI stands now

Google retired the standalone Gemini CLI for its AI Pro, Ultra and free tiers in June 2026 and pointed those users to Antigravity CLI, invoked as agy. Gemini CLI still runs on paid Gemini API and Enterprise keys, and the repository is still shipping, so these flags still matter to anyone on that path.

If you are moving across, Antigravity's equivalent is spelled --dangerously-skip-permissions, the same as Claude Code's, and it behaves differently from both. The Antigravity post covers it.

How this works in Forkbench

Forkbench is a desktop app for running coding agents. It launches the gemini binary in a real login shell with your settings.json intact, and it does not wrap or proxy it, so your approval mode and sandbox choice behave exactly as they do anywhere else.

What it adds is aimed at the gap in the section above: with the sandbox off by default, reads are unbounded. A Thread can be locked to a set of folders at the kernel level, inherited by every process Gemini starts, so a yolo session cannot wander into the rest of your home folder. And a key in Vault is used by the command that needs it without the value reaching Gemini's environment or its context window, which matters more here than for most agents, because permissive-open lets anything it reads go out over the network.

The limit: none of this inspects what an approved command does with what it was given. It narrows what is in reach, and that is the honest claim.

Frequently asked

How do I enable yolo mode in Gemini CLI?
Start it with --approval-mode=yolo. The older --yolo and -y flags still work but are deprecated, and you cannot combine them with --approval-mode. Yolo cannot be saved as the default in settings.json; Gemini rejects it there on purpose, so it is chosen per session.
Does Gemini CLI yolo mode disable the sandbox?
No. Approval mode and sandboxing are independent in Gemini CLI. The sandbox is simply off by default, so unless you started with -s, --sandbox or GEMINI_SANDBOX set, a yolo session runs commands directly on your machine with your user's access.
What is auto_edit mode in Gemini CLI?
The middle setting. auto_edit approves file edits automatically and still asks before running shell commands, which removes most of the prompts on a coding task while keeping a human in front of anything that executes.
Why does Gemini CLI ignore my --yolo flag?
Usually because the folder is not trusted, in which case Gemini resets the approval mode to default. On a managed install, an administrator may also have set security.disableYoloMode, which makes the flag do nothing.
Is it safe to run Gemini CLI in yolo mode with API keys in my environment?
Not on a default install. Without the sandbox, every command Gemini approves on its own runs with your environment, and with the macOS permissive-open profile it can still read widely and reach the network. Keep keys out of the environment entirely, for example by brokering them through Forkbench's Vault, so there is nothing for an approved command to send.