Antigravity YOLO Mode: How --dangerously-skip-permissions Really Works
Updated August 5, 2026
agy --dangerously-skip-permissions. It turns off the confirmation prompt on every action the agent takes, so agy stops asking and just runs.
The name is not marketing. Google could have called it auto-approve, and other vendors do, but the flag is deliberately spelled out so you cannot type it by accident or leave it in a script without noticing. That honesty is worth respecting: this is the mode where the agent edits, deletes, installs and executes without a checkpoint.
This guide covers what the flag actually skips, why it changes how fast Antigravity feels rather than how capable it is, the three situations where it genuinely earns its place, and the containment strategies that make it safe enough to leave running.The flag, and what it actually does
# Normal: agy asks before it acts
agy
# YOLO / turbo: auto-approve everything, no confirmation prompts
agy --dangerously-skip-permissionsBy default, agy pauses before actions that change something and waits for you to approve them. Reading a file is free; writing one, deleting one, running a shell command or installing a dependency is not. Each of those stops the agent until you say yes.
--dangerously-skip-permissions removes that gate entirely. The agent still decides what to do in exactly the same way and is exactly as capable as before. What changes is the latency between its decision and the action, and therefore how far it can get without you.
The flag does not make the agent more aggressive, more autonomous in its planning, or more willing to attempt risky things. It only removes your veto. An agent that would have proposed deleting the wrong directory still proposes it; you simply are not there to say no.
That distinction matters when you are deciding whether to use it. The question is not "do I trust the agent more in this mode", because it is the same agent. The question is "am I going to catch a bad action at the prompt, or would I have clicked yes anyway".
Why approval prompts cost more than they look like they cost
A confirmation prompt takes a second to answer. The reason YOLO mode feels transformative rather than marginally convenient is that the cost is not the second, it is the interruption.
An agent working through a refactor might touch thirty files. In approval mode that is thirty moments where the agent is idle and waiting for a human, and thirty moments where you cannot be doing anything else because the agent is blocked on you. The agent works at your attention span rather than at its own speed.
This gets dramatically worse with parallel agents, which is the case that actually motivates the flag. Four Antigravity sessions in approval mode do not give you four times the throughput; they give you one human round-robining between four blocked processes, and the agents spend most of their time waiting. Approval mode does not scale past one agent. That is the real argument for YOLO, and it is the same argument that applies in the Antigravity agent swarm guide.
The flip side is honest: in approval mode you see every action before it happens, which is a real review process. YOLO trades continuous review for a single review at the end, and that trade is only good if the end state is something you can actually review.
The three situations where YOLO genuinely earns its place
Blanket advice in either direction is useless here. These are the cases where the trade actually pays:
- Mechanical work with a clear finish line. Renaming a symbol across a codebase, migrating a deprecated API, updating imports after a move. The agent will make dozens of near-identical edits, you would approve all of them, and the diff at the end is easy to read.
- Anything with a test suite as the safety net. If a green test run is the real gate, the approval prompt is a worse version of the same check. Let the agent work and let the tests judge it.
- Parallel sessions. Once you are running more than one agent, approval mode stops being a safety feature and starts being a bottleneck that keeps every agent idle.
And the cases where it does not:
- Exploratory work, where you are still deciding what the right change is. The prompts are where you steer.
- Anything touching infrastructure, credentials or production. The blast radius of a wrong action is not bounded by
git. - An unfamiliar codebase, where you cannot yet tell a reasonable edit from an unreasonable one by reading the diff.
Containing the blast radius
YOLO mode is safe in proportion to how easily you can undo it. Three habits do almost all of the work, and none of them involve trusting the agent more.
Commit before you start. This is the whole strategy in one line. A clean working tree before an unattended run means the agent's entire output is a diff you can read, stage selectively, or throw away with one command. It costs five seconds and it converts "what did it do to my files" into a normal code review.
Give each agent its own worktree. If several YOLO sessions share one checkout, they will edit each other's files and you will not be able to tell whose change was whose. A git worktree per agent gives each one an isolated directory on its own branch, which is covered in the worktrees guide.
Scope the task, not the permissions. A tightly-specified task is a better safety mechanism than a confirmation prompt on a vague one. "Update these four files to use the new client" fails safely. "Clean up the codebase" does not, in any mode.
Do not put --dangerously-skip-permissions in a shell alias for agy. The flag is verbose on purpose, and hiding it behind a short alias means you will eventually run an exploratory session in YOLO mode without realising it. Keep the typing cost; it is doing a job.
The other flags worth knowing alongside it
# Start a new session in the current project
agy
# Continue your most recent conversation
agy -c
# Resume a specific conversation by id
agy --conversation <id>These matter for YOLO specifically because an unattended run is exactly the kind of session you will want to come back to. agy -c picks up your most recent conversation where it ended, which is the one you will reach for after reviewing a diff and deciding the agent needs one more pass.
When you have several sessions and need an older one, agy --conversation <id> resumes it by id. Finding that id is its own small problem, and it is covered in the Antigravity conversation history guide.
Running several YOLO agents without losing track
The moment YOLO mode pays off is also the moment it becomes hard to supervise. Agents that never stop to ask also never announce themselves, so a session that finished twenty minutes ago looks exactly like one still working, and a session that went wrong looks exactly like one going well.
CodeAgentSwarm, the desktop workspace for running several AI CLI agents in parallel, gives every Antigravity session its own terminal with a live status, so you can see at a glance which agents are working, which are waiting and which are done, and it fires a desktop notification the moment any of them finishes. Combined with a worktree per agent, that is what makes a swarm of YOLO sessions supervisable rather than just fast.
FAQ
It is the auto-approve mode, enabled with agy --dangerously-skip-permissions. Antigravity stops asking for confirmation before actions that change things (writing files, running commands, installing dependencies) and simply runs them.
No. It is exactly the same agent making exactly the same decisions. The only thing that changes is that your approval step is removed, so the agent gets further without waiting for you. It does not become more aggressive or more autonomous in its planning.
It is as safe as your ability to undo it. Commit before you start so the agent output is a reviewable diff, give each agent its own git worktree so parallel sessions cannot collide, and keep the task tightly scoped. Do not use it on infrastructure, credentials, production, or a codebase you cannot review by reading the diff.
Deliberately, so you cannot type it by accident or leave it in a script without noticing. That is also why you should not hide it behind a shell alias: the typing cost is doing a job.
Three cases: mechanical work with a clear finish line (mass renames, API migrations), anything where a test suite is the real gate, and any time you run more than one agent at once. Approval mode does not scale past a single agent, because one human cannot unblock four waiting processes.
Each agy session is an independent process, so you can open several. Give each one its own git worktree so they cannot edit each other files, and use a workspace like CodeAgentSwarm to keep every session visible with its status and get a notification when one finishes.
YOLO mode is fastest when several agents run at once and none of them stop to ask. CodeAgentSwarm runs a whole swarm of Antigravity sessions side by side, with a notification the moment any of them finishes.