Blog
Yolo mode in every coding agent: what each skip-permissions flag really turns off
Every coding agent now has a way to stop asking. The flags look alike, and the question that matters is the one their names do not answer: does this remove a person, or a wall?
Every major coding agent has a yolo mode, and they split into two kinds. Most, including Claude Code, Gemini CLI, Cursor CLI, Copilot CLI and Qwen Code, remove only the approval prompts. Codex's --yolo and Antigravity's --dangerously-skip-permissions also remove the sandbox. Where a sandbox exists it is usually off by default, so a bare yolo session is often running with your full access either way. None of them keep a credential out of the process, which is what Forkbench's Vault adds.
The table
One row per agent, checked against each vendor's own documentation or source on 16 October 2026. Every agent with a flag of its own has a full breakdown, linked at the end of this page.
| Agent | Skip-everything flag | Also removes a sandbox? | Built-in sandbox | Gentler option |
|---|---|---|---|---|
| Claude Code | --dangerously-skip-permissions | No | Yes, opt-in | Auto mode, a reviewing model |
| Codex CLI | --yolo (--dangerously-bypass-approvals-and-sandbox) | Yes | Yes, on by default | --approve-for-me |
| Gemini CLI | --approval-mode=yolo (--yolo deprecated) | No | Yes, off by default | auto_edit |
| Antigravity CLI | --dangerously-skip-permissions | Yes | Yes, off by default on the CLI | proceed-in-sandbox |
| Cursor CLI | --force (alias --yolo) | No | Yes | Auto-Run in Sandbox |
| GitHub Copilot CLI | --allow-all (alias --yolo) | No | Yes since Oct 2026, off by default | --allow-tool patterns |
| OpenCode | --auto | No sandbox to remove | None | allow, ask and deny rules |
| Aider | --yes-always | No sandbox to remove | None | --no-suggest-shell-commands |
| Qwen Code | --yolo or --approval-mode yolo | No | Yes, off by default | auto, a classifier |
| Kiro CLI | --trust-all-tools (-a) | No | Yes since 2.31, off by default | --trust-tools with a list |
| Factory Droid | droid exec --skip-permissions-unsafe | No | Yes, off by default | --auto low, medium, high |
| Goose | GOOSE_MODE=auto, the default | No sandbox to remove | None | smart_approve |
| Crush | --yolo (-y, ctrl+y) | No sandbox to remove | None, a banned-command list | per-tool allow |
| Cline CLI | --yolo, auto-approve on by default | No | Sandbox mode, off by default | --auto-approve false |
| Kimi Code | --auto (Never Ask) | No sandbox to remove | None | --yolo, which still asks for risky actions |
| Amp | None needed, it does not ask by default | No sandbox to remove | None | ask and reject rules |
Removing a person versus removing a wall
An approval prompt and a sandbox do different jobs. The prompt puts a person in front of each action. The sandbox decides what an action can reach whether or not anyone is watching. Most yolo flags remove the first and leave the second alone.
Two do not. Codex's --yolo is named for both halves, approvals and sandbox, and does both. Antigravity's --dangerously-skip-permissions borrows Claude Code's spelling and, unlike Claude Code's, sets aside the terminal sandbox as well. Those are the two flags where the risk changes most between running with them and without.
Everywhere else, the honest description is the one from our Claude Code breakdown: the flag removes the human, not a boundary.
The defaults matter more than the flags
Read down the sandbox column and a pattern appears: where an agent has a sandbox, it is usually off until you turn it on. Gemini CLI, Antigravity CLI, Copilot CLI, Qwen Code, Kiro and Droid all ship one, and all of them start without it. Codex is the outlier, sandboxed out of the box.
So for most agents, the question of whether yolo disables the sandbox has a deflating answer: there was no sandbox running. A bare yolo session in those tools runs with your files, your network and your environment, exactly as a bare session with prompts did, minus the person.
Three agents start unprompted before you pass anything. Goose defaults to auto, Cline's CLI auto-approves by default, and Amp does not ask before running tools. For those, the advice is reversed: the useful flag is the one that turns review on.
What survives in every one of them
Deny rules are the most consistent protection across the whole table. OpenCode, Cursor, Copilot, Qwen, Kiro and Kimi all evaluate a deny before any blanket approval, so a short list of commands and files you never want touched holds under the yolo flag in each.
A few agents add guards that no flag reaches. Crush refuses curl, ssh, sudo and dozens more inside its bash tool. Droid's block rules have no approval path. Kimi Code keeps its file tools away from secret files in every mode, and OpenCode denies reading .env files by default.
What none of them do is keep a credential out of the agent's process. Every guard above decides which actions run. A key already in the environment is readable by any action that does run, and an ordinary request can carry it anywhere the network allows.
How this works in Forkbench
Forkbench is a desktop app for running coding agents, and it runs each of these as the binary you installed, with your flags and your config untouched. Claude Code, Codex, Cursor and Antigravity connect in one click; every other agent reaches the Thread's notes, board and keys through the fb command on its PATH.
It adds the same two things whichever agent you pick, because the gap is the same in all of them. A key in Vault is used by the command that needs it without the value entering the agent's environment, prompt or transcript, so no yolo flag has a token to spend. And a Thread can be locked to a set of folders by the kernel, inherited by every process the agent starts, which gives the agents with no sandbox, or a sandbox left off, a wall that is on by default.
The limit: a folder lock bounds files, not the network, and a command you authorise can still use a key against the destination it was bound to. That is containment and evidence, not isolation, and we say so on every page.
Related: Claude Code: what --dangerously-skip-permissions actually skips, Codex --yolo, Gemini CLI yolo mode, Antigravity CLI --dangerously-skip-permissions, Cursor CLI --force and --yolo, GitHub Copilot CLI --allow-all, OpenCode --auto, Aider --yes-always, Qwen Code yolo mode, Kiro CLI --trust-all-tools, Factory Droid --skip-permissions-unsafe, Goose auto mode, Crush --yolo, Cline CLI --yolo, Kimi Code --yolo and --auto
Frequently asked
Which coding agent's yolo mode is the most dangerous?
The ones that remove a sandbox as well as the prompts: Codex's --yolo and Antigravity's --dangerously-skip-permissions. In practice, an agent with no sandbox, or one left off, is just as exposed in yolo mode, because nothing was containing it before the flag either.
Does yolo mode disable the sandbox?
In Codex and Antigravity CLI, yes. In Claude Code, Gemini CLI, Cursor CLI, Copilot CLI, Qwen Code, Kiro, Droid and Cline, no: the sandbox is a separate setting, though it is usually off by default.
Do deny rules still work in yolo mode?
In most agents, yes. OpenCode, Cursor CLI, Copilot CLI, Qwen Code, Kiro CLI and Kimi Code all evaluate deny rules before a blanket approval, and Droid's block rules and Crush's banned commands cannot be approved by any flag.
Which coding agents run without asking by default?
Goose, whose default mode is auto; Cline's CLI, which auto-approves tool calls unless you pass --auto-approve false; and Amp, which does not ask before running tools unless you write rules that make it.
How do I run any coding agent in yolo mode without exposing my API keys?
Keep the key out of the agent's process. A broker that runs the command needing the key and returns only the result, as Forkbench's Vault does, means no yolo flag puts a token in reach. Approval prompts and deny lists decide which commands run; they do not decide what a running command can read.