Skip to content
RuleSellBeta
Sign up

Topic · A6

YOLO Mode (--dangerously-skip-permissions): The Safe Playbook

Running Claude Code without permission prompts is the most productive setting and the most dangerous one. Here is when to use it, when not to, and the guardrails that make it safe.

There is a flag in Claude Code called --dangerously-skip-permissions. Run it and the agent stops asking before every shell command, file edit, and network call. It just goes. Everyone who has used Claude Code for more than a week knows about this flag. Most have toggled it once and then turned it back off. A few run it as their default.

The reason it has "dangerously" in the name is that Anthropic wants you to think about it. The reason people still use it is that the permission prompts genuinely slow you down on long tasks. Both are true. This page is the honest playbook for when YOLO mode is the right call and what guardrails to put in place when you make it.

What the flag actually does

By default, Claude Code prompts before executing tools that can affect your system — Bash, file Write, file Edit, WebFetch, and the various MCP tools. The prompt looks like:

Run this Bash command? [y/n/edit]

You hit y, the command runs, the agent continues. On a 200-step task, that is 200 prompts. On an overnight autoresearch run, it is thousands.

--dangerously-skip-permissions suppresses every prompt. The agent runs every tool call as if you had typed y. There is no other change — the same tools are available, the same agent loop runs. You have removed the human checkpoint.

When the flag is correct

Three cases justify the flag:

1. You are running inside a sandbox. A Docker container, an ephemeral GitHub Codespace, a fresh VM. The agent can rm -rf / and you do not care because the sandbox dies in two hours. This is the safest use of the flag and the one Anthropic implicitly endorses by shipping the flag at all. The Anthropic Quickstart for autonomous agents recommends Docker + this flag. 2. You are running an unattended long-horizon workflow. autoresearch loops (cluster A6), overnight test sweeps, batch refactors. Babysitting these defeats the point. The flag is correct here if you have a deny-list (next section) and a budget cap on the API spend. 3. You have a hardened repo configuration. A .claude/settings.json with a deny-list of dangerous commands, hooks that block specific patterns, a CLAUDE.md that explicitly forbids destructive operations, and ideally a CI pipeline that prevents force push to main. With those in place, the flag is closer to "skip the prompts, the hooks will catch the bad cases" than to true YOLO.

The pattern these three share: the human checkpoint is replaced by a mechanical one. The flag is only correct when something else is doing the checking.

When the flag is wrong

Inverse list:

  • On your laptop, in a real repo with uncommitted work. A bad git reset --hard or rm -rf here is not recoverable from the agent's logs.
  • With network access to production. If the agent has KUBECTL_CONFIG, AWS_ACCESS_KEY_ID, or a database connection string in its environment, every tool call is a potential production incident.
  • When you do not have a deny-list configured. Default .claude/settings.json is permissive. Running YOLO with the default settings is the worst-case configuration.
  • On a fresh project with no CLAUDE.md. The CLAUDE.md is where you encode "never commit secrets, never push to main, never delete files outside the project root." Without it, the agent has no rules.
The decision is not "is this task too small to need permissions" — it is "is the blast radius contained if the agent does something wrong."

The deny-list pattern

A deny-list is a set of commands or patterns the agent must never execute, enforced by a PreToolUse hook. Example .claude/settings.json:

{
  "permissions": {
    "deny": [
      "Bash(rm -rf )",
      "Bash(rm -rf /)",
      "Bash(git push --force)",
      "Bash(git push -f)",
      "Bash(git reset --hard)",
      "Bash(curl  | sh)",
      "Bash(curl  | bash)",
      "Bash(sudo )",
      "Write(.env)",
      "Write(.env.)",
      "Write(credentials)",
      "WebFetch(http://)"
    ]
  }
}

The patterns are matched against the tool call before execution. A deny match blocks the command and surfaces the block to the agent, which then has to revise its approach.

Three classes of pattern matter most:

  • Filesystem destruction: rm -rf, find ... -delete, truncate, dd of=....
  • Git destruction: git push --force, git reset --hard, git clean -fd, git checkout -- (silently discards working tree).
  • Credential exposure: writing .env, committing private keys, curl-piping unknown scripts.
A starter deny-list for a typical Node.js project, refined over a few weeks of use, runs 20-40 lines. RuleSell publishes per-stack templates (Next.js, Rails, Django, Go, Rust); cluster A6 §10 surfaces these as a wedge content area.

The allowlist alternative

The deny-list is one approach. The opposite is the allowlist — only named commands run without prompting; everything else prompts.

{
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(npx tsc --noEmit)",
      "Bash(git status)",
      "Bash(git diff)",
      "Bash(git log)",
      "Bash(grep)",
      "Bash(find  -name )",
      "Read()",
      "Glob()",
      "Grep()"
    ]
  }
}

The allowlist is safer because the default is to prompt — only explicitly safe commands run autonomously. The cost is more prompts during real work, because you cannot predict every command in advance.

The right starting place for most teams is allowlist plus default-prompt, not YOLO. The deny-list pattern is for teams who genuinely need unattended runs and have done the work to harden the deny rules.

Hooks for additional safety

The hook system in Claude Code is the strongest safety mechanism the deny-list/allowlist cannot replicate alone. Two hooks matter most:

PreToolUse hook — runs before every tool call, can block or rewrite the call. Example: enforce that any git push includes --no-verify only with explicit user confirmation. 
#!/bin/bash
# .claude/hooks/pre_tool_use.sh
if [[ "$TOOL_NAME" == "Bash" ]] && echo "$TOOL_INPUT" | grep -q -- "--no-verify"; then
  echo "BLOCKED: --no-verify requires explicit user approval"
  exit 1
fi
Stop hook — runs when the agent claims completion, can force a verification pass. Example: refuse to end the session if there are unscreenshotted UI changes (this is exactly the visual-debt enforcement we use on RuleSell's frontend repos).

Both hooks compose with --dangerously-skip-permissions. The flag suppresses the prompt; the hook still runs. This is the architecture for "skip the prompts but keep the safety floor."

CLAUDE.md constraints

CLAUDE.md is where the agent's behavior is shaped before any prompt. For YOLO-mode setups, three rules are the minimum:

## Safety Rules (load-bearing)


  • Never run git push --force or git reset --hard without explicit user request in the current turn.
  • Never write to .env, .env., or any file matching credentials or secret.
  • Never delete files outside the project root.
  • Before any destructive operation (file deletion, table drop, branch deletion), verify the target path with ls or git status and confirm in your response that the target matches the intent.

If a tool is denied by a hook, do not retry with a workaround. Surface the block to the user and ask.

These are not magic — a misbehaving agent can ignore them. They reduce the rate of accidents. The combination of CLAUDE.md rules + deny-list + hooks is what makes YOLO mode practical, not any single layer.

The sandbox option

The cleanest version of YOLO mode is running Claude Code inside a sandbox. Two options:

Docker — Run Claude Code in a container with the repo mounted read-write but the host filesystem isolated. The agent can destroy the container; the host is safe. Anthropic's official Quickstart for autonomous coding agents documents this pattern. GitHub Codespaces — A cloud VM per task. The agent runs in the VM, opens a PR with the changes, the VM dies. Blast radius is the VM, not your laptop.

Both let you run with --dangerously-skip-permissions without the standard fears. The trade-off is setup overhead — running Claude Code in Docker takes 10-15 minutes the first time, less after that.

For unattended long-horizon work (autoresearch, batch refactors), the sandbox is the right answer. Running YOLO mode on your daily-driver laptop is almost never the right answer.

Where this fails

1. The deny-list misses creative variants. rm -rf is denied; find . -type f -delete is not. The agent will find the path your patterns miss. Treat the deny-list as defense-in-depth, not perimeter security. 2. Hook bypass via subprocesses. The agent can write a script that calls a denied command, then run the script. Hooks see the script call, not the inner command. Mitigation: deny bash -c, deny writing shell scripts in certain patterns, or run inside a sandbox where the deny-list does not have to be exhaustive. 3. The "I trust this agent" failure mode. Senior engineers who have used Claude Code for months sometimes drop guardrails because they have not been bitten recently. The cluster A6 community signal: people get bitten in the second year of use, not the first. The flag does not get safer with experience. 4. Production credentials in the environment. YOLO mode + production AWS credentials is the worst common configuration. Never run with production credentials available. Use a separate shell or unset them. 5. Cost runaway. An agent in YOLO mode can spend $40-80 in an evening on a misconfigured loop (cluster A6 §5 numbers from autoresearch runs). Set --budget on long-horizon runs and check the spend before sleeping.

The recommended posture

For most users, most of the time:

  • Default mode with the permission prompts on. Hit y 200 times if that is what the task needs.
  • Allowlist for the commands you run constantly (npm test, tsc --noEmit, git status, grep). This removes 80% of the prompt friction.
  • Deny-list + hooks for the destructive patterns, configured once per project and checked into the repo.
  • YOLO mode only inside a sandbox, only for long-horizon work, only with budget caps set.
That posture is more conservative than the "just use YOLO" recommendation that sometimes appears in community blog posts. The conservatism is intentional. The flag is a real productivity gain when used in the right place; it is also the single setting that turns a small accident into a large one.

What to read next

Sources

Related GitHub projects

@anthropics

claude-code

Claude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflows - all through natural language commands.

⭐ 122,880

Frequently asked

What is YOLO mode in Claude Code?
YOLO mode is the community nickname for running Claude Code with the `--dangerously-skip-permissions` flag, which suppresses the per-tool-call permission prompts that would otherwise interrupt the agent. The flag's name is honest — Anthropic deliberately included 'dangerously' in the name because the safety floor it removes is the user reviewing each shell command, file edit, and network call before the agent runs it. With the flag set, the agent runs unattended. That is exactly what makes it productive and exactly what makes it dangerous.
When should I use --dangerously-skip-permissions?
Three legitimate cases: (1) running autoresearch or other long-horizon workflows where you cannot babysit every command, (2) inside a sandbox (Docker container, ephemeral VM, GitHub Codespace) where the blast radius is contained, (3) on a repo where you have already configured a deny-list of dangerous commands via hooks or settings. Outside those, prefer the default permission prompts — the time cost is small relative to the damage of an unwatched `rm -rf` or `git push --force`.
Is there a safer middle ground?
Yes. Claude Code's permission-allowlist mode (configurable in `.claude/settings.json`) auto-approves a named set of commands and prompts for everything else. A well-tuned allowlist for `npm test`, `npx tsc --noEmit`, `git status`, and `grep` removes 80% of the friction without removing the safety floor. This is the workflow most experienced Claude Code users converge on, not full YOLO mode.
Can hooks make YOLO mode safe?
Hooks help a lot. A PreToolUse hook can block a deny-list of dangerous commands (rm -rf, git reset --hard, git push --force, curl pipe-to-bash, etc.) before they execute. A Stop hook can force a verification step before the agent claims completion. These do not make YOLO mode 'safe' in the absolute sense — a clever agent can still find paths around a hook — but they raise the bar enough that the failure cases become rare.
What is the worst that can happen?
Real cases from the community: rm-rf of the wrong directory because the agent confused the working directory; `git push --force` to main on the wrong remote; committing a `.env` file with production credentials; running a 30-second curl that turned into a 4-hour API bill; deleting a database table while debugging a migration script. None of these are hypothetical. They are the reason the flag has 'dangerously' in its name.

Related topics