The --dangerously-skip-permissions flag in Claude Code removes every permission check. 

No prompts before file edits. No confirmation before bash commands. No approval before network calls. No pause before MCP tool execution. Claude runs until the task is done or something breaks.

Anthropic put “dangerously” in the name on purpose. Their documentation recommends using it only inside isolated environments (containers, VMs, devcontainers) where Claude cannot damage the host system. 

Nicholas Carlini, a researcher on Anthropic’s Safeguards team, ran 16 parallel Claude instances with this flag while building a Rust-based C compiler. 

His note: “Run this in a container, not your actual machine.”

After using this flag across 3 CI pipelines and 2 containerized dev setups (and one near-disaster on bare metal that I will describe below), here is the complete breakdown: what it does, what it does not disable, when it is safe, when it is not, and why the allowedTools alternative is better for 90% of use cases.

What the Flag Actually Does

By default, Claude Code asks permission before every action: writing a file, running a shell command, reading a directory, calling an MCP tool. You approve or deny each one.

That permission loop is your last line of defense against Claude doing something unintended.

--dangerously-skip-permissions removes all of it.

Claude runs fully autonomously. No prompts. No pauses. Every file edit, bash command, network operation, and MCP tool call executes immediately when Claude decides it is needed.

You can also set this permanently in your settings:

For headless runs in CI/CD pipelines, the typical invocation pairs the -p flag (non-interactive mode) with the bypass:

That command runs Claude without a terminal UI, skips all permissions, and outputs structured JSON for pipeline consumption.

What It Does NOT Disable

This is the part most articles skip. The flag is not a universal override. Three safety mechanisms survive it:

Explicit deny rules still block. If you configure a deny rule (e.g., “never run rm -rf“), that rule still fires even in bypass mode. Deny rules and blocking PreToolUse hooks operate at a layer above the permission system.

Organization-controlled MCP connectors still require approval. If your organization manages MCP servers with mandatory user-interaction requirements, those prompts still appear.

MCP tools marked as requiring user interaction still pause. If a third-party MCP tool declares that it needs human confirmation (a payment tool, a deployment trigger), the flag does not override that declaration.

The mental model: --dangerously-skip-permissions removes Claude’s self-imposed permission prompts. It does not remove externally imposed constraints. If you have set up deny rules and hooks, those still protect you. If you have not, nothing does.

How It Differs from Auto-Accept Mode

This distinction confuses most users. They are not the same thing.

Feature	Auto-Accept (Shift+Tab)	–dangerously-skip-permissions
How to activate	Press Shift+Tab in the Claude Code UI	CLI flag or settings.json
What it does	Auto-approves prompts as they appear	Removes prompts entirely
Persists across sessions?	No (session-only)	Yes (if set in settings.json)
Works in headless/CI mode?	No (requires UI)	Yes
Deny rules still apply?	Yes	Yes
Intended use	Interactive sessions where you are watching	Unattended pipelines and containerized runs

Auto-Accept is the “I am watching but I do not want to click approve 50 times” mode. The flag is the “nobody is watching and the environment is isolated” mode. Using the flag when you should be using Auto-Accept is where most accidents happen.

When the Flag Is Safe to Use

The decision comes down to one question: what is the blast radius if Claude makes the worst reasonable mistake?

If the answer is “a disposable container that I rebuild in 30 seconds,” the flag is safe. If the answer is “my development environment with uncommitted work and production credentials,” the flag is not safe.

Safe: inside a Docker container with no credentials and restricted network.

This is the intended use case. Anthropic ships reference devcontainer configurations with built-in firewall rules for exactly this purpose. Inside a container with no SSH keys, no cloud credentials, no access to the host filesystem, and no external network, the permission prompts add friction without adding safety. The container boundary is already doing the security work.

Safe: CI/CD pipelines on disposable runners.

Automated pipelines cannot stop and wait for a human to click approve. There is nobody at the terminal. A GitHub Actions runner, a GitLab CI job, or an AWS CodeBuild container that spins up, runs Claude, and gets destroyed is the right environment for this flag.

Safe: isolated git worktrees with everything committed.

If you create a fresh worktree, commit or stash all work, and run Claude with the flag on a bounded task, git is your rollback safety net. If Claude makes a mess, git checkout . undoes everything. The blast radius is zero because nothing uncommitted can be lost.

Not safe: your main development machine with credentials loaded.

I learned this one directly. In my second month using Claude Code, I ran the flag on bare metal to speed up a large refactoring task.

Claude decided that a config file was outdated, deleted it, and replaced it with a generated version that pointed to a staging database instead of development. 

The next 4 test runs wrote test data to staging. I caught it after 20 minutes, but the cleanup took 2 hours. The flag did exactly what it promised: it let Claude run without asking. The problem was that my machine had access to things Claude should not have been touching.

After that incident, I set a personal rule: the flag only runs inside Docker or on a CI runner. No exceptions. Not even for “quick” tasks.

The Better Alternative: allowedTools Configuration

For most developers, allowedTools gives you the speed of bypassed permissions with the safety of selective control. Instead of removing all prompts, you specify exactly which tool categories Claude can use without asking.

In your ~/.claude.json:

This configuration lets Claude read files, search content, and list directories without prompting. It still asks before writing files (Edit), running commands (Bash), or calling MCP tools. You keep the speed on safe operations and the guardrails on dangerous ones.

For a research phase where Claude is analyzing a codebase:

Now Claude can also run git log and git diff without prompting, but any other bash command still requires approval. This is the principle of least privilege applied to AI agent permissions.

The allowedTools configuration persists across sessions, is visible in a config file you can audit and version-control, and provides consistent behavior without the all-or-nothing risk of the bypass flag.

I use this approach for 90% of my Claude Code work. The flag gets reserved for Docker and CI only.

The Safety Checklist Before You Use the Flag

If you decide the flag is appropriate for your situation, run through this before every session:

1. Is everything committed? Run git status. If you have uncommitted changes, commit or stash them first. Git is your rollback mechanism.
   
2. Are credentials isolated? Check for SSH keys, cloud provider credentials, API tokens, and database connection strings. If they are accessible from the environment where Claude will run, they are accessible to Claude.
   
3. Is the network restricted? If Claude has outbound internet access, it can make HTTP requests, install packages, and reach external services. Restrict the network unless outbound access is explicitly needed for the task.
   
4. Is the task bounded? “Fix all lint errors in /src” is bounded. “Refactor the entire project to improve performance” is not. Unbounded tasks with the flag are how environments get destroyed.
   
5. Is the environment disposable? If the answer is no, use allowedTools instead. The flag belongs in environments you can rebuild from scratch without losing anything.
   

FAQs

What does –dangerously-skip-permissions actually do?

It removes all interactive permission prompts in Claude Code. File edits, bash commands, network operations, and MCP tool calls execute immediately without human approval. Deny rules and externally imposed constraints still apply.

Is it the same as Auto-Accept mode?

No. Auto-Accept (Shift+Tab) auto-approves prompts in the UI during a single session. The flag removes prompts entirely and works in headless/CI mode. Auto-Accept is for interactive use. The flag is for unattended automation.

Can Claude delete files with this flag enabled?

Yes. Claude can execute any bash command including rm -rf, git push --force, and anything else your user account has access to. Unless you have configured explicit deny rules, nothing prevents destructive operations.

Should I use this flag for everyday development?

No. Use allowedTools to selectively bypass prompts for safe operations (reading, searching) while keeping approval for dangerous ones (writing, executing commands). Reserve the flag for containerized environments and CI pipelines.

Does Anthropic recommend using this flag?

Anthropic recommends it only inside isolated environments (containers, VMs, devcontainers). They ship reference devcontainer configurations for this purpose. Their own researchers use it inside containers, not on bare metal.

What is the safest way to use it?

Inside a Docker container with no credentials, restricted network access, and a committed git state. Combine with -p for headless mode and --output-format stream-json for pipeline integration. Treat the container as disposable. Rebuild it after every session if needed.