Claude Code YOLO Mode: Risks and Safer Setup

If permission prompts are slowing your agent down, Claude Code YOLO mode is the tempting fix. The docs call it bypassPermissions, and --dangerously-skip-permissions is its flag. I don't run it. I cut prompts with auto mode and an allowlist, and I added one guard after a CPU failure. Below: what the docs say the mode removes, and what I run instead.

Updated 2026-10-26. Docs quoted: permissions and permission modes, both fetched 2026-10-26.

What bypassPermissions removes

Per the permission modes page, bypassPermissions "disables permission prompts and safety checks so tool calls execute immediately, including writes to protected paths" such as .git and .claude. The --dangerously-skip-permissions flag is documented as equivalent to --permission-mode bypassPermissions.

The docs are blunt about where it belongs: "Only use this mode in isolated environments like containers, VMs, or dev containers without internet access, where Claude Code cannot damage your host system." And: "bypassPermissions offers no protection against prompt injection or unintended actions."

Two limits worth knowing. The docs list actions that are not auto-approved in bypassPermissions either, among them tools matched by an explicit ask rule and recognized rm and rmdir critical-path removals. They also say deny rules block "in every mode, including bypassPermissions", while allow rules "have no effect" there. That is the permission modes page as I read it; check it for exceptions, since the pages carry several.

The modes between "ask everything" and "ask nothing"

You do not have to choose between a prompt on every command and none. The permissions page lists the modes:

Abbreviated from the docs' own tables; they list exceptions for each row.

Mode	What runs without asking
`default`	Reads only
`acceptEdits`	Reads, file edits, common filesystem commands in the working directory
`plan`	Reads; no source edits
`auto`	Runs without routine prompts; a background classifier checks actions against your request
`dontAsk`	Reads in your working directories and pre-approved tools; anything that would prompt is denied
`bypassPermissions`	Everything except the actions no mode auto-approves

Rules are evaluated deny first, then ask, then allow, and the first match decides. A broad deny can't be carved out by a narrower allow. Deny rules are where a blocklist belongs.

What I run

The settings file behind my worker sessions sets defaultMode to auto. It carries 239 allow rules and zero deny and zero ask rules. About 147 of the allows are Bash(...) rules scoped to a specific command, such as one named build or test invocation. But several tools are allowed outright with no scope, including Edit, Write, Read, WebFetch and WebSearch, so those allow rules carry no path restriction. I counted that on 2026-10-26.

Don't copy that allowlist as it stands: zero deny rules is a gap, not a feature. The docs describe Read deny rules for files like .env, and I haven't written those yet. If your sessions can reach secrets, that is the first rule I'd add before widening any allow. A starting shape, using the docs' own rule syntax:

{
  "permissions": {
    "defaultMode": "auto",
    "allow": ["Bash(npm run test *)"],
    "deny": ["Read(./.env)", "Read(./secrets/**)"]
  }
}

defaultMode sets the mode sessions start in; the docs also say to check which mode your plan and editor start in.

I chose auto over bypassPermissions because the docs describe it as keeping a background check on actions while cutting routine prompts. I haven't measured how often it blocks something I would have wanted, so I can't tell you what it costs in interruptions.

The guard I added instead of a prompt

The failure was not data loss. One session fanned out around a dozen background shell commands, each using CPU, and three such sessions slowed every build on a 12-core Mac. Each command was individually ordinary.

So I added a PreToolUse hook on Bash. The docs say an exit code of 2 on PreToolUse "blocks the tool call", and that exit 0 with no output "doesn't approve" the call; it continues through the normal permission flow. My guard only has an opinion about background launches. Past a CPU-worker budget it refuses them. Foreground commands are never blocked, which is meant to keep a running build from being cut off. The full policy and the per-command override are in Claude Code hooks; I won't retell them here.

A hook deny is not a security boundary. The pages I read don't say whether a hook deny still runs under bypassPermissions, and I haven't tested it, so don't build a guard on that assumption. A deny rule is the documented way to block in every mode.

The reaper log, and what it can't tell you

A second hook runs at session end, lists the CPU-active processes the session left behind, and signals them. The log has 364 entries between 2026-09-11 and 2026-10-26, listing 892 processes in total. It records what the hook found, not that each one ended, and not whether any was doing harm: I did not mark which were wasted CPU and which were harmless. The earliest entry is 2026-09-11, so I have nothing on sessions before it.

What I did not measure

How often the guard has blocked a launch. How often auto mode stopped something it should have. Whether a deny rule or hook would have caught a real incident, because I have no logged incident beyond the CPU fan-out. If you do run bypassPermissions, the docs' own advice is a container or VM, and for background safety checks with fewer prompts, auto mode. For what belongs in rules versus a hook, see what goes in CLAUDE.md.