Gemini CLI's resolver reads past a yolo default in settings.json

The enforcement sits at step 3 of the startup resolver, and it fails quietly. ^[10] The resolver does not reject a "yolo" value in settings. According to the dev.to post, it reads past the value as if the key were not there. ^[11] The settings schema says YOLO "can only be enabled via command line". ^[23] A user who writes the setting and passes no flag falls through to default, with prompts on. ^[10] The post says the code behind this is three lines long. ^[2]

The kill switch behaves the other way. If security.disableYoloMode or admin secure mode is set and the resolved mode is YOLO, startup throws a FatalConfigError instead of downgrading. ^[5] In our view the split is sensible. Ignoring a setting is a safe failure. Refusing an explicit flag with an error tells the person who typed it. The folder-trust rule is wider than YOLO: it covers three of the four modes. ^[24]

The reason is the workspace file. Gemini CLI merges settings from several layers, and one of them is the project's own .gemini/settings.json. ^[12] If that file could set defaultApprovalMode to yolo, the post says, "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." ^[13] So settings can make the CLI more cautious but never less. ^[14] We think that is the right tradeoff for a tool that routinely runs in directories its user did not write. The post calls it one of the cleaner permission designs among coding agents. ^[25] Qwen Code, a fork, does allow tools.approvalMode: "yolo" in settings and leans on folder trust instead. ^[15]

YOLO removes prompts and nothing else. ^[3] The sandbox resolver never reads the approval mode, and with nothing set it returns no sandbox. ^[16] The alias the post offers as the supported answer therefore names both switches: gemini --approval-mode=yolo --sandbox. ^[21]

On macOS, sandbox: true picks Seatbelt first and defaults to the permissive-open profile. That profile starts from (deny default), allows file reads anywhere, and limits writes to the project directory, temp, cache, ~/.npm, ~/.cache and any --include-directories. ^[17] It also blocks the Docker socket and writes to the ~/.gemini credential files. ^[18] Gemini CLI's own gVisor, LXC and windows-native backends are explicit-only. ^[20]

The post read one nightly build, 0.65.0-nightly.20261006, on October 7 and 8, 2026. ^[6] Gemini CLI stopped serving Google AI Pro, Ultra and free Code Assist users on June 18, 2026, and Google moved them to the Antigravity CLI. ^[7] There the flag is agy --dangerously-skip-permissions, and there is no --yolo. ^[8] The post's short version of who remains on Gemini CLI is holders of a Gemini Code Assist Standard or Enterprise license. ^[22]