Claude Code --dangerously-skip-permissions: What It Does and a Safer Fast Setup
What --dangerously-skip-permissions switches off in Claude Code, what still blocks, and a faster setup that keeps guardrails. Checked 27-10-2026.
Published 27-10-2026. Last verified against Anthropic's documentation on 27-10-2026. Reviewed monthly, because Claude Code changes its permission settings often.
Quick answer
Claude dangerously skip permissions is the flag that starts Claude Code in bypassPermissions mode, where tool calls run without a prompt, including writes to protected paths. This page is for a developer or tech lead who is tired of approving every command and has to decide how much to switch off, and for the person who owns the machine that session runs on. Our advice: keep deny rules and a container in place, and treat the flag as the last step, not the first. If your real goal is fewer prompts, Anthropic's own docs point to auto mode instead. We ran none of this, so every behaviour below is what Anthropic documents, read on 27-10-2026.
How we checked the information in this article
Our method is to read the vendor documentation, write down what it says with the date and mark what we did not run. On 27-10-2026 we read Anthropic's pages on permission modes, permissions, sandboxing, dev containers and security. Our gate for this page: a claim is in only if the docs state it and we can name the setting. We tested nothing in a throwaway repo, so we mark every behaviour as not tested by us. Two things failed the gate. We dropped the exact command behind the incident we cite below, because the report itself says it was not logged. And we dropped any claim about what each mode does for network access or git push, because the docs we read do not state it per mode. Every figure below is vendor-reported and was read on 27-10-2026.
What does --dangerously-skip-permissions do?
It starts Claude Code in bypassPermissions mode, and Anthropic's docs describe that mode as one that "disables permission prompts and safety checks so tool calls execute immediately, including writes to protected paths". The flag is equivalent to claude --permission-mode bypassPermissions, and you can also set permissions.defaultMode to bypassPermissions in settings. The first time you use it, Claude Code shows a warning dialog. If you accept, it sets skipDangerousModePermissionPrompt to true in ~/.claude/settings.json, and if you decline it stops.
Three details matter in a work setting. You cannot enter the mode from a session you started without it, though a second flag, --allow-dangerously-skip-permissions, adds it to the Shift+Tab cycle without activating it. On Linux and macOS Claude Code refuses to start in this mode as root or under sudo, with the message "--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons", unless it runs inside a recognized sandbox. And an administrator can block the mode by setting permissions.disableBypassPermissionsMode to "disable" in managed settings. We would set that for any team that does not have a container standard yet. We did not run the flag.
Is YOLO mode safe?
No, and Anthropic says so in the docs: "bypassPermissions offers no protection against prompt injection or unintended actions". YOLO mode is the community name for the same flag, not a separate feature in the pages we read. The docs limit it to isolated environments such as containers, VMs and dev containers without internet access, "where Claude Code cannot damage your host system". We would not use it on a laptop that holds your SSH keys and cloud credentials, and we would not use it on a repository you did not write.
Not everything is off. Even in this mode, some actions still prompt or are denied: tools with an explicit ask rule, tools that need your input such as AskUserQuestion, recognized rm and rmdir removals of critical paths, and Bash commands flagged "Dangerous rm operation not ruled out". Deny rules still block, because "Deny rules block in every mode, including bypassPermissions". Note the reverse: "Allow rules have no effect in bypassPermissions", since nothing is asked in the first place. Plan mode changes too: in interactive terminal sessions with bypass available, Claude Code does not enforce plan mode's blocks.
For the cost of getting this wrong, one reported case. GitHub issue anthropics/claude-code#10077 describes a Linux user who says Claude Code "executed what appears to be an rm -rf command starting from root" while rebuilding a project, with project directories and source files gone and only dotfiles left. The reporter puts it at 21-10-2025. The command was not logged, the report cannot say which mode was active, and a comment on the issue states the flag was not used, while another commenter reports a similar attempt with the flag on. We cite it as one unconfirmed user report, not as proof of how the flag behaves.
For a review of how much an agent's tools can reach before you switch anything off, Agent Permission Boundary Audit costs USD 5 per its listing. The listing says it audits tool inventories, authentication models and connector scopes, and produces a privilege matrix and a hardening plan. It showed no reviews and no use count on 27-10-2026 and we have not run it. It sits with the other tools in the Claude security collection.
How do the permission modes compare?
The modes differ in what runs without asking, so pick the narrowest one that stops the prompts you actually mind. The table below is Anthropic's own wording from the permission modes page, read on 27-10-2026, and we ran none of it.
| Mode | Runs without asking | Anthropic's intended use | Writes to protected paths |
|---|---|---|---|
| default (shown as Manual) | Reads only | Reviewing every action yourself, sensitive work | Prompted |
| acceptEdits | Reads, file edits and common filesystem commands such as mkdir, touch, mv and cp | Iterating on code you are reviewing | Prompted |
| plan | Reads, plus classifier-approved commands when auto mode is available | Exploring a codebase before changing it | See the docs, depends on bypass and auto |
| auto | Everything, with background safety checks | Long tasks, reducing prompt fatigue | Routed to the classifier |
| dontAsk | File reads in your working directories and pre-approved tools, anything that would prompt is denied | Locked-down CI and scripts | Denied |
| bypassPermissions | Everything | Isolated containers and VMs only | Allowed |
Source: Anthropic's permission modes page, read on 27-10-2026 and listed under Sources below. We left out network and git push columns because the page does not state them per mode.
Our ranking follows the risk. We send almost everyone to default or acceptEdits first, because acceptEdits removes the prompts that interrupt a coding loop most and leaves shell commands on a prompt. Auto mode is where we would go next, for long tasks: Anthropic's docs recommend it over bypass for "background safety checks with far fewer permission prompts", and a separate classifier model reviews actions. It is only available when your account and model meet the requirements on that page, and a Team or Enterprise administrator can switch it off. dontAsk is the one for CI, since anything that would prompt is denied instead of hanging a job. bypassPermissions sits last, and the only thing that moves it up is a container that holds nothing you mind losing.
You switch modes in a session with Shift+Tab, and the status bar shows which one is active. bypassPermissions only appears in that cycle if you started with the flag, with --allow-dangerously-skip-permissions or with the default mode set. dontAsk never appears in the cycle and has to be set with --permission-mode dontAsk.
What do allow and deny lists do in Claude Code?
They are rules in your settings files, and the order decides everything. Anthropic's permissions page says rules are "evaluated in order: deny, then ask, then allow", and the first match wins. A broad deny rule such as Bash(aws *) blocks every matching call, even when a narrower allow rule like Bash(aws s3 ls) also matches. An allow rule cannot carve an exception out of a deny rule, and a matching ask rule still prompts.
Two limits are worth knowing before you rely on a list. First, rules that try to constrain command arguments are fragile: the docs show Bash(curl http://github.com/ *) as an example that "intends to restrict curl to GitHub URLs" but does not match every variation. For network limits that do not depend on the command text, the docs point to sandbox network isolation. Second, precedence: managed settings are highest, and no other level, including command line arguments, can override a managed permission rule. When you pick Yes, and don't ask again for a Bash command, Claude Code saves a rule to .claude/settings.local.json at the root of the git repository. That is how a personal allow list grows without you noticing, so we would read that file after a long session. Our view: write the deny rules first and the allow rules second, and keep both short.
Deny rules protect you in every mode, bypass included, which makes them the cheapest guardrail on this page. They do not cover a command the list never thought of, though. For that gap, Claude Code Security Hooks costs USD 15 per its listing and describes "secret detection, destructive command prevention", with confirmation forced for git reset --hard and git push --force. The listing does not say which hook events it uses or what it requires, it showed no reviews and no use count on 27-10-2026, and we have not run it. Our guide to agentjacking and how to protect your coding agent covers the prompt injection side.
How do you run Claude Code in a container?
Put the whole process inside a dev container, a VM or the sandbox runtime, and run it as a non-root user. Anthropic's docs list the unattended case as claude -p "" --dangerously-skip-permissions with a container, VM or the sandbox runtime as a requirement. Its dev container page says the CLI rejects the flag as root, so the container's remoteUser must be a non-root account, and that Claude Code can still change any file in the bind-mounted workspace, which appears on your host.
The same page carries the warning we would put in front of a team: with the flag on, a dev container does not stop a malicious project from exfiltrating anything accessible inside the container, "including the Claude Code credentials stored in ~/.claude". Its advice is to use dev containers only with trusted repositories, to avoid mounting host secrets such as ~/.ssh or cloud credential files and to prefer repository-scoped or short-lived tokens. The reference container in Anthropic's repository adds a firewall script that limits outbound traffic to allowed destinations, and the docs tell you to pair the flag with network restrictions. A firewall is optional for Claude Code itself, so it is easy to leave out.
The built-in Bash sandbox is a lighter option, and it is off by default. You turn it on with /sandbox or sandbox.enabled in settings, and the docs say it uses Seatbelt on macOS and bubblewrap on Linux and WSL2. Its limits matter: Read, Edit, Write, WebFetch and WebSearch run outside it and follow permission rules, and most of the machine is readable by default, "including credential files such as ~/.ssh and ~/.aws/credentials". Native Windows runs commands unsandboxed. Our walkthrough of the Claude Code sandbox goes through the setup.
For the container and its CI around it, the Claude DevOps and cloud collection lists skills for Dockerfiles and pipelines, and the Claude workflow automation collection covers scripted runs. To check an agent setup before you hand it shell access, AI Security Auditor is free per its listing, with a USD 5 Pro version, and showed 20 uses and no reviews on 27-10-2026. The listing says it maps tool permissions per MCP server and gives "Terminal tool has unrestricted shell access" as an example finding. It states that it is static analysis of configuration files and cannot detect dynamic attacks. We have not run it.
What should you check after a bypass session?
Look first at the places a bypass session is allowed to write that a normal one is not. In bypassPermissions mode, writes to protected paths are allowed. The docs list the protected folders as .git, .config/git, .vscode, .idea, .husky, .cargo, .devcontainer, .yarn, .mvn and .claude, and protected files that include .gitconfig, .gitmodules, shell configs such as .bashrc and .zshrc, .npmrc, .envrc, .mcp.json and .claude.json. The docs say the list is not complete. These are the files that run code later, so what changed in them matters more than what changed in your source.
Our routine, which is our judgment and not Anthropic's advice, has four steps. Read git status and the full diff before you commit anything. Open the protected files above and compare them with the last commit or a known-good copy. Check .claude/settings.local.json for rules that were added. And rotate any token that was inside the container. This is where we would send every team that ran the flag even once. For the diff review itself, the Claude code quality and review collection lists review skills, and our article on how skills are security scanned explains what the scan on a skill listing does and does not cover. For unattended runs that call agents on a schedule, see the Claude agents orchestration collection and our guide to Claude Code workflows.
We sell skills that load into Claude, Cursor, Codex CLI and Copilot, and we name three of ours on this page. No vendor paid to be listed.
Where to go next
Re-read Anthropic's own pages for anything that changes after 27-10-2026, starting with the permission modes page and the permissions page, because modes, flags and managed settings are renamed often. For the container route, read the dev container page and the sandboxing page in full. The incident we mention is one user report on GitHub, so read the thread yourself. All are listed under Sources below. This page contains no guarantee about safety or results, so test any setup in a throwaway repo before it touches real work. We will recheck it monthly and mark what changed.
Written by Samuel Rose, Founder of Agensi.