YOLO Mode in Claude Code: When to Use --dangerously-skip-permissions (and Safer Options)

Short answer: YOLO mode in Claude Code means starting it with --dangerously-skip-permissions (the same thing as --permission-mode bypassPermissions), so it runs commands and edits files without asking you first. It’s genuinely useful for long unattended jobs, but only inside a container or a throwaway VM. For everyday work on your own laptop, the newer auto mode or the built-in Bash sandbox gets you most of the speed with a lot less risk.

*Last updated: October 31, 2026. Built from Claude Code’s official docs (permission modes, sandbox environments, dev containers, hooks), r/ClaudeCode threads, and Hacker News discussions about agents deleting files. The yolo launcher script below is the part I ran: I tested its checks on a Linux box with a stand-in for the claude command, and the real output is shown further down. I haven’t run a multi-hour YOLO session on a client project, so I won’t pretend to.*

What “YOLO mode” actually is in Claude Code

“YOLO mode” isn’t an official name. It’s what the community calls the permission mode that skips every approval prompt. Claude Code has six permission modes, and you can see the trade-off in one table:

ModeWhat runs without askingGood for
Manual (default)Reads onlySensitive work, unfamiliar code
acceptEditsReads, file edits, basic file commands like mkdir, mv, cpIterating on code you review with git diff
planReads and exploring, no source editsPlanning before a big change
autoAlmost everything, checked by a second “classifier” modelLong tasks with far fewer prompts
dontAskOnly what you pre-approved; everything else is deniedCI and scripts
bypassPermissionsEverythingContainers and VMs only. This is YOLO mode

There are three ways to start it, and they do the same thing:

claude --dangerously-skip-permissions
claude --permission-mode bypassPermissions
# or start normally but make it available in the Shift+Tab cycle:
claude --allow-dangerously-skip-permissions

A few things surprise people the first time:

  • You can’t switch into it mid-session unless you started with one of those flags. With --allow-dangerously-skip-permissions, it shows up in the Shift+Tab cycle and the status bar reads bypass permissions on when it’s active.
  • It refuses to run as root on Linux and macOS (outside a recognized sandbox). That’s on purpose: run it as a normal user inside a container.
  • You get a one-time warning dialog the first time. Accepting it writes skipDangerousModePermissionPrompt: true to ~/.claude/settings.json.
  • **A project’s .claude/settings.json can’t turn it on.** Setting "defaultMode": "bypassPermissions" there is ignored and the session starts in Manual mode. Only your user settings, a --settings file, managed settings or the flag can enable it. That’s a good thing: a repo you clone can’t YOLO you.
  • It’s not 100% prompt-free. Explicit ask rules, AskUserQuestion, and rm -rf on critical paths like your home folder or the project root still stop and ask (in the terminal, with a two-minute countdown before it auto-denies).

Why people turn on YOLO mode anyway

The honest reason is prompt fatigue. On r/ClaudeCode, a thread asking “how often do you use --dangerously-skip-permissions” drew more than a hundred replies, and the split was roughly: people who run it all day on throwaway machines and call it “the real unlock” for agentic work, people who only use it inside dev containers, and people who never do. One commenter even shared a shell function that refuses to start YOLO mode unless it’s inside a dev container. That’s basically the idea behind the script later in this post.

The pain is real. If you’re building an MVP and Claude asks “allow npm test?” for the fortieth time, you stop reading the prompts. At that point you’re approving everything anyway, just slower. YOLO mode removes the pretend safety. The question is what you put in its place.

What can actually go wrong

The horror stories are not hypothetical. On Hacker News, a thread titled “Claude CLI deleted my home directory and wiped my Mac” collected a lot of similar reports: an agent deleting a config folder outside the project while troubleshooting, and an agent wiping a repo because it decided a rewrite was easier. Another HN thread had someone describing Claude deleting a large chunk of a codebase because it couldn’t get a feature working, so it removed everything that threw errors. In the replies, another developer said Codex once removed an entire project folder including .git, and only a remote copy saved them.

The patterns behind those stories are consistent:

  1. Cleanup and “fix the build” tasks. Deletion is the fastest way to make errors go away.
  2. Paths that escape the folder. A command like rm -rf ../build or a cd in a chained command can reach outside the project.
  3. No commit before the run. With uncommitted work, git reset --hard or a rewrite destroys hours.
  4. Secrets in reach. Your ~/.ssh, cloud credentials, and .env files are readable by anything the agent runs, and with network access they can leave the machine, for example after a prompt injection in a README or web page the agent read.

None of this needs a malicious model. It only needs a confident model plus a fast loop with no checkpoint.

Safer alternatives to YOLO mode (try these first)

1. Auto mode: the “YOLO with a seatbelt” option

Auto mode is the one most people actually want. A separate classifier model reviews each risky action before it runs, and blocks things like curl | bash, force pushes, production deploys, mass deletes, git reset --hard on uncommitted work, and sending secrets to outside hosts. Reads and edits inside your project skip the check, so it isn’t slow.

According to the current docs, auto mode is the built-in starting mode for interactive terminal and VS Code sessions from Claude Code v2.1.283, and it needs a supported model (Claude Sonnet 4.6 or later, Opus 4.6 or later, and a few newer ones on the Anthropic API). Start it explicitly with:

claude --permission-mode auto

Two details worth knowing. You can tell it boundaries in plain English (“don’t push until I review”), and the classifier treats that as a block, but those boundaries can disappear when the conversation gets compacted, so put hard rules in permissions.deny instead. And if it blocks something 3 times in a row or 20 times in a session, auto mode pauses and goes back to asking you.

The docs are blunt that auto mode is a per-action check, not an isolation boundary. For a long unattended run, put it in a container too.

2. The built-in Bash sandbox with auto-allow

If you don’t want a classifier, run /sandbox and pick auto-allow. Claude Code then runs shell commands inside an OS-level sandbox (macOS, Linux and WSL2; not native Windows) that limits which paths they can write and which hosts they can reach, and stops prompting for the commands it sandboxes. Your deny rules still apply, and ask rules like Bash(git push *) still prompt.

The catch: the sandbox covers shell commands only. File edits, MCP servers and hooks run outside it. Great for everyday work, not enough for an overnight run.

3. acceptEdits plus a short allowlist

The low-tech option: acceptEdits mode (Shift+Tab once from Manual) and allow rules for the commands you run all day. This alone removes most prompts for a typical web app:

{
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(git push *)",
      "Bash(rm -rf *)"
    ]
  }
}

Save it as .claude/settings.json in the project. Deny rules block in every mode, including YOLO mode, so the deny half of this file is worth keeping even if you later go full bypass.

Claude Code YOLO mode in a dev container: the safe setup

When you really do want hands-off runs (a big refactor, a test suite to fix overnight, a batch of small tickets), the official answer is a container. Anthropic’s claude-code repository publishes an example dev container that runs Claude Code as a non-root user behind a default-deny firewall, and the docs say that setup supports --dangerously-skip-permissions for unattended work. Copy its .devcontainer/ folder into your repo, adjust the firewall allowlist for the hosts your project needs (your package registry, your API), and open the folder in the container from VS Code or Cursor.

Four rules I’d treat as non-negotiable:

  • Mount only the project. Not your home folder, not ~/.ssh, not ~/.aws. Use a short-lived or repo-scoped token if the agent must push.
  • Restrict network egress. The firewall is what stops a prompt-injected agent from sending your code or keys somewhere. The docs warn that even a dev container can’t stop a malicious project from leaking anything inside the container, including Claude Code’s own credentials in ~/.claude.
  • Commit before you start, review after. The project folder is bind-mounted, so a deletion inside the container is a deletion on your disk.
  • Only trusted repos. Don’t YOLO a random repo you just cloned. For untrusted code, use a separate VM or a cloud session.

If you don’t use Docker, the docs list two other options: the @anthropic-ai/sandbox-runtime package (srt claude), which wraps the whole Claude Code process including MCP servers and hooks (it’s a beta research preview), or a disposable cloud VM.

A launcher script that refuses unsafe YOLO runs

This is the script I wish more guides included. It’s a small wrapper you call instead of typing the flag yourself. It refuses to start YOLO mode as root, outside a container (unless you explicitly mark the machine as a throwaway VM), outside a git repo, or with uncommitted changes. It warns if host secrets are visible, moves the work to a fresh yolo/... branch, and prints exactly what changed when the session ends.

Save it as ~/bin/yolo and run chmod +x ~/bin/yolo:

#!/usr/bin/env bash
# yolo: start Claude Code with --dangerously-skip-permissions only when it's reasonably safe.
set -euo pipefail

die() { echo "yolo: $*" >&2; exit 1; }

# 1. Never as root (Claude Code refuses this anyway on Linux/macOS).
[ "$(id -u)" -ne 0 ] || die "running as root. Use a non-root user inside the container."

# 2. Only inside a container or a VM you marked as disposable.
in_box=0
[ -f /.dockerenv ] && in_box=1
[ -f /run/.containerenv ] && in_box=1
[ -n "${REMOTE_CONTAINERS:-}${CODESPACES:-}${DEVCONTAINER:-}" ] && in_box=1
[ "${YOLO_DISPOSABLE_VM:-0}" = "1" ] && in_box=1
[ "$in_box" -eq 1 ] || die "not inside a container. Open the dev container first (or set YOLO_DISPOSABLE_VM=1 on a throwaway VM)."

# 3. Must be a git repo with nothing uncommitted.
git rev-parse --is-inside-work-tree >/dev/null 2>&1 || die "not a git repository. Run 'git init' and commit first."
[ -z "$(git status --porcelain)" ] || die "uncommitted changes. Commit or stash them first."

# 4. Warn loudly if host secrets are reachable.
for p in "$HOME/.ssh" "$HOME/.aws" "$HOME/.config/gcloud" "$HOME/.kube"; do
  [ -e "$p" ] && echo "yolo: WARNING: $p is visible in this environment. Don't mount host secrets into a YOLO box." >&2
done

# 5. Work on a throwaway branch and remember where we started.
start=$(git rev-parse HEAD)
branch="yolo/$(date +%Y%m%d-%H%M%S)"
git switch -q -c "$branch"
echo "yolo: on branch $branch (started from ${start:0:7}). Ctrl+C stops the agent."

status=0
claude --dangerously-skip-permissions "$@" || status=$?

echo
echo "yolo: session ended (exit $status). Changes since start:"
git --no-pager diff --stat "$start"
git --no-pager log --oneline "$start"..HEAD || true
echo "yolo: review with 'git diff ${start:0:7}', keep with 'git switch - && git merge $branch',"
echo "      or throw away with 'git switch - && git branch -D $branch'."
exit "$status"

Here’s the real output from my test run. I used a throwaway git repo and a fake claude command that just creates and commits one file, so this shows the script’s checks working, not Claude itself:

$ yolo   # on the host
yolo: not inside a container. Open the dev container first (or set YOLO_DISPOSABLE_VM=1 on a throwaway VM).

$ echo "draft" > todo.md && YOLO_DISPOSABLE_VM=1 yolo
yolo: uncommitted changes. Commit or stash them first.

$ YOLO_DISPOSABLE_VM=1 yolo -p "add a notes file"
yolo: WARNING: /tmp/yolotest/home/.ssh is visible in this environment. Don't mount host secrets into a YOLO box.
yolo: on branch yolo/20261031-080845 (started from 97b3015). Ctrl+C stops the agent.
[fake claude] args: --dangerously-skip-permissions -p add a notes file

yolo: session ended (exit 0). Changes since start:
 notes.txt | 1 +
 1 file changed, 1 insertion(+)
ba81058 agent: add notes
yolo: review with 'git diff 97b3015', keep with 'git switch - && git merge yolo/20261031-080845',
      or throw away with 'git switch - && git branch -D yolo/20261031-080845'.

On Windows, run this inside WSL2 or the dev container, not in PowerShell. Native Windows has no built-in Bash sandbox, and the container check won’t mean anything there.

Pair the launcher with a PreToolUse hook that blocks rm -rf, git push --force and edits to .env. A hook that returns “deny” blocks the action even in YOLO mode, which makes it the one guardrail that survives the flag. My Claude Code hooks examples post has a copy-paste bash-guard.sh and a protected-files hook for exactly this. If you also use OpenAI’s Codex, the same idea works there with Codex hooks.

A prompt for unattended YOLO runs

YOLO mode makes the agent faster, not smarter. Most bad runs start with a vague prompt. This is the shape I’d use for an overnight job:

Task: make `npm test` pass on this branch. Do not change test files unless a test is clearly wrong; if so, explain why in NOTES.md.

Rules:
- Work only inside this repository. Never touch files outside it.
- Never delete a file you didn't create in this session. If something should go, list it in NOTES.md instead.
- Commit after each working step with a clear message. No force pushes, no pushes at all.
- No new dependencies without writing the reason in NOTES.md.
- If you are stuck on the same error for 3 attempts, stop and write what you tried in NOTES.md.

When done: run the full test suite, then write a 10-line summary in NOTES.md (what changed, what's risky, what I should check first).

The “stop after 3 attempts” line matters more than it looks. Without it, a stuck loop can keep spending your quota for hours. If that’s already a problem for you, see how to reduce Claude Code token usage.

YOLO mode on a budget: DeepSeek and other non-Claude models

A lot of indie devs run Claude Code against a cheaper model by pointing ANTHROPIC_BASE_URL at another provider. When I used Claude Code, I did this myself with DeepSeek, which is the cheapest option I know of for long agent loops. It’s not the smartest model, but it’s the cheapest. As of today, DeepSeek’s pricing page lists deepseek-flash at $0.30 per million cache-miss input tokens, $0.006 per million cache-hit input tokens and $1.20 per million output tokens at peak hours, with off-peak hours at half price.

The catch for this topic: auto mode only works with supported Claude models, and DeepSeek isn’t on that list. Press Shift+Tab and look for auto mode on in the status bar. If it never shows up, your choices are Manual, acceptEdits with the Bash sandbox, or YOLO mode in a container. Cheap models also make more tool-call mistakes, so the container and the “stop after 3 attempts” rule matter even more. Low cost per token doesn’t help if a loop runs all night. For the plan math on the Claude side, see Claude Code pricing.

Common mistakes with YOLO mode

  • Using it on your main laptop “just this once.” Most of the deletion stories start this way.
  • **Putting bypassPermissions in the project’s settings file** and wondering why nothing changes. It’s ignored there on purpose. Use the flag or your user settings.
  • Relying on “don’t do X” in the chat. In auto mode, a stated boundary helps until context compaction drops it. In YOLO mode, nothing checks it at all. Use deny rules and hooks.
  • **Leaving .env readable with network on.** If you’re about to launch, run through the vibe-coded app security checklist first.
  • Not reading the diff. The branch-per-run habit only works if you actually look at git diff before merging.
  • Giving it a vague cleanup task. “Clean up the repo” plus no permissions check is how folders disappear.

FAQ

What is YOLO mode in Claude Code?

It’s the nickname for bypassPermissions mode, started with claude --dangerously-skip-permissions. Claude runs tools without asking first, apart from a few things no mode auto-approves (explicit ask rules, critical-path deletes and similar).

How do I turn on YOLO mode in Claude Code?

Start a session with claude --dangerously-skip-permissions or claude --permission-mode bypassPermissions. To be able to toggle it with Shift+Tab, start with --allow-dangerously-skip-permissions. You can’t enable it from a project’s .claude/settings.json.

Is auto mode the same as YOLO mode?

No. Auto mode also skips most prompts, but a classifier model reviews risky actions and blocks things like force pushes, mass deletes and data leaving your machine. YOLO mode checks nothing. For most people, auto mode is the better default.

Can I use YOLO mode in VS Code or the desktop app?

Yes, but you have to opt in. In the VS Code extension, turn on “Allow dangerously skip permissions” in the extension settings, then pick “Bypass permissions” from the mode indicator. In the desktop app, enable the bypass toggle in settings. Cloud sessions don’t offer it at all.

Is it safe to use --dangerously-skip-permissions on Windows?

Not on the host. Run it in WSL2 inside a container or in a VM. Native Windows doesn’t support the built-in Bash sandbox, so a container is your only real boundary.

My take

YOLO mode isn’t evil. It’s a power tool with the safety guard taken off, and it belongs in a box. My default for solo work is auto mode (or acceptEdits plus an allowlist when auto mode isn’t available), with deny rules for .env and pushes. I’d only reach for --dangerously-skip-permissions inside a dev container, on a fresh branch, through a launcher like the one above that won’t start when the basics are missing. If you’re new to all of this, start with Claude Code for non-developers and add YOLO mode last, not first.

1 thought on “YOLO Mode in Claude Code: When to Use --dangerously-skip-permissions (and Safer Options)”

Leave a Comment