Guides / Gemini CLI

Gemini CLI YOLO mode, approval modes and a safe settings.json

Gemini CLI reads .gemini/settings.json (project) and ~/.gemini/settings.json (user). Newer versions nest tool settings under tools.*; older ones use top-level keys. Both forms are counted here.

Data snapshot: 2026-10-20. Counts are unique public GitHub configs, identical files counted once. Aggregates only; no repos are named.

What the settings in .gemini/settings.json do

tools.core / coreTools: Allowlist of built-in tools. run_shell_command(git) restricts the shell to specific commands.
tools.exclude / excludeTools: Tools the model can never call, e.g. run_shell_command(rm). The closest thing to deny rules. Newer releases mark it deprecated in favor of the Policy Engine, but it is still what committed configs use.
tools.allowed: Tools that run without a confirmation prompt.
general.defaultApprovalMode: default prompts for each tool call, auto_edit auto-approves edit tools, plan is read-only. Current versions only allow YOLO (approve everything) from the command line: --approval-mode=yolo, or the deprecated --yolo flag. Older configs set yolo: true, autoAccept or approvalMode "yolo" in the file, and the index still counts those.

What public Gemini CLI configs look like

Unique public configs analyzed	1,377
Configs that set any permission keys	85 (small sample)
…with YOLO / auto-accept on	42.4%
…allowing the shell tool unrestricted	10.6%
…with any excluded tools	20%
All configs with a credential-looking literal	3.4%
Leaderboard	#2 of 4 on the safety leaderboard (score 93.4, small sample)

See the full dataset and leaderboard methodology. Public repos skew toward demos and templates, so treat these as a lower bound on what is possible, not a census.

Common risky patterns

YOLO / auto-accept committed to the repo
Older versions honored these keys from a committed settings.json, so everyone who cloned the repo ran with no prompts. Remove them and use --approval-mode=yolo only per session, inside a sandbox (--sandbox).
run_shell_command allowed without arguments
Allows any shell command. List specific commands like run_shell_command(npm test).
No tools.exclude
Exclude the destructive commands you never want run automatically.
API keys in mcpServers env
Use $VAR references so the key stays in your environment.

A safer starting config

{
  "tools": {
    "core": [
      "read_file",
      "glob",
      "search_file_content",
      "replace",
      "write_file",
      "run_shell_command(git status)",
      "run_shell_command(npm test)"
    ],
    "exclude": [
      "run_shell_command(rm)",
      "run_shell_command(git push)"
    ]
  },
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-github"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "$GITHUB_TOKEN"
      }
    }
  }
}

Adjust the allowed commands to your project. Rotate any key that was ever committed, even if you remove it later.

Grade your config

Paste your .gemini/settings.json into the grader for a score and fixes. Grading runs in your browser and the config is never stored. You get an A–F grade, the fixes, and a README badge.

Open the grader Grade from your agent (MCP)

Gemini CLI permissions FAQ

What is Gemini CLI YOLO mode?

An approval mode that auto-approves every tool call, including shell commands. Current versions only allow it from the command line with --approval-mode=yolo, or the deprecated --yolo flag.

Can I set YOLO mode in settings.json?

Not in current versions. general.defaultApprovalMode accepts default, auto_edit and plan. Older configs used yolo, autoAccept or approvalMode keys, and the index still counts those.

How common is YOLO mode in public Gemini configs?

42.4% of the 85 unique public configs that set any permission keys turn on YOLO or auto-accept. That's a small sample.