Claude Code YOLO mode: what --dangerously-skip-permissions really turns off (and what it doesn't)

TL;DR

• Claude Code's YOLO mode is officially called bypass permissions: claude --dangerously-skip-permissions, which is exactly claude --permission-mode bypassPermissions.
• It removes the permission prompts. It does not touch the Bash sandbox, which is a separate, OS-enforced layer (Seatbelt on macOS, bubblewrap + socat on Linux/WSL2).
• deny rules, explicit ask rules and the critical-path rm guard still fire in bypass mode.
• A repo's own .claude/settings.json cannot switch YOLO on. Only user settings, managed settings or --settings can.
• For most people, auto mode (a classifier reviews each action) is the better "YOLO, but not stupid".

Everything here was checked against Anthropic's docs at code.claude.com and claude --help from Claude Code 2.1.292 on October 7, 2026.

---

Why does "skip permissions" not mean "no guardrails"?

The first thing to internalize is that Claude Code has two independent safety layers, and they're enforced in completely different places:

Layer	Enforced by	What it gates	Does YOLO remove it?
Permission prompts	Claude Code itself, before a tool call runs	Every tool call: Bash, Edit, Write, MCP tools…	Yes
Bash sandbox	The operating system, while a command runs	Filesystem writes and network egress of shell commands and their children	No

The permission layer is a policy check in the agent's process: "is this tool call allowed, denied, or do I ask the human?" Bypass mode short-circuits the "ask" branch to "allow". Allow rules become irrelevant, because everything is allowed anyway.

The sandbox is a different beast. When it's on, Claude Code wraps each shell command in an OS-level boundary built on Anthropic's open source @anthropic-ai/sandbox-runtime:

• macOS: the built-in Seatbelt framework. Nothing to install.
• Linux and WSL2: bubblewrap for filesystem isolation and socat to relay network traffic through the sandbox proxy (plus a seccomp filter; /sandbox shows a Dependencies tab if any piece is missing).
• Native Windows: no sandbox. Use WSL2.

By default a sandboxed command can write only to the working directory, a per-user temp dir and directories you've added. Network has no direct route out: everything goes through a local proxy that checks each host against an allowlist that starts empty. That's why something like curl --noproxy '*' just fails to resolve: there's no route around the proxy.

So YOLO answers "should I ask?" and the sandbox answers "what can this process physically reach?". You can (and should) run them together.

What survives bypass mode?

Even with every prompt gone, these still apply:

• deny rules and explicit ask rules in your permission config.
• The guard against rm on critical paths.
• Questions Claude asks you directly (it's still allowed to stop and ask).
• The sandbox, if you turned it on with /sandbox or "sandbox": {"enabled": true}.

There's one sharp edge in that last point. When a command fails inside the sandbox (say, a tool that's incompatible with it, or a blocked host), Claude can retry it with a dangerouslyDisableSandbox parameter. In bypassPermissions mode, that unsandboxed retry runs without a prompt. Two ways to close the hatch:

{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false
  }
}

With that set, Claude Code ignores dangerouslyDisableSandbox entirely (the /sandbox Overrides tab calls this Strict sandbox mode). Alternatively, add an ask rule for Bash(dangerouslyDisableSandbox:true); per the docs it prompts even in bypass mode and beats a matching allow rule.

Also worth knowing: the sandbox covers shell commands only. Read/Edit/Write/WebFetch, hooks, local MCP servers and your status line command run outside it, governed only by permission rules. In bypass mode that means they're governed by… your deny rules. If you want one boundary around everything, run the whole claude process in a container or VM.

How do you actually turn it on?

Where	Full YOLO	Halfway
CLI	claude --dangerously-skip-permissions	claude --permission-mode auto or acceptEdits
settings.json	"defaultMode": "bypassPermissions"	"defaultMode": "acceptEdits"
In a session	Shift+Tab, if allowed at launch	Shift+Tab
VS Code	claudeCode.allowDangerouslySkipPermissions	mode selector
Rules	—	"allow": ["Bash(npm test)"]

The flag:

claude --dangerously-skip-permissions
# identical to:
claude --permission-mode bypassPermissions

--permission-mode takes manual (the default, spelled default in config files), acceptEdits, auto, plan, dontAsk and bypassPermissions. The first interactive run shows a warning you have to accept.

As a persistent default, in ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "bypassPermissions"
  }
}

Why can't a cloned repo flip YOLO on for you?

This is my favourite design decision in the whole permission system. defaultMode: "bypassPermissions" is honoured in user settings, managed settings and a file passed with --settings. It is ignored in a project's own .claude/settings.json and .claude/settings.local.json: Claude Code just starts in the default mode.

Think about the threat model. Project settings ship with the repo. If they could set bypass mode, then git clone evil/repo && cd repo && claude would hand an attacker an agent that runs anything without asking, and the attacker's README or issue text is right there to prompt-inject it. The rule is simple: only scopes you control can lower your guard. The same idea shows up elsewhere in the sandbox docs, where credential-masking settings are honoured only from user/managed/--settings scopes and ignored in a repo's settings.

Cloud sessions ignore bypassPermissions from settings files too, and admins can kill the mode org-wide:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Why won't --dangerously-skip-permissions run as root?

On Linux and macOS, Claude Code refuses to start in bypass mode as root or under sudo, unless it detects it's already inside a sandbox. That's the "no prompts and unlimited privilege" combination it won't sign off on. If you hit this in a container, it's the container detection that matters; on a bare host, the fix is "don't be root", not "find a workaround".

Why isn't bypass in my Shift+Tab cycle?

Shift+Tab cycles auto → default → acceptEdits → plan, then any optional modes. Bypass is only part of the cycle if the session was launched with permission to use it. To have it available without starting in it:

claude --allow-dangerously-skip-permissions

It's a nice two-step arm-then-fire design: the capability is granted at process start (a deliberate act), and only then can a keystroke reach it. A stray Shift+Tab in a normal session can never land you in YOLO.

In VS Code, claudeCode.allowDangerouslySkipPermissions plays the same "arm" role: it adds Bypass permissions to the mode selector. claudeCode.initialPermissionMode sets what new conversations start in (default, acceptEdits, plan, bypassPermissions).

Is auto mode just YOLO with extra steps?

No, and it's what I'd reach for first. In auto mode a separate classifier model reviews each action and only stops you for the risky ones. Since 2.1.283 it's the default starting mode in the terminal and VS Code on supported models.

The other halfway options compose nicely:

• acceptEdits: file edits go through, shell commands still ask.
• Allow rules: "Bash(npm test)", "Bash(git *)", "Read" in permissions.allow, or --allowedTools.
• Sandbox auto-allow: with the sandbox on, sandboxed Bash commands can run without prompts because the OS, not you, limits what they can reach. Deny rules, critical-path rm and content-scoped ask rules like Bash(git push *) still prompt.

That last combo is, for me, the sweet spot: zero prompts for npm test and friends, but a kernel-enforced fence around writes and egress.

How do I turn on YOLO per task or per workspace with AgentRQ?

Everything above is session-scoped: you decide once, at launch or with Shift+Tab, and that decision covers every tool call until you exit. If you run Claude Code unattended (scheduled jobs, long refactors while you're away), you usually want something finer: YOLO for this job, prompts for everything else. That's the gap AgentRQ fills by moving the approval decision out of the terminal and into a task.

1. Connect Claude Code to a workspace. Follow the Claude Code setup guide, which adds the workspace as an MCP server and a notification channel. Alternatively, run it through the ACP Gateway with --agent claude-acp.

2. Start Claude Code without bypass. Use the default mode or acceptEdits, for example:

claude --permission-mode acceptEdits

Avoid auto mode here, otherwise the classifier answers the permission requests before they ever reach you. Each request now shows up in the AgentRQ task (web, phone or Slack) with the command or edit it's about, and you answer one of:

• Allow Once: this call only.
• Always Allow: adds the tool to the workspace's auto-approved list, so routine calls stop asking.
• Deny: Claude Code gets a rejection and carries on with another approach.

3a. YOLO for one task. Flip the YOLO toggle on a task, or set it when you create the task. Every permission request in that task is approved automatically and Claude Code never waits, while every other task in the workspace still asks. The flag is per task and persists across agent disconnects and reconnects. Scheduled tasks, event triggers and workflow steps have the same switch, so a nightly job can run in YOLO while your interactive work stays supervised.

3b. YOLO for the whole workspace. Workspace settings has YOLO Mode (Execute All) (UI warning: "Agent will not ask for permission"). Under the hood it's a default, not a global override: the approval check reads the task's own YOLO flag, and the workspace switch decides what that flag starts as. New tasks you create in the web form open with the YOLO toggle already on (you can still switch it off per task), and tasks the agent creates for itself over the workspace MCP server inherit it. Flipping the switch doesn't rewrite tasks that already exist.

Or let a model approve and deny for you, from plain-English rules. Between "ask me every time" and "approve everything" there's a third option: an AgentRQ desktop extension that reviews each permission request before it reaches you. Extensions are trusted Node modules loaded by the AgentRQ desktop app. One registers a reviewer with ctx.hooks.add({ id, review(request) { ... } }) and is handed the pending call: the tool name, the argument preview the harness sent, and the workspace. It answers { behavior: 'deny', reason }, { behavior: 'allow' }, or nothing at all to abstain. Point review() at an external decision API such as TypeSafe's Jev, a "System One" model that returns a typed choice with calibrated probabilities and a confidence in milliseconds instead of generating text. Send the tool call as the state, and your workspace's rules in plain English ("git push is fine on feature branches, never on main", "never read anything under ~/.aws") as a Choice question over allow / deny / ask me. Then threshold it: approve only on a high-confidence allow, refuse on a confident deny, and abstain on everything else so the request lands on your phone as usual. The rules can live on a per-workspace settings tab the extension draws itself; the bundled guardrail example does exactly that with literal patterns.

The review contract is built on one asymmetry: refusing costs a tool call, approving costs whatever the tool call does. So one refusal settles a request; silence (an abstain, an exception, or a reviewer that misses its 5-second deadline) is never an allow, the request just stays in front of you; and an extension needs the decide consent level to approve, while deny consent can only refuse. The install screen starts every extension at none. Reviews only happen while the desktop app is open and signed in, so treat this as a fast first pass, not a security boundary.

Per task vs. workspace-wide, the trade-off: the workspace switch is the AgentRQ equivalent of putting bypassPermissions in your user settings: convenient, but it outlives the job you actually trusted, and it covers work you haven't seen yet. Per-task YOLO scopes the blast radius to one unit of work and expires with it. My rule: leave Execute All off, use per-task YOLO for jobs you'd happily git reset, and lean on Always Allow for boring tools (prune that list now and then). Either way, Claude Code's own layers still apply underneath:

• Keep /sandbox on, ideally with allowUnsandboxedCommands: false. AgentRQ removes the questions; the sandbox still limits what an approved command can touch.
• Start every YOLO task from a clean git tree, so any change is one git reset away.
• Read the tool call history afterwards; it lists every call, including the auto-approved ones.

FAQ

Is --dangerously-skip-permissions the same as --permission-mode bypassPermissions? Yes, exactly the same.

Does YOLO mode turn off the sandbox? No. It only skips prompts. But unsandboxed retries run without asking in bypass mode unless you set allowUnsandboxedCommands: false.

Can I put bypass mode in my repo's .claude/settings.json? You can write it, but Claude Code ignores it there. Use ~/.claude/settings.json, managed settings or --settings.

Why does it refuse to start as root? Bypass mode is blocked as root/sudo on Linux and macOS unless Claude Code detects it's already sandboxed.

Why is bypass missing from Shift+Tab? Start the session with --dangerously-skip-permissions or --allow-dangerously-skip-permissions, or set bypass in user settings.

Does the sandbox cover MCP servers and hooks? No. They run with your full access; only shell commands are sandboxed.

Can I approve Claude Code permissions from my phone? Yes. Connect it to an AgentRQ workspace and answer Allow Once, Always Allow or Deny in the task.

If you're comparing agents, here's how YOLO mode works in every coding agent, side by side.

---

So, what's your setup: full bypass inside a container, auto mode on the host, or sandbox auto-allow with a strict no-retry policy? And has the unsandboxed retry ever surprised you? Tell me in the comments.

Originally published on AgentRQ.