DEV Community: Tony

Copilot YOLO mode, dissected: what --yolo, /yolo and Allow all actually skip

Tony — Mon, 12 Oct 2026 18:02:40 +0000

TL;DR

Copilot CLI: copilot --yolo (same flag as --allow-all), or /yolo in a running session. It is shorthand for --allow-all-tools + --allow-all-paths + --allow-all-urls.
VS Code: pick Allow all in the chat permission picker, type /yolo, or set "chat.tools.global.autoApprove": true to make it permanent.
What it skips: approval prompts. What it doesn't: your --deny-tool rules, and (in VS Code, explicitly documented) an enabled sandbox.
Autopilot is a different switch. It keeps the agent iterating; YOLO approves its tool calls. Unattended runs usually want both.

Everything here was checked on October 7, 2026 against GitHub's Copilot CLI reference, the github/copilot-cli changelog (1.0.93) and VS Code's agent docs in microsoft/vscode-docs.

Why does "YOLO" mean two different things in Copilot?

Because Copilot ships two agent runtimes with two permission systems. The Copilot CLI is a terminal agent with flag-driven permissions. Copilot Chat in VS Code is an editor agent whose permissions hang off a picker and settings.json. They share vocabulary (/yolo exists in both) but not config. Nothing you set in VS Code changes the CLI, and vice versa.

The one thing they agree on is the layering. There are three separate gates between the model and your machine:

model wants to act
   │
   ▼
[1] deny rules ─────────── always win, YOLO or not
   │
   ▼
[2] approval prompt ────── this is the only layer YOLO removes
   │
   ▼
[3] sandbox (if enabled) ─ still limits files + network
   │
   ▼
your shell / filesystem / network

Keep that picture in mind; every flag below is about layer 2.

What exactly does copilot --yolo turn on?

copilot --yolo

--yolo and --allow-all are the same flag, documented as "Enable all permissions (tools, paths, and URLs)". It decomposes into three narrower switches you can use on their own:

Flag	What stops asking
`--allow-all-tools`	every tool call (GitHub notes this is required when you drive the CLI from a script)
`--allow-all-paths`	the check on which file paths the agent may touch
`--allow-all-urls`	URL fetch approval

The env var COPILOT_ALLOW_ALL=true does the same as --yolo and trusts the current directory, which makes it the CI-friendly form: no flag plumbing through wrapper scripts.

The nerdy bit worth noticing: paths and URLs are separate trust dimensions from tools. If your threat model is "the agent may run npm test but must not read ~/.ssh or exfiltrate to random hosts", --allow-all-tools alone is a materially different posture from --yolo.

How do the in-session commands map onto each other?

/permissions is now the canonical command, with four arguments: default, assisted, allow-all and show. Everything else is an alias:

/yolo and /allow-all → /permissions allow-all
/yolo also takes off, auto and show
/reset-allowed-tools (or /permissions default) undoes it

While it's on, the footer shows a YOLO indicator, so you can't forget you're flying without a net.

One gotcha for people coming from other agents: Shift+Tab does not toggle YOLO in the Copilot CLI. It cycles standard → plan → autopilot. That's a mode-of-work switch, not a permission switch.

Why isn't Autopilot the same thing as YOLO?

Two orthogonal axes:

Autopilot (--autopilot, /autopilot, or Shift+Tab) answers "should the agent keep going without checking in with me?"
YOLO answers "should the agent run tools without asking me?"

Autopilot without YOLO: the agent keeps working, then blocks on the first approval. YOLO without Autopilot: approvals fly through, but the agent stops to check in. An unattended run usually needs both. VS Code's security docs make the same point from the other side: Autopilot "combines auto-approval with autonomous iteration" and "reduces your ability to review intermediate steps".

Can I get most of the speed without approving everything?

Yes, and this is where Copilot's design is genuinely nice. Two halfway layers:

Pattern rules. --allow-tool and --deny-tool take typed patterns:

copilot --allow-tool 'shell(git:*)' --deny-tool 'shell(git push)'

Other shapes: write(src/*.ts), read(.env), url(github.com), MyMCP(create_issue). The rule that matters: a deny always wins, including over --yolo. That gives you a cheap "YOLO minus the footguns" profile: --yolo --deny-tool 'shell(git push)'.

Assisted permissions. /permissions assisted puts a safety model in front of the prompt. It approves routine requests and only escalates the rest to you. It's a classifier in layer 2, not a sandbox, so it reduces prompts without adding isolation.

Admins get the last word: "disableBypassPermissionsMode": "disable" under permissions kills all of this, and "allow-auto-only" restricts users to the assisted mode.

How does VS Code's version work?

Copilot Chat calls it Allow all, one of three permission levels:

Level	Behavior
Manual (default)	asks for each tool call
Assisted	a model approves routine requests (needs `chat.assistedPermissions.enabled`)
Allow all	asks for nothing; VS Code warns you the first time

Three ways in:

The permission picker in the chat input.
/yolo or /autoApprove in chat, for the current session. Undo with /disableYolo or /disableAutoApprove.
Permanently, in settings.json:

{ "chat.tools.global.autoApprove": true }

That last one approves every tool in every workspace, and VS Code's own docs flag it as a setting that "disables critical security protections". The docs recommend the session-scoped Allow all when you don't need auto-approval everywhere. The experimental chat.permissions.default (default, autoApprove, autopilot) picks the level new chats start with, and orgs can block global auto-approve with the ChatToolsAutoApprove policy.

Are terminal allowlists enough to keep me safe?

They're the VS Code halfway option:

{
  "chat.tools.terminal.autoApprove": {
    "mkdir": true,
    "/^git (status|diff|log)\\b/": true,
    "rm": false
  }
}

Keys are prefixes or regexes. true auto-approves; false forces a prompt even if another rule would approve. Note that false means ask, not block.

But read the fine print: VS Code's security docs say auto-approval rules "use best-effort command parsing and have known limitations with shell aliases, quote concatenation, and complex shell syntax". Anyone who has written a shell parser knows why: g'it' push, an alias, or bash -c "$(…)" can all slip past a prefix match. Treat allowlists as a convenience, and put the real boundary somewhere that enforces it at the OS level.

What does the sandbox actually enforce, and what doesn't YOLO touch?

In VS Code, turn on chat.agent.sandbox.enabled (or the Sandboxing for terminal toggle in the picker). The docs are explicit that Allow all and Autopilot skip prompts "but an enabled sandbox still restricts terminal file system and network access". Under the hood VS Code's docs list:

macOS: Apple's Seatbelt, built in.
Linux / WSL2: bubblewrap for filesystem isolation plus socat for network proxying (apt-get install bubblewrap socat). WSL1 is out, because bubblewrap needs user namespaces.

Two caveats from the same docs: outbound network stays on by default (chat.agent.sandbox.network.allowNetwork defaults to true), so lock that down separately; and the sandbox is "not a virtual machine or user-account boundary". If you see the older key chat.tools.terminal.sandbox.enabled in blog posts, it's no longer in VS Code's docs.

The Copilot CLI has /sandbox / --sandbox too. GitHub's reference still marks it experimental while the changelog says it's available to everyone, and the CLI docs don't say whether --yolo bypasses it. We treat it as a separate layer like VS Code's, but if you rely on it, check what /sandbox reports.

Can a cloned repo flip YOLO on for me?

In VS Code, the front-line defense is Workspace Trust: an untrusted folder opens in restricted mode, which "also disables agents". So review a repo before you trust it, because trust is what unlocks agents in it at all. The global auto-approve setting is something you set yourself, and the docs steer you to the session-scoped level instead. The CLI has a notion of trusted directories too: COPILOT_ALLOW_ALL=true trusts the current directory, and /add-dir PATH grants file access to another directory and loads its .github/skills and .github/agents as trusted configuration. That's worth remembering before you point a YOLO session at a repo you haven't read.

How do I turn on YOLO per task or per workspace with AgentRQ?

Copilot's YOLO is session-scoped: once on, it's on for everything that session does. If you'd rather decide per task, and answer prompts from somewhere other than the terminal, you can route the Copilot CLI through AgentRQ via the ACP Gateway (Copilot setup guide):

npx @agentrq/acp-gateway@latest --agent github-copilot-cli

This covers the Copilot CLI only; Copilot Chat in VS Code keeps its own picker.

Start Copilot without --yolo. The gateway moves each new session out of any mode that would approve on its own and into one where Copilot asks a person. Every permission request then lands in the AgentRQ task (web, phone or Slack) with the command or edit attached, and you answer:

Allow Once: this call only.
Always Allow: adds the tool to the workspace's auto-approved list, so routine calls stop asking.
Deny: Copilot gets a refusal and carries on.

If nobody answers within 30 minutes, the gateway cancels the turn rather than guessing; tune that with --permission-timeout.

Per task. Flip the YOLO toggle on a task, or set it when you create one, to put just that task in YOLO mode. Every permission request in it is auto-approved and Copilot never waits, while every other task in the workspace still asks. The setting sticks to the task even if the agent disconnects and reconnects. Scheduled tasks, event triggers and workflow steps have the same switch, so the nightly job can run in YOLO while your interactive work stays supervised.

Per workspace. Workspace settings has YOLO Mode (Execute All) (UI warning: "Agent will not ask for permission"). Under the hood it's a default, not a global override: the approval check reads the task's own YOLO flag, and the workspace switch decides what that flag starts as. New tasks you create in the web form open with the YOLO toggle already on (you can still switch it off per task), and tasks the agent creates for itself over the workspace MCP server inherit it. Flipping the switch doesn't rewrite tasks that already exist.

Or let a model approve and deny for you, from plain-English rules. Between "ask me every time" and "approve everything" there's a third option: an AgentRQ desktop extension that reviews each permission request before it reaches you. Extensions are trusted Node modules loaded by the AgentRQ desktop app. One registers a reviewer with ctx.hooks.add({ id, review(request) { ... } }) and is handed the pending call: the tool name, the argument preview the harness sent, and the workspace. It answers { behavior: 'deny', reason }, { behavior: 'allow' }, or nothing at all to abstain. Point review() at an external decision API such as TypeSafe's Jev, a "System One" model that returns a typed choice with calibrated probabilities and a confidence in milliseconds instead of generating text. Send the tool call as the state, and your workspace's rules in plain English ("git push is fine on feature branches, never on main", "never read anything under ~/.aws") as a Choice question over allow / deny / ask me. Then threshold it: approve only on a high-confidence allow, refuse on a confident deny, and abstain on everything else so the request lands on your phone as usual. The rules can live on a per-workspace settings tab the extension draws itself; the bundled guardrail example does exactly that with literal patterns.

The review contract is built on one asymmetry: refusing costs a tool call, approving costs whatever the tool call does. So one refusal settles a request; silence (an abstain, an exception, or a reviewer that misses its 5-second deadline) is never an allow, the request just stays in front of you; and an extension needs the decide consent level to approve, while deny consent can only refuse. The install screen starts every extension at none. Reviews only happen while the desktop app is open and signed in, so treat this as a fast first pass, not a security boundary.

The trade-off. Workspace-wide is one click and zero prompts, but it outlives the job you actually trusted: the next task inherits it whether you meant to or not. Per-task YOLO expires with the task. Our default is the workspace switch off, per-task YOLO for the jobs you've vetted, Always Allow for the boring tools, the sandbox on, and a clean git tree before every YOLO run. The tool call history keeps a record of every call, including the auto-approved ones.

FAQ

Is copilot --yolo the same as --allow-all? Yes. Same flag: tools, paths and URLs.

Does --yolo override --deny-tool? No. A deny always wins.

Why doesn't Shift+Tab turn on YOLO in the CLI? It cycles standard, plan and autopilot. Use /yolo.

How do I make Allow all permanent in VS Code? "chat.tools.global.autoApprove": true, though the session-scoped picker level is the safer habit.

Does Allow all disable the VS Code sandbox? No. An enabled sandbox still restricts terminal filesystem and network access.

Is Autopilot YOLO? No. Autopilot keeps the agent going; YOLO approves its tool calls.

For every other agent, see what YOLO mode is and how to turn it on in every coding agent.

Your turn: do you run Copilot with --yolo plus a couple of --deny-tool guards, or do you trust the assisted classifier more than your own regexes? Tell me your setup in the comments.

Originally published on AgentRQ.

Gemini CLI YOLO mode, read from the source: why settings.json can't turn it on

Tony — Mon, 12 Oct 2026 18:01:40 +0000

TL;DR

Start YOLO with gemini --approval-mode=yolo, or press Ctrl+Y in a running session. --yolo / -y still work but are deprecated, and combining --yolo with --approval-mode is an error.
You cannot make YOLO the default in settings.json. That's a deliberate design choice, and the code that enforces it is three lines long.
YOLO only removes approval prompts. The sandbox (Seatbelt, Docker, Podman, gVisor, LXC) is a separate switch, and in the current source YOLO never turns it on.
In an untrusted folder, any mode other than default gets forced back to default. If security.disableYoloMode or admin secure mode is set, asking for YOLO is a fatal config error, not a silent downgrade.

Everything below was checked against the Gemini CLI source (google-gemini/gemini-cli, 0.65.0-nightly.20261006) and its docs, on October 7–8, 2026.

Who is this even for in late 2026?

Short version: Gemini CLI users with a Gemini Code Assist Standard or Enterprise license.

Since June 18, 2026, Gemini CLI no longer serves Google AI Pro, Ultra or free Code Assist users. Google moved them to the Antigravity CLI (agy), which has a different YOLO story (it's agy --dangerously-skip-permissions, and there's no --yolo at all). Gemini CLI is still developed, though, and the approval code is worth reading on its own. It's one of the cleaner permission designs among coding agents.

What does Gemini CLI actually do with an approval mode?

There are four modes: default, auto_edit, plan and yolo. Here's how the CLI picks one at startup, in order:

--approval-mode <x> on the command line
else --yolo / -y, which maps to yolo
else general.defaultApprovalMode from settings, unless its value is yolo, in which case it's skipped
else default

Step 3 is the interesting one. The resolver doesn't reject a "yolo" value in settings. It just reads past it, as if the key weren't there. The settings schema says it outright: YOLO "can only be enabled via command line".

Two gates come after the mode is resolved:

Kill switch. If security.disableYoloMode or admin.secureModeEnabled is set and the resolved mode is YOLO, startup throws a FatalConfigError. It doesn't quietly drop you to default. You asked for something that's banned, and the CLI tells you so.
Folder trust. If the current folder isn't trusted, any mode other than default gets forced back to default, with a warning. This one applies to auto_edit and plan too, not just YOLO.

Why can't I just put "yolo" in settings.json?

The threat model is a cloned repo.

Gemini CLI merges settings from several layers, and one of them is the workspace's own .gemini/settings.json. If a project file could set defaultApprovalMode: "yolo", then 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. Prompt injection plus auto-approval is the worst combination in agent security.

So the rule is: YOLO has to come from a human typing a flag (or a key) in this process. Settings can make you more cautious (disableYoloMode, secureModeEnabled, folder trust), but never less. If you want YOLO every time, the supported answer is a shell alias:

alias gemini-yolo='gemini --approval-mode=yolo --sandbox'

Compare that with Qwen Code, Gemini CLI's fork, which does allow tools.approvalMode: "yolo" in settings. It pushes the protection down to folder trust instead.

Does YOLO turn the sandbox on?

Not in the current code, whatever one older config page says.

Gemini CLI has two independent layers:

Layer	What it gates	Switch
Approval mode	Whether a human confirms each tool call	`--approval-mode`, Ctrl+Y, Shift+Tab
Sandbox	What a tool call can touch once it runs	`--sandbox`, `GEMINI_SANDBOX`, `tools.sandbox`

The sandbox resolver never reads the approval mode. With nothing set, it returns "no sandbox". Here's what you get when you turn it on:

macOS, sandbox: true: sandbox-exec (Seatbelt) is picked first. The default profile is permissive-open. Despite the name, it starts from (deny default), allows file reads anywhere, and allows writes only to the project dir, temp, cache, ~/.npm, ~/.cache and any --include-directories. It also explicitly blocks the Docker socket and writes to ~/.gemini credential files (oauth_creds.json, mcp-oauth-tokens.json, …). Pick another built-in profile with SEATBELT_PROFILE: permissive-* and restrictive-* come in -open, -closed and -proxied network flavors, and strict-* in -open and -proxied. Anything not on that list is rejected, which also stops path traversal through the variable.
Linux/other, sandbox: true: Docker, then Podman, whichever exists.
Explicit only: runsc (gVisor, Linux only, run via Docker's --runtime=runsc), lxc (needs a container you already have running, so it's never auto-detected) and windows-native (Windows only).

A wrong value fails fast. GEMINI_SANDBOX=runsc on a Mac, or true with neither Docker nor Podman installed, is a fatal error, not a silent run without a sandbox.

The point: YOLO plus a sandbox is a reasonable setup. YOLO without one means "run anything with my user's full privileges". Pass --sandbox yourself.

How do Ctrl+Y and Shift+Tab interact?

Ctrl+Y toggles between YOLO and default. This is the only in-session way into YOLO.
Shift+Tab cycles default → auto_edit → plan (plan only if it's enabled). It never lands on YOLO. If you're in YOLO and press it, you drop to auto_edit.

Small design choice, sensible result: the key you hit all the time can't take you to the dangerous mode by accident.

One more thing: --yolo together with --approval-mode doesn't pick a winner. It's a validation error. Ambiguous intent fails at the door.

What happens in CI and headless runs?

This edge case trips people up. In non-interactive mode (gemini -p "…") there's nobody to answer a prompt, and the policy engine handles that by translating ask_user decisions into deny. So in headless default mode, a tool call that would have asked simply doesn't run.

Belt and braces: the CLI also removes ask_user, the tool the model uses to ask you a question, from the toolset in headless and ACP modes. The source comment says why: so that "it can never be allowed via a high-priority policy rule when no human is present". In ACP mode the IDE or client does the asking instead.

So headless, your options are:

--approval-mode=yolo, ideally with --sandbox
--approval-mode=auto_edit, plus policy rules that allow the shell commands you need
or a policy file that says allow for exactly the tools the job uses

What are the halfway options?

auto_edit approves file edits and still asks before shell commands.
tools.allowed lists tool patterns that skip the prompt, such as run_shell_command(git).
The policy engine is the recommended route: TOML files in ~/.gemini/policies/ with allow / deny / ask_user rules, which can be scoped to a mode (including YOLO). --allowed-tools on the command line is deprecated in its favour.

For the Gemini Code Assist extension in VS Code, set "geminicodeassist.agentYoloMode": true in user settings and reload the window. Note the familiar rule again: it only works in a trusted workspace. In IntelliJ, the matching option is Auto-approve changes.

How do I turn on YOLO per task or per workspace with AgentRQ?

Gemini CLI's switch is per process: you either started with --approval-mode=yolo or you didn't. AgentRQ moves that decision onto the task.

1. Connect Gemini CLI. It goes through the ACP Gateway. The Gemini CLI setup guide and the step-by-step post have the details:

npx @agentrq/acp-gateway@latest --agent gemini

Start it without --approval-mode=yolo. The gateway also moves each new session out of any mode that would approve on its own and into one where Gemini CLI asks a person.

2. Answer from anywhere. Each permission request shows up in the AgentRQ task, on the web, on your phone or in Slack, along with the command or edit it's asking about. You answer Allow Once, Always Allow (adds the tool to the workspace's auto-approved list) or Deny. If nobody answers within 30 minutes, the gateway cancels the turn instead of guessing. --permission-timeout changes that limit.

3a. YOLO for one task. Flip the YOLO toggle on a task, or when you create it. Every permission request in that task is approved automatically, while every other task in the workspace still asks. The flag lives on the task, so it persists across agent disconnects and reconnects. Scheduled tasks, event triggers and workflow steps have the same switch.

3b. YOLO for the whole workspace. Workspace settings has YOLO Mode (Execute All) (UI warning: "Agent will not ask for permission"). Under the hood it's a default, not a global override: the approval check reads the task's own YOLO flag, and the workspace switch decides what that flag starts as. New tasks you create in the web form open with the YOLO toggle already on (you can still switch it off per task), and tasks the agent creates for itself over the workspace MCP server inherit it. Flipping the switch doesn't rewrite tasks that already exist.

The trade-off. Per-task YOLO is scoped trust: it ends when the job you vetted ends, and an unattended nightly job can run in YOLO while your interactive work stays supervised. Workspace-wide YOLO is easier, but it outlives any single decision you made, and every new task inherits it. The setup that holds up: leave the workspace switch off, use per-task YOLO, keep GEMINI_SANDBOX=true (or "tools": {"sandbox": true}) so the auto-approved commands still run in a container, start from a clean git tree, and read the tool call history afterwards. More on the per-task model: AgentRQ YOLO mode.

FAQ

Is gemini --yolo still a thing? It works, but it's deprecated. Use --approval-mode=yolo, and don't pass both.

Can I make YOLO the default in settings.json? No. The resolver skips "yolo" in defaultApprovalMode. Use a shell alias.

What does Ctrl+Y do? It toggles YOLO ↔ default in the running session.

Does YOLO enable the sandbox? Not in the current source. Add --sandbox or set GEMINI_SANDBOX.

Why does Gemini CLI refuse to start with --yolo? security.disableYoloMode or admin.secureModeEnabled is set. That's a fatal error by design. If it starts but drops you to default, the folder isn't trusted.

Why do my tool calls silently not run in gemini -p? Headless mode turns "ask" into "deny". Use YOLO (with a sandbox), auto_edit, or allow rules in a policy file.

For every other agent, see what YOLO mode is and how to turn it on in every coding agent.

Over to you: do you think "YOLO only from a flag, never from settings" is the right call, or should a tool trust your user-level config the way Qwen Code does? And if you run Gemini CLI in CI, which sandbox backend did you end up on? 👇

Originally published on AgentRQ.

Codex CLI YOLO mode: two knobs, one flag, and why --yolo also kills the sandbox

Tony — Sat, 10 Oct 2026 15:30:53 +0000

TL;DR

codex --yolo is a short alias of --dangerously-bypass-approvals-and-sandbox. It sets approvals to never and the sandbox to danger-full-access.
That second part is unusual. Claude Code's and Gemini CLI's YOLO modes skip prompts but leave sandboxing alone. Codex's removes both.
The two knobs are orthogonal: -a never -s workspace-write gives you "never ask, but stay fenced", which is what most people actually want.
The sandbox is real OS isolation: Seatbelt (sandbox-exec) on macOS, bubblewrap + seccomp on Linux/WSL2, a native sandbox on Windows, and nothing on WSL1.
codex exec never asks for approval, so in CI the sandbox is the only knob that matters.

Every flag below was checked against openai/codex at commit 72c9595 (release 0.161.0), @agentclientprotocol/codex-acp 2.1.1 and OpenAI's Codex docs on October 7, 2026.

What are the two knobs?

Codex models safety as two independent dimensions:

Knob	Config key	CLI flag	Values
When to ask you	`approval_policy`	`-a` / `--ask-for-approval`	`on-request` (default), `never`, or a `granular` table
What a command can reach	`sandbox_mode`	`-s` / `--sandbox`	`read-only`, `workspace-write`, `danger-full-access`

on-request means the model may stop and ask whenever it wants to do something the sandbox would block. The sandbox then decides, at the OS level, which files are writable and whether there's network.

Because the knobs are independent, you get a 2×3 grid of behaviours. The interesting cells:

codex -a never -s danger-full-access   # == codex --yolo
codex -a never -s workspace-write      # never asks, still fenced
codex -a on-request -s danger-full-access  # no fence, may still ask (rarely does)

The middle one has a lovely failure mode: when a command needs more than the sandbox allows, it simply fails, and the error goes back to the model to work around. No human in the loop, but no escape either.

On the CLI, -a only accepts on-request and never. Combining flags that both set a knob is rejected: --yolo can't be combined with -a, and --approve-for-me can't be combined with -a, -s or --yolo.

Why does Codex's YOLO also drop the sandbox?

Because the flag's own help text says it's meant for environments that are already sandboxed from the outside (it calls itself "EXTREMELY DANGEROUS"). The design assumption is: if you're telling Codex "never ask", you're probably in a container, VM or CI runner where an inner sandbox is just friction. That assumption is great in CI and terrible on your laptop.

Here's what danger-full-access actually means. Not "the project". Everything your user account can reach:

Every file you can read or write: ~/.ssh, ~/.aws, ~/.config/gcloud, browser profiles, other repos, dotfiles.
Unrestricted network: download-and-run, call APIs with any token it finds, exfiltrate anything.
Your git identity: .git is no longer protected, so history rewrites and git push --force go out as you.
Every exported env var in the shell that started Codex.

Now add prompt injection. A malicious instruction in a README, an issue, or a fetched web page can steer the model, and with YOLO on nothing pauses to ask you.

How is the sandbox actually built?

Platform	Mechanism	Notes
macOS	Seatbelt via `sandbox-exec`	Built into the OS, nothing to install
Linux	bubblewrap + a seccomp network filter	Uses `bwrap` from `PATH` or a bundled copy. The old Landlock backend is legacy and refused for filesystem-restricted policies
WSL2	Same as Linux
WSL1	None	WSL1 can't create the user namespaces bubblewrap needs, so Codex refuses sandboxed commands
Native Windows	Codex's own sandbox	Unelevated and elevated variants; `/setup-default-sandbox` sets up the elevated one

The Linux one is the gotcha. bubblewrap needs unprivileged user namespaces. Inside an unprivileged container they're often unavailable, you get a startup warning, and the sandbox can't start. That's the one situation where running --yolo inside a container is the normal setup rather than a shortcut: the container is the sandbox.

Even in workspace-write, Codex keeps .git, .codex and .agents read-only, so it can't rewrite history or its own config without asking. That's a neat detail: the agent's own control plane is outside its write fence.

How do I get most of YOLO without dropping the fence?

Most YOLO cravings come from two workspace-write limits: no network, and no writes outside the project. Open them individually:

sandbox_mode = "workspace-write"
approval_policy = "never"

[sandbox_workspace_write]
network_access = true
writable_roots = ["/Users/me/.cache/pip"]

network_access makes npm install/pip install work. writable_roots (or --add-dir <DIR> per run) adds folders. exclude_tmpdir_env_var and exclude_slash_tmp remove $TMPDIR and /tmp from the writable set if you want it tighter.

How does config precedence work, and where does project trust fit?

Codex reads ~/.codex/config.toml (or $CODEX_HOME/config.toml). The YOLO default is just:

approval_policy = "never"
sandbox_mode = "danger-full-access"

A few precedence rules worth knowing:

-c key=value overrides any key for one run.
Permission profiles: default_permissions = ":danger-full-access" (also :workspace, :read-only) is the newer form, and wins over sandbox_mode when set.
Profiles: codex -p yolo layers ~/.codex/yolo.config.toml on top of your normal config. Keeping YOLO in a profile means it's opt-in per launch. (Old [profiles.yolo] tables still load, but -p now means the separate file.)
Managed requirements.toml: an admin can forbid never or danger-full-access, and Codex falls back to the allowed default.
Retired value: approval_policy = "untrusted" is now a hard error at startup. on-failure is still accepted as another name for on-request.

Project trust is how Codex handles the "random cloned repo" problem. The first time you open a folder, Codex asks whether you trust it and records trust_level = "trusted" under [projects."/path"] in your config. A trusted, version-controlled project starts in workspace-write + on-request; anything untrusted or not under version control starts read-only. Trust only sets the default: an explicit --yolo or config key still wins. The point is that the decision lives in your home directory, not in the repo.

How does the in-session switch work?

/permissions opens a picker with three presets:

Preset	Approvals	Sandbox
Read Only	on-request	`read-only`
Default	on-request	`workspace-write`
Full Access	never	`danger-full-access` (the YOLO preset)

With the Auto-review experiment on, there's also an Auto-review mode that routes approvals to an automatic reviewer (the CLI equivalent is --approve-for-me, hidden alias --not-so-yolo, which pairs that reviewer with workspace-write). /approvals is gone; /approve only retries one action the reviewer rejected. There's no keyboard shortcut to Full Access, which is deliberate friction.

Gotcha: config is read at session start. Edit config.toml mid-session and nothing changes until you restart or use /permissions.

What changes in CI with codex exec?

codex exec runs one task non-interactively. There's nobody to ask, so it never asks and has no -a flag. The sandbox is the only knob, and it defaults to read-only:

codex exec "summarize the open TODOs"                        # read-only
codex exec --sandbox workspace-write "fix the failing tests"
codex exec --yolo "run the full release script"              # no sandbox

exec refuses to run outside a git repo unless you pass --skip-git-repo-check (or --yolo, which skips it too). --json streams JSON Lines events; -o <file> writes the final message. Use CODEX_API_KEY scoped to that one step, not job-wide, if the workflow checks out untrusted code.

On GitHub, openai/codex-action@v1 keeps the key behind a proxy, drops sudo by default (safety-strategy: drop-sudo), and takes permission-profile: ":workspace". A hosted runner is exactly the "outer sandbox" --yolo assumes, but the workspace profile is usually enough.

Two more things YOLO does not skip: hooks still need to be trusted once (--dangerously-bypass-hook-trust exists for automation that vets them), and --full-auto is simply gone (use -s workspace-write).

How does YOLO map over ACP?

Codex doesn't speak the Agent Client Protocol natively. @agentclientprotocol/codex-acp is a stdio adapter that starts the Codex App Server and translates both ways. Over ACP there are no flags, just four session modes:

ACP mode	Approvals	Sandbox	CLI equivalent
`read-only`	asks you	read-only	`-s read-only`
`workspace-write`	asks you	workspace-write	`/permissions` Default
`agent` (default)	automatic reviewer	workspace-write	`--approve-for-me`
`agent-full-access`	never	danger-full-access	`--yolo`

Note the default is agent, so Codex over ACP doesn't ask you about most things even before YOLO. INITIAL_AGENT_MODE=agent-full-access starts it in YOLO; CODEX_CONFIG merges a JSON object into session config.

How do I turn on YOLO per task or per workspace with AgentRQ?

Every Codex switch above is session-scoped. If you want YOLO for one job and approvals for everything else, move the decision out of Codex and into a task.

1. Connect Codex through the ACP Gateway (Codex CLI ACP setup guide):

npx @agentrq/acp-gateway@latest --login --agent codex-acp   # once
npx @agentrq/acp-gateway@latest --agent codex-acp

The gateway moves each new session out of any self-approving mode (Auto review, Full access) and into read-only, so every edit and command comes to you as a permission request in the AgentRQ task, on the web, your phone or Slack. You answer:

Allow Once: this call only.
Always Allow: adds the tool to the workspace's auto-approved list.
Deny: Codex gets the rejection; you can reply with what to do instead.

If nobody answers within 30 minutes, the gateway cancels the turn instead of guessing (--permission-timeout changes it).

2a. Per task. Flip the YOLO toggle on a task, or set it at creation. Every permission request in that task is auto-approved; every other task still asks. Scheduled tasks, event triggers and workflow steps have the same switch. The per-task flag persists across agent disconnects and reconnects.

2b. Per workspace. Workspace settings has YOLO Mode (Execute All) (UI warning: "Agent will not ask for permission"). Under the hood it's a default, not a global override: the approval check reads the task's own YOLO flag, and the workspace switch decides what that flag starts as. New tasks you create in the web form open with the YOLO toggle already on (you can still switch it off per task), and tasks the agent creates for itself over the workspace MCP server inherit it. Flipping the switch doesn't rewrite tasks that already exist.

The trade-off. Workspace-wide is AgentRQ's version of putting approval_policy = "never" in your global config: zero friction, but it outlives the job you trusted. Per-task YOLO scopes it to one unit of work. Crucially, YOLO in AgentRQ only removes the questions: Codex keeps the sandbox of the mode it's in, so it never turns into danger-full-access. Concrete example: task A ("upgrade test deps and fix what breaks", YOLO on) runs to the end unattended; task B ("clean up the staging deploy script", YOLO off) pings your phone for ./deploy.sh --dry-run (Allow Once) and later git push --force origin staging (Deny, "open a PR instead"). Same Codex, same gateway. Start YOLO tasks from a clean git tree and check the tool call history afterwards. More in the YOLO mode feature page.

FAQ

Is --yolo the same as --dangerously-bypass-approvals-and-sandbox? Yes, identical.

How do I get no prompts but keep the sandbox? codex -a never -s workspace-write.

Why "unexpected argument '--yolo'"? Your Codex predates the alias. npm install -g @openai/codex@latest or brew upgrade --cask codex.

Why does Codex still ask in YOLO? Config changed mid-session, only one of the two keys is set, an admin requirements.toml forbids it, a hook awaits trust, or you're on ACP where the client picks the mode.

Does Codex sandbox work in WSL1? No. Use WSL2.

Is --full-auto YOLO? It never was, and it's removed. Use --sandbox workspace-write.

Comparing agents? Here's YOLO mode in every coding agent, side by side.

Where do you land: --yolo only inside containers, or -a never -s workspace-write with network_access = true everywhere? And has anyone hit the bubblewrap user-namespace wall in their CI? Tell me in the comments.

Originally published on AgentRQ.

Claude Code YOLO mode: what --dangerously-skip-permissions really turns off (and what it doesn't)

Tony — Fri, 09 Oct 2026 15:35:38 +0000

TL;DR

Claude Code's YOLO mode is officially called bypass permissions: claude --dangerously-skip-permissions, which is exactly claude --permission-mode bypassPermissions.
It removes the permission prompts. It does not touch the Bash sandbox, which is a separate, OS-enforced layer (Seatbelt on macOS, bubblewrap + socat on Linux/WSL2).
deny rules, explicit ask rules and the critical-path rm guard still fire in bypass mode.
A repo's own .claude/settings.json cannot switch YOLO on. Only user settings, managed settings or --settings can.
For most people, auto mode (a classifier reviews each action) is the better "YOLO, but not stupid".

Everything here was checked against Anthropic's docs at code.claude.com and claude --help from Claude Code 2.1.292 on October 7, 2026.

Why does "skip permissions" not mean "no guardrails"?

The first thing to internalize is that Claude Code has two independent safety layers, and they're enforced in completely different places:

Layer	Enforced by	What it gates	Does YOLO remove it?
Permission prompts	Claude Code itself, before a tool call runs	Every tool call: Bash, Edit, Write, MCP tools…	Yes
Bash sandbox	The operating system, while a command runs	Filesystem writes and network egress of shell commands and their children	No

The permission layer is a policy check in the agent's process: "is this tool call allowed, denied, or do I ask the human?" Bypass mode short-circuits the "ask" branch to "allow". Allow rules become irrelevant, because everything is allowed anyway.

The sandbox is a different beast. When it's on, Claude Code wraps each shell command in an OS-level boundary built on Anthropic's open source @anthropic-ai/sandbox-runtime:

macOS: the built-in Seatbelt framework. Nothing to install.
Linux and WSL2: bubblewrap for filesystem isolation and socat to relay network traffic through the sandbox proxy (plus a seccomp filter; /sandbox shows a Dependencies tab if any piece is missing).
Native Windows: no sandbox. Use WSL2.

By default a sandboxed command can write only to the working directory, a per-user temp dir and directories you've added. Network has no direct route out: everything goes through a local proxy that checks each host against an allowlist that starts empty. That's why something like curl --noproxy '*' just fails to resolve: there's no route around the proxy.

So YOLO answers "should I ask?" and the sandbox answers "what can this process physically reach?". You can (and should) run them together.

What survives bypass mode?

Even with every prompt gone, these still apply:

deny rules and explicit ask rules in your permission config.
The guard against rm on critical paths.
Questions Claude asks you directly (it's still allowed to stop and ask).
The sandbox, if you turned it on with /sandbox or "sandbox": {"enabled": true}.

There's one sharp edge in that last point. When a command fails inside the sandbox (say, a tool that's incompatible with it, or a blocked host), Claude can retry it with a dangerouslyDisableSandbox parameter. In bypassPermissions mode, that unsandboxed retry runs without a prompt. Two ways to close the hatch:

{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false
  }
}

With that set, Claude Code ignores dangerouslyDisableSandbox entirely (the /sandbox Overrides tab calls this Strict sandbox mode). Alternatively, add an ask rule for Bash(dangerouslyDisableSandbox:true); per the docs it prompts even in bypass mode and beats a matching allow rule.

Also worth knowing: the sandbox covers shell commands only. Read/Edit/Write/WebFetch, hooks, local MCP servers and your status line command run outside it, governed only by permission rules. In bypass mode that means they're governed by… your deny rules. If you want one boundary around everything, run the whole claude process in a container or VM.

How do you actually turn it on?

Where	Full YOLO	Halfway
CLI	`claude --dangerously-skip-permissions`	`claude --permission-mode auto` or `acceptEdits`
settings.json	`"defaultMode": "bypassPermissions"`	`"defaultMode": "acceptEdits"`
In a session	Shift+Tab, if allowed at launch	Shift+Tab
VS Code	`claudeCode.allowDangerouslySkipPermissions`	mode selector
Rules	—	`"allow": ["Bash(npm test)"]`

The flag:

claude --dangerously-skip-permissions
# identical to:
claude --permission-mode bypassPermissions

--permission-mode takes manual (the default, spelled default in config files), acceptEdits, auto, plan, dontAsk and bypassPermissions. The first interactive run shows a warning you have to accept.

As a persistent default, in ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "bypassPermissions"
  }
}

Why can't a cloned repo flip YOLO on for you?

This is my favourite design decision in the whole permission system. defaultMode: "bypassPermissions" is honoured in user settings, managed settings and a file passed with --settings. It is ignored in a project's own .claude/settings.json and .claude/settings.local.json: Claude Code just starts in the default mode.

Think about the threat model. Project settings ship with the repo. If they could set bypass mode, then git clone evil/repo && cd repo && claude would hand an attacker an agent that runs anything without asking, and the attacker's README or issue text is right there to prompt-inject it. The rule is simple: only scopes you control can lower your guard. The same idea shows up elsewhere in the sandbox docs, where credential-masking settings are honoured only from user/managed/--settings scopes and ignored in a repo's settings.

Cloud sessions ignore bypassPermissions from settings files too, and admins can kill the mode org-wide:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Why won't --dangerously-skip-permissions run as root?

On Linux and macOS, Claude Code refuses to start in bypass mode as root or under sudo, unless it detects it's already inside a sandbox. That's the "no prompts and unlimited privilege" combination it won't sign off on. If you hit this in a container, it's the container detection that matters; on a bare host, the fix is "don't be root", not "find a workaround".

Why isn't bypass in my Shift+Tab cycle?

Shift+Tab cycles auto → default → acceptEdits → plan, then any optional modes. Bypass is only part of the cycle if the session was launched with permission to use it. To have it available without starting in it:

claude --allow-dangerously-skip-permissions

It's a nice two-step arm-then-fire design: the capability is granted at process start (a deliberate act), and only then can a keystroke reach it. A stray Shift+Tab in a normal session can never land you in YOLO.

In VS Code, claudeCode.allowDangerouslySkipPermissions plays the same "arm" role: it adds Bypass permissions to the mode selector. claudeCode.initialPermissionMode sets what new conversations start in (default, acceptEdits, plan, bypassPermissions).

Is auto mode just YOLO with extra steps?

No, and it's what I'd reach for first. In auto mode a separate classifier model reviews each action and only stops you for the risky ones. Since 2.1.283 it's the default starting mode in the terminal and VS Code on supported models.

The other halfway options compose nicely:

acceptEdits: file edits go through, shell commands still ask.
Allow rules: "Bash(npm test)", "Bash(git *)", "Read" in permissions.allow, or --allowedTools.
Sandbox auto-allow: with the sandbox on, sandboxed Bash commands can run without prompts because the OS, not you, limits what they can reach. Deny rules, critical-path rm and content-scoped ask rules like Bash(git push *) still prompt.

That last combo is, for me, the sweet spot: zero prompts for npm test and friends, but a kernel-enforced fence around writes and egress.

How do I turn on YOLO per task or per workspace with AgentRQ?

Everything above is session-scoped: you decide once, at launch or with Shift+Tab, and that decision covers every tool call until you exit. If you run Claude Code unattended (scheduled jobs, long refactors while you're away), you usually want something finer: YOLO for this job, prompts for everything else. That's the gap AgentRQ fills by moving the approval decision out of the terminal and into a task.

1. Connect Claude Code to a workspace. Follow the Claude Code setup guide, which adds the workspace as an MCP server and a notification channel. Alternatively, run it through the ACP Gateway with --agent claude-acp.

2. Start Claude Code without bypass. Use the default mode or acceptEdits, for example:

claude --permission-mode acceptEdits

Avoid auto mode here, otherwise the classifier answers the permission requests before they ever reach you. Each request now shows up in the AgentRQ task (web, phone or Slack) with the command or edit it's about, and you answer one of:

Allow Once: this call only.
Always Allow: adds the tool to the workspace's auto-approved list, so routine calls stop asking.
Deny: Claude Code gets a rejection and carries on with another approach.

3a. YOLO for one task. Flip the YOLO toggle on a task, or set it when you create the task. Every permission request in that task is approved automatically and Claude Code never waits, while every other task in the workspace still asks. The flag is per task and persists across agent disconnects and reconnects. Scheduled tasks, event triggers and workflow steps have the same switch, so a nightly job can run in YOLO while your interactive work stays supervised.

Per task vs. workspace-wide, the trade-off: the workspace switch is the AgentRQ equivalent of putting bypassPermissions in your user settings: convenient, but it outlives the job you actually trusted, and it covers work you haven't seen yet. Per-task YOLO scopes the blast radius to one unit of work and expires with it. My rule: leave Execute All off, use per-task YOLO for jobs you'd happily git reset, and lean on Always Allow for boring tools (prune that list now and then). Either way, Claude Code's own layers still apply underneath:

Keep /sandbox on, ideally with allowUnsandboxedCommands: false. AgentRQ removes the questions; the sandbox still limits what an approved command can touch.
Start every YOLO task from a clean git tree, so any change is one git reset away.
Read the tool call history afterwards; it lists every call, including the auto-approved ones.

FAQ

Is --dangerously-skip-permissions the same as --permission-mode bypassPermissions? Yes, exactly the same.

Does YOLO mode turn off the sandbox? No. It only skips prompts. But unsandboxed retries run without asking in bypass mode unless you set allowUnsandboxedCommands: false.

Can I put bypass mode in my repo's .claude/settings.json? You can write it, but Claude Code ignores it there. Use ~/.claude/settings.json, managed settings or --settings.

Why does it refuse to start as root? Bypass mode is blocked as root/sudo on Linux and macOS unless Claude Code detects it's already sandboxed.

Why is bypass missing from Shift+Tab? Start the session with --dangerously-skip-permissions or --allow-dangerously-skip-permissions, or set bypass in user settings.

Does the sandbox cover MCP servers and hooks? No. They run with your full access; only shell commands are sandboxed.

Can I approve Claude Code permissions from my phone? Yes. Connect it to an AgentRQ workspace and answer Allow Once, Always Allow or Deny in the task.

If you're comparing agents, here's how YOLO mode works in every coding agent, side by side.

So, what's your setup: full bypass inside a container, auto mode on the host, or sandbox auto-allow with a strict no-retry policy? And has the unsandboxed retry ever surprised you? Tell me in the comments.

Originally published on AgentRQ.

There is no agy --yolo. How YOLO mode actually works in Antigravity (IDE and CLI)

Tony — Thu, 08 Oct 2026 15:37:53 +0000

TL;DR

agy --yolo is not a flag. The CLI's YOLO is agy --dangerously-skip-permissions, or "toolPermission": "always-proceed" in ~/.gemini/antigravity-cli/settings.json.
In the Antigravity IDE, YOLO is the Turbo permission preset.
The two are not equivalent. Turbo turns off approvals and the sandbox, and opens the whole filesystem. The CLI flag turns off approvals only, and leaves the terminal sandbox however it was, which by default means off.
The sane middle ground is the IDE's Default preset, or proceed-in-sandbox in the CLI with the sandbox actually enabled.

Checked against Google's Antigravity docs (antigravity.google/docs) on October 7, 2026. Antigravity is closed source and Google doesn't publish the CLI's full flag list, so everything here comes from the documentation, not the code.

Why are people typing `agy --yolo` in the first place?

Migration muscle memory. On June 18, 2026, Google moved free, Google AI Pro and Ultra users from Gemini CLI to the Antigravity CLI. Gemini CLI had --yolo (now deprecated in favour of --approval-mode=yolo). agy didn't carry it over. Instead, it borrowed Claude Code's spelling:

agy --dangerously-skip-permissions

The naming is a design statement in itself. "yolo" sounds like a fun mode. "dangerously skip permissions" says what you're giving up. Google's CLI guide lists it with --sandbox as launch flags that override your saved settings for that one session, and the settings panel shows when a value came from a flag rather than the file.

What are the two layers YOLO can touch?

Like most serious agents, Antigravity separates two questions:

Approval: does a human confirm this tool call before it runs?
Containment: once it runs, what can it reach?

Where the IDE and CLI differ is in how their "YOLO" maps onto those layers:

	Approvals	Terminal sandbox	Filesystem	MCP / web tools
IDE Turbo	Off	Off	Whole filesystem	Allowed
CLI `--dangerously-skip-permissions`	Off	Unchanged (`--sandbox` / `enableTerminalSandbox`, default off)	Unchanged	Allowed (no prompts)

So "YOLO in the CLI" leaves you exactly as sandboxed as you were before. On a stock install, that's not at all. Turbo is the more honest of the two: it's labelled as the everything-off preset.

How does the CLI's toolPermission work?

The CLI keeps settings in ~/.gemini/antigravity-cli/settings.json, and it only writes the keys you change. The one that matters is toolPermission, which takes four values. Ordered from most to least paranoid:

Value	Behaviour
`strict`	Asks before every tool that isn't a read
`request-review` (default)	Asks before writes, shell commands and web tools
`proceed-in-sandbox`	Runs terminal commands without asking as long as they stay in the sandbox, asks otherwise
`always-proceed`	Never asks. This is YOLO

proceed-in-sandbox is the interesting design. Approval depends on containment, so the prompt only appears when the command wants out. The catch is that it's only meaningful if the sandbox is on:

{
  "toolPermission": "proceed-in-sandbox",
  "enableTerminalSandbox": true
}

In-session, /permissions opens the permissions manager (mode and rules for the running session), and /config or /settings opens the full editor. When a subagent is waiting on an action, Ctrl+K approves just that one action.

Can I get something finer than a global mode?

Yes, with rules. A permissions block takes allow, ask and deny lists:

{
  "permissions": {
    "allow": ["command(git)", "command(npm test)", "write_file(src/)"],
    "deny": ["command(rm)"]
  }
}

Matchers cover commands (including command(regex:...)), file writes, URLs and MCP tools (mcp(server/tool)). Precedence is the conservative one: deny beats ask, ask beats allow. So a broad allow can never swallow a specific deny, and that's what lets you safely allow command(git) while still denying something narrower.

What do the IDE presets actually configure?

On macOS and Linux: Settings → General → Permission Settings. A project can override the preset or choose Inherit General.

Preset	Sandbox	Terminal commands	Files	MCP and web
Default	On	Free inside the sandbox, ask outside	Workspace + temp	Ask
Request Review	Off	Always ask	Workspace only	Ask
Turbo	Off	Run without asking	Whole filesystem	Allowed

Look at the shape of Default. It isn't "ask about everything". It's the IDE version of proceed-in-sandbox: the agent runs freely while it's contained, and stops when it wants to leave. For most work that's the better trade than Turbo. You keep the speed, and the blast radius stays at "workspace + temp".

Request Review is the odd one out. It turns the sandbox off, but makes up for it by asking about every command and limiting files to the workspace. That's human review instead of OS containment.

Two more IDE knobs:

Artifact review policy (asks-for-review, agent-decides, always-proceed) decides whether the agent waits for you to review its plans and other artifacts. It's YOLO for planning, separate from YOLO for tools.
Strict mode is the anti-Turbo. It sends terminal commands, browser JavaScript and artifacts to review, and turns the sandbox on with no network.

Windows still uses the older model. Set Terminal Command Auto Execution to Always Proceed (it still respects your deny list) and the outside-of-folder file access policy to Always Allow. Sandbox mode is a separate toggle there.

Is there an "Antigravity 2.0 YOLO mode"?

Forum posts mention "Antigravity 2.0", but we found no official 2.0 page that changes the permission model. Today's documented options are Turbo in the IDE and --dangerously-skip-permissions / always-proceed in agy. If that changes, the doc pages above are where it'll show up first.

How do I turn on YOLO per task or per workspace with AgentRQ?

Both native switches cover a whole session (or a whole IDE preset). AgentRQ moves the decision to the task, and lets you answer prompts away from the terminal.

1. Connect Antigravity through the ACP Gateway (Antigravity setup guide). Its registry build publishes no checksum, so the first run needs --allow-unverified-agent:

npx @agentrq/acp-gateway@latest --agent antigravity-acp --allow-unverified-agent

Start it without --dangerously-skip-permissions or always-proceed. The gateway also moves each new session out of any self-approving mode and into one where the agent asks a person.

2. Answer from anywhere. Each permission request shows up in the AgentRQ task, on the web, your phone or Slack, with the command or edit it wants to run. You answer Allow Once, Always Allow (adds the tool to the workspace's auto-approved list) or Deny. If nobody answers within 30 minutes, the gateway cancels the turn instead of guessing. --permission-timeout changes the limit.

3a. YOLO for one task. Flip the YOLO toggle on a task, or when you create it. Every request in that task is auto-approved, and every other task still asks. The flag lives on the task, so it survives agent disconnects and reconnects. Scheduled tasks, event triggers and workflow steps have the same switch.

The trade-off. Per-task YOLO is scoped trust: it ends with the job you vetted, so a nightly scheduled run can be YOLO while your interactive tasks stay supervised. Workspace-wide YOLO is less friction, but every future task inherits it. With Antigravity in particular, remember the layering above. AgentRQ's YOLO only answers the approval question, so set "enableTerminalSandbox": true and auto-approved commands still run inside the sandbox. Add a clean git tree before each YOLO task and a look at the tool call history afterwards. More: AgentRQ YOLO mode.

FAQ

Does agy --yolo exist? No. Use agy --dangerously-skip-permissions, or "toolPermission": "always-proceed".

What's the difference between Turbo and the agy flag? Turbo also turns off the sandbox and opens the whole filesystem. The CLI flag only skips approvals.

Is the agy terminal sandbox on by default? No. Enable it with --sandbox or "enableTerminalSandbox": true.

What's the safest "fast" setting? The IDE's Default preset, or proceed-in-sandbox with the sandbox on in the CLI: no prompts while contained, a prompt when the agent wants out.

Do deny rules still work with always-proceed? The docs say Windows' Always Proceed respects the deny list. For rules in general, deny beats ask beats allow.

How do I approve Antigravity commands from my phone? Connect it to AgentRQ through the ACP Gateway. Permission requests show up in the task.

For every other agent, see what YOLO mode is and how to turn it on in every coding agent.

Question for the comments: is "approve automatically only while sandboxed" (Default / proceed-in-sandbox) the pattern every agent should copy, or does it just move the trust problem into the sandbox config? 👇

Originally published on AgentRQ.

DEV Community: Tony

Copilot YOLO mode, dissected: what --yolo, /yolo and Allow all actually skip

Why does "YOLO" mean two different things in Copilot?

What exactly does copilot --yolo turn on?

How do the in-session commands map onto each other?

Why isn't Autopilot the same thing as YOLO?

Can I get most of the speed without approving everything?

How does VS Code's version work?

Are terminal allowlists enough to keep me safe?

What does the sandbox actually enforce, and what doesn't YOLO touch?

Can a cloned repo flip YOLO on for me?

How do I turn on YOLO per task or per workspace with AgentRQ?

FAQ

Gemini CLI YOLO mode, read from the source: why settings.json can't turn it on

Who is this even for in late 2026?

What does Gemini CLI actually do with an approval mode?

Why can't I just put "yolo" in settings.json?

Does YOLO turn the sandbox on?

How do Ctrl+Y and Shift+Tab interact?

What happens in CI and headless runs?

What are the halfway options?

How do I turn on YOLO per task or per workspace with AgentRQ?

FAQ

Codex CLI YOLO mode: two knobs, one flag, and why --yolo also kills the sandbox

What are the two knobs?

Why does Codex's YOLO also drop the sandbox?

How is the sandbox actually built?

How do I get most of YOLO without dropping the fence?

How does config precedence work, and where does project trust fit?

How does the in-session switch work?

What changes in CI with codex exec?

How does YOLO map over ACP?

How do I turn on YOLO per task or per workspace with AgentRQ?

FAQ

Claude Code YOLO mode: what --dangerously-skip-permissions really turns off (and what it doesn't)

Why does "skip permissions" not mean "no guardrails"?

What survives bypass mode?

How do you actually turn it on?

Why can't a cloned repo flip YOLO on for you?

Why won't --dangerously-skip-permissions run as root?

Why isn't bypass in my Shift+Tab cycle?

Is auto mode just YOLO with extra steps?

How do I turn on YOLO per task or per workspace with AgentRQ?

FAQ

There is no agy --yolo. How YOLO mode actually works in Antigravity (IDE and CLI)

Why are people typing agy --yolo in the first place?

What are the two layers YOLO can touch?

How does the CLI's toolPermission work?

Can I get something finer than a global mode?

What do the IDE presets actually configure?

Is there an "Antigravity 2.0 YOLO mode"?

How do I turn on YOLO per task or per workspace with AgentRQ?

FAQ

Why are people typing `agy --yolo` in the first place?