Gemini CLI reads files, edits them and runs shell commands on your machine. How much of that happens without asking you is a setting, and so is where those commands are allowed to reach. They are separate settings, and mixing them up is the usual mistake.
Approval modes
The approval mode decides which actions need your yes. There are four:
| Mode | What it does |
|---|---|
default | The standard mode: most tools that write ask for confirmation first |
auto_edit | Edits are approved automatically |
plan | Strict and read-only: research and design, no changes |
yolo | Every tool call is approved automatically. The docs say to use it with extreme caution |
You switch between them while you work:
- Shift+Tab cycles default, auto_edit and plan. Plan is skipped while the agent is busy.
- Ctrl+Y toggles YOLO on and off.
/planswitches to plan mode and shows the current plan.
Or set the mode when you start:
gemini --approval-mode=plan
The older --yolo flag still exists but is deprecated in favour of --approval-mode=yolo.
Quick check
You want to understand an unfamiliar codebase before touching anything. Which mode fits?
The sandbox is a separate switch
The approval mode decides whether Gemini CLI asks. The sandbox decides what a command can reach once it runs. It isolates shell commands and file changes from the rest of your system, and it is off by default.
Turn it on for a session with the flag:
gemini --sandbox
or permanently with the GEMINI_SANDBOX environment variable or "sandbox" under tools in settings.json. How it isolates depends on your platform: on macOS the lightweight option is the built-in Seatbelt (sandbox-exec), whose default profile restricts writes and still allows the network; with Docker or Podman, the commands run inside a container instead.
The configuration reference adds one more trigger: starting with --yolo or --approval-mode=yolo enables the sandbox by default. Whether commands run sandboxed is settled when Gemini CLI starts, so pressing Ctrl+Y in a session that started without a sandbox changes the approval mode and nothing else.
That is why YOLO without a sandbox is the combination to avoid. Every command is approved, and nothing limits what those commands can touch.
Undo: checkpoints and commits
Checkpointing saves a snapshot of your project before a tool modifies files. The snapshot lives in a separate shadow Git repository in your home folder, so it does not touch your project’s own history, and /restore brings the files back to that point. It is off by default; the checkpointing page shows the setting that turns it on.
Whether or not you enable it, before a task. A commit is a checkpoint you control, and it marks exactly where the agent’s work starts — which matters most in auto_edit, where the edits land without a prompt each.
Trusted folders
Gemini CLI can also ask, the first time you run it in a folder, whether you trust that folder. An untrusted folder runs in a restricted safe mode: the project’s own settings and .env files are ignored, MCP servers do not connect, and tool auto-approval is turned off, so you are asked before every tool runs. The trusted-folders page describes the feature as off by default and shows the setting that enables it; /permissions trust manages it from inside a session.
It is worth turning on if you open repositories you did not write. A project’s settings file can auto-approve tools or switch the sandbox off, and the trust dialog lists those before you agree.
On Antigravity CLI
Antigravity CLI has its own approval and sandbox settings, and Google’s migration guide does not map them one to one. The ideas carry over — ask before writing, isolate what runs, commit first — but check its documentation for the actual names and keys.
Try it yourself
Eight approvals in, the temptation is to make the questions stop.
What is the safest way to let Gemini CLI work through a long, repetitive change?
Commit first, switch to auto_edit with Shift+Tab rather than YOLO, and review the whole diff with git diff when it is done. Edits go through without a prompt each, but shell commands are not blanket-approved the way they are in YOLO.
Does the sandbox protect my project files?
It limits what commands can reach outside the project. It does not judge whether an edit inside the project is correct; that is what your review and a commit before the task are for.