# Approval modes, the sandbox and checkpoints

Course: Gemini CLI from Zero — https://zero2vibecode.com/learn/gemini-cli
Canonical URL: https://zero2vibecode.com/learn/gemini-cli/0-4-approval-modes-and-sandbox
Verified against: Gemini CLI v0.65.0 (2026-10-22)
Last updated: 2026-10-22

The approval mode decides which actions Gemini CLI takes without asking, from plan (read-only) to YOLO (everything). The sandbox is a separate switch, set when it starts, and it is off unless you turn it on or start in YOLO. Checkpoints and a commit before each task are what make a wrong edit cheap to undo.

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.
- `/plan` switches to plan mode and shows the current plan.

Or set the mode when you start:

```bash
gemini --approval-mode=plan
```

The older `--yolo` flag still exists but is deprecated in favour of `--approval-mode=yolo`.

## 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:

```bash
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, commit 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.