Running Agents in YOLO Mode (--dangerously-skip-permissions) Safely

May 15, 2026 - 14 min read - 3000 words

Dan Mindru

Creator of Ralph Loop, founder of PageAI

Yes, you can run an agent with --dangerously-skip-permissions safely, but only when the agent is locked inside a sandbox. The exact same flag is reckless on your laptop and a non-event inside a Docker Sandbox microVM. The flag never changes. What changes is what the agent can reach when it stops asking permission. This post explains what YOLO mode does, why you want it for unattended loops, and the one rule that makes dangerously skip permissions safely an honest phrase instead of a contradiction.

What “YOLO mode” actually means

YOLO mode is any configuration where the agent stops asking you to approve commands and just executes them. No “can I run this?” prompt, no confirmation step, no human in the loop on each shell call. The agent reads a task, decides what to do, and does it.

That is the entire appeal and the entire risk in one sentence. The appeal is speed and autonomy. The risk is that you have removed the only gate between a probabilistic model and a real shell.

Claude Code: —dangerously-skip-permissions

In Claude Code the flag is --dangerously-skip-permissions. There is an equivalent longer form, --permission-mode bypassPermissions, documented in the Claude Code docs. Both do the same thing: the agent skips the per-action approval prompt for the rest of the session.

claude --dangerously-skip-permissions
claude --permission-mode bypassPermissions

The name is refreshingly honest. The word “dangerously” is in the flag because Anthropic wants you to feel a little sick typing it on a machine that has your credentials on it. That instinct is correct. The fix is not to avoid the flag. The fix is to change where you run it.

The same idea in other agents

Every serious agent CLI has its own version of this switch, because every long autonomous run needs it. The Codex CLI has a full-auto mode. Gemini, Cursor, Copilot, and opencode each expose an auto-accept or yolo style setting that turns off interactive approvals. The spelling differs per tool, and you do not have to memorize each one, because Ralph Loop launches each supported agent in bypass-permissions mode for you. Pass any extra agent-specific flags after a -- separator:

./ralph.sh --agent codex -- --model gpt-5.5
./ralph.sh -a gemini -- --model pro

Supported agents are claude (the default), codex, copilot, cursor, gemini, and opencode. The common thread across all of them is the same trade. You give up the approval prompt to get an agent that can work without you.

Why you want YOLO mode for unattended loops

Here is the case for turning the prompts off, because it is easy to read “dangerous” and conclude you should always approve commands by hand. You should not, and the reason is structural.

An autonomous loop runs the agent many times. A single iteration of a Ralph loop does real work: it finds the highest-priority incomplete task in .agent/tasks.json, works the steps in the task spec, runs tests, linting, and type checks, commits, and repeats. Across ./ralph.sh -n 50 that is fifty iterations, each one issuing dozens of shell commands. If every command needs your approval, the loop is not autonomous. It is a very slow pair-programming session where you are the bottleneck and you are asleep.

The whole point of running an agent overnight is that you are not there. A permission prompt at 3am is a permission prompt that blocks forever. The agent stalls on the first npm install waiting for a yes that never comes, and you wake up to a loop that did nothing for eight hours.

So unattended runs and per-command approval are mutually exclusive. You either babysit, or you go YOLO. For a long loop, babysitting defeats the purpose, which means YOLO mode is not an edge case. It is the normal operating mode for any agent meant to run while you are away. If you want the deeper version of this argument applied to a single CLI, the run Claude Code in a loop guide walks through the same trade for autonomous Claude Code runs.

The one rule: only go YOLO when the blast radius is contained

Now the rule that makes all of this safe. Run YOLO mode only when the blast radius is contained. The blast radius is everything the agent can touch when it stops asking. Your job is to make that set small, disposable, and external to anything you care about.

A permission prompt is not a security boundary. When the agent asks “can I run this command?” and you click yes, you are the boundary, and you are slow, distracted, and often not awake. When you tell the agent to stop asking, you have not made the agent safe. You have removed the only thing standing between the model and your filesystem. The real fix is to put a wall around the agent that the agent cannot reach through.

On your host, that wall does not exist. An agent running with your user account can read your SSH keys, your ~/.aws/credentials, your browser session cookies, and every other git repository you have checked out. It can push to remotes, delete files, and run a curl | bash it found in a README. None of that requires malice. It is a probabilistic system executing shell commands, and shell commands do not have an undo. For the longer version of why every autonomous run belongs behind a wall, read why you should sandbox every autonomous coding agent.

Inside a Docker Sandbox, the wall is real. A Docker Sandbox is not a plain docker run. It is a lightweight microVM with its own guest kernel, documented in the Docker Sandboxes docs. The agent sees your project directory and a network gate. It does not see the rest of your machine. Run --dangerously-skip-permissions in there and “anything the agent can do” now means “anything it can do inside a microVM that only contains one project directory and a locked-down network.” The dangerous flag becomes a non-event, because the danger had a target on the host and the sandbox removed the target.

This is the inversion worth internalizing. You are not making the agent trustworthy. You are making trust unnecessary by shrinking the blast radius to something you can reset with git or throw away entirely.

flowchart TB
  subgraph Laptop["YOLO on your laptop (host)"]
    HAgent["Agent: --dangerously-skip-permissions"]
    HAgent --> Keys["SSH keys, cloud creds, cookies"]
    HAgent --> Repos["Every other git repo"]
    HAgent --> Net1["Open network: fetch any URL"]
  end
  subgraph Box["YOLO inside a Docker Sandbox"]
    SAgent["Agent: --dangerously-skip-permissions"]
    SAgent --> Proj["Shared project directory only"]
    SAgent --> Gate["Network gate: deny-by-default"]
    SAgent -. "no path to" .-> HostHome["Host home directory"]
  end

Same flag in both boxes. The only difference is the box. On the left, “skip permissions” means skip the last protection your machine had. On the right, it means move fast inside a container that contains nothing precious.

How Ralph runs YOLO mode inside a named sandbox

You can wire this up by hand: create a microVM, launch the agent with the bypass flag, and tear it down when you are done. The point of Ralph is that you do not have to. It computes the sandbox name, checks that the sbx CLI exists, decides whether to create or attach, launches the agent in bypass-permissions mode, and stops the sandbox on exit. Ralph is a hackable Bash loop in the tradition of Geoffrey Huntley’s original Ralph technique, and the YOLO plumbing is part of what it automates.

Answering “Yes” to bypass permissions inside the sandbox

The first time you launch an agent in bypass mode, the CLI shows a one-time warning that asks you to confirm you really want to skip permission prompts. With Ralph, you hit that confirmation inside the sandbox, not on your host, which is exactly where you want to be saying yes. Authenticate and accept the bypass warning in one step with the login action:

./ralph.sh --login
./ralph.sh --login --agent codex

This opens the selected agent inside its correctly named sandbox. You answer the bypass-permissions prompt once, in the microVM, and from then on the agent runs without prompts inside that contained environment. Saying yes to “skip permissions” feels very different when the worst case is a disposable container instead of your home directory.

The deterministic sandbox name is the boundary

Ralph names every sandbox deterministically so the same project and agent pair always reuses the same microVM. The format is:

ralph-<agent>-<current-dir>-<hash8>

The <agent> slug is the lowercased agent name, <current-dir> is the sanitized basename of your project directory, and <hash8> is the first 8 hex characters of a sha256 of the absolute project path. A project at /Users/me/Work/My App running Claude becomes ralph-claude-my-app-a1b2c3d4. The path hash keeps two same-named directories on different paths from colliding, and the agent slug in the name means switching --agent gives you a separate sandbox rather than a surprising state swap.

You never have to memorize it. Ralph prints the name on its startup line, and you can ask for it directly:

./ralph.sh --print-name
./ralph.sh --print-name --agent cursor

That name is the handle for everything else: the sandbox you shell into, the sandbox you allowlist a domain for, and the sandbox Ralph stops on exit.

Create versus attach, every iteration

Each iteration of the loop probes whether the deterministic sandbox already exists. Iteration one usually creates it. Iteration two and onward attach to it. If you manually sbx rm the sandbox mid-run, the next probe simply creates it again. That re-probe is what makes a long YOLO run resilient to you poking at the sandbox by hand.

flowchart TD
  Start["./ralph.sh -n 50"] --> Name["Compute name: ralph-agent-dir-hash8"]
  Name --> CheckSbx{"sbx installed?"}
  CheckSbx -->|"no"| Fail["Exit with docs link"]
  CheckSbx -->|"yes"| Iter["Start iteration"]
  Iter --> Probe{"sandbox exists?"}
  Probe -->|"no"| Create["sbx run --name ... agent ."]
  Probe -->|"yes"| Attach["sbx run name"]
  Create --> Work["Agent works one task in YOLO mode"]
  Attach --> Work
  Work --> Signal{"completion signal?"}
  Signal -->|"COMPLETE"| Done["Exit 0, then sbx stop"]
  Signal -->|"keep going"| Iter

The loop stops on an explicit signal, not a vibe. The agent emits a promise tag: <promise>COMPLETE</promise> when all tasks are done, <promise>BLOCKED:reason</promise> when it needs human help, or <promise>DECIDE:question</promise> when it needs a decision. Those map to exit codes 0, 2, and 3, with 1 reserved for hitting the iteration cap. When the loop ends, Ralph stops the sandbox through its exit trap and hands you back a contained microVM you can inspect or discard.

A safe YOLO run, end to end

Putting the pieces in order, here is what a clean bypass-permissions run looks like. None of these steps put the agent’s hands on your host.

First, install Ralph in your project:

npx @pageai/ralph-loop

Next, authenticate the agent inside its sandbox and accept the bypass-permissions warning once, in the microVM:

./ralph.sh --login

If the task needs network access for installs, allowlist only the domains it needs instead of opening everything. Get the name, then add a rule:

./ralph.sh --print-name
sbx policy allow network ralph-claude-my-app-a1b2c3d4 "*.npmjs.org,github.com"

The network gate matters as much as the filesystem boundary when the agent runs unattended in YOLO mode. A tight allowlist lets installs through and keeps exfiltration out. The full treatment of building that allowlist lives in network policies for AI agent sandboxes.

Then run the loop and walk away. The agent runs with permissions bypassed, but the sandbox is the boundary, so fast and contained are the same thing:

./ralph.sh -n 50

If something looks off mid-run, shell in and look. The sandbox is a normal container from the inside:

sbx exec -it ralph-claude-my-app-a1b2c3d4 bash

When the loop finishes, Ralph stops the sandbox for you. The agent skipped every prompt and ran at full speed, and your host never had its hands on it. This is the default posture Ralph ships, and the broader setup is covered in the pillar guide on running AI coding agents in Docker Sandboxes safely.

Where YOLO mode still bites

A sandbox is a strong boundary and not a magic one. Two limits are worth naming so you do not over-trust the setup.

First, the project directory is shared, which is the entire point, so the agent can absolutely wreck your working tree. The protection there is git, not the sandbox. Commit often, work on a branch, and treat the sandbox as protection for everything outside the project rather than a substitute for version control inside it. A YOLO agent that thrashes on a bad task can still produce a messy diff. The fix is the same as for any agent: clean tasks, frequent commits, and a verification gate of tests, type checks, and linting on every iteration.

Second, whatever you allowlist on the network is genuinely reachable. If you grant a domain that can receive uploads, an agent in YOLO mode could in principle send data there. A "**" allow-all rule throws the whole network surface wide open and undoes half the reason you built the sandbox. Treat network grants like firewall rules: minimal, specific, and reviewed.

Inside those limits, the model is simple and it holds. Skip permissions only when the blast radius is a disposable microVM, enforce the boundary from the outside, and let the agent be fearless where fearless is cheap.

Frequently asked questions

Is it safe to run an agent with --dangerously-skip-permissions?

It is unsafe on your host and safe inside a Docker Sandbox. On the host the flag gives the agent full shell access with no confirmation, so a single bad command can touch your SSH keys, credentials, or other repositories. Inside a microVM sandbox the same flag only grants access to the shared project directory and an allowlisted network, so the worst case is something you can reset with git or throw away.

What is YOLO mode for an AI coding agent?

YOLO mode is any configuration where the agent stops asking you to approve each command and just executes. In Claude Code it is the flag --dangerously-skip-permissions, also written as --permission-mode bypassPermissions. Other agents have their own full-auto or auto-accept setting that does the same thing.

Why do unattended agent loops need bypass-permissions mode?

A long loop issues many shell commands per iteration. If every command needs your approval, the loop blocks the moment you step away and does nothing until you return. Bypass-permissions mode is what lets an agent run overnight without a human approving each action.

Does Ralph Loop run agents in YOLO mode by default?

Yes. Ralph launches each supported agent in bypass-permissions mode because the Docker Sandbox is the boundary. You accept the one-time bypass warning inside the sandbox during ./ralph.sh --login, and every iteration after that runs without prompts inside the contained microVM.

Can a sandboxed YOLO agent still cause damage?

It can damage the shared project directory, since that directory is shared on purpose, so commit often and work on a branch. It can also reach any network domain you allowlist, so keep the allowlist minimal and avoid the allow-all double-star rule. It cannot reach the rest of your host, which is the boundary the sandbox enforces.

Run your own Ralph loop

Ralph is a hackable script you point at your project. Install it and let an agent work through your task list.

npx @pageai/ralph-loop

Install from npm Star on GitHub Watch the walkthrough

Tags:

• sandboxing

Network Policies for AI Agent Sandboxes

Spec-Driven Development vs Vibe Coding: When Each One Wins