Claude Code dangerously skip permissions refers to the --dangerously-skip-permissions flag, which starts Claude Code in bypassPermissions mode: every tool call runs immediately, with no prompt before a command, a file edit or a web request. Anthropic's documentation says to use it only in isolated containers or virtual machines without internet access, and warns that the mode offers no protection against prompt injection. Deny rules still apply, so a well-written deny list is the last line of defense. For most teams, allow rules, the sandbox or auto mode remove the same prompts with far less risk.
What Claude Code dangerously skip permissions does
Claude Code normally asks before it runs a shell command, edits a file or fetches a URL, unless a rule already approves that action. The flag turns those prompts off. In the docs' own words, it disables permission prompts and safety checks so tool calls execute immediately, including writes to protected paths.
A few things still hold. Deny rules block in every mode. Explicit ask rules still prompt. Removals of critical paths with rm or rmdir still prompt or are refused. Allow rules have no effect, because everything is already allowed. On Linux and macOS, Claude Code refuses to start in this mode as root or under sudo, with the message that the flag cannot be used with root privileges for security reasons, unless it detects a recognized sandbox.
You can only enable the mode at launch: with the flag, with claude --permission-mode bypassPermissions, or by setting the default mode in settings. The first interactive launch shows a warning dialog, and accepting it records that choice in your user settings so it does not appear again.
Where it sits among the permission modes
Claude Code has six permission modes, and bypass is the one at the far end. Default mode runs reads only and asks for everything else. Accept edits mode also runs file edits and common filesystem commands inside the working directories. Plan mode keeps edits blocked until you approve a plan. Auto mode runs everything but has a classifier model review each action first. Don't ask mode runs only pre-approved tools and denies anything that would prompt, which suits locked-down scripts. Bypass permissions runs everything, and Anthropic's table lists it as for isolated containers and VMs only.
The useful comparison is with auto mode. Both remove prompts. Only auto mode keeps a reviewer in front of each action. If prompt fatigue is the problem, auto mode solves it without taking the check away.
What can go wrong
The risk is not that Claude Code does something reckless on its own. It is that something Claude reads tells it what to do. A README, an issue, a web page or an MCP tool response can carry hidden instructions. With prompts on, a strange curl command or an edit to a config file stops and waits for you. With prompts off, it runs. That is exactly the pattern behind an MCP tool poisoning attack, where a tool description quietly redirects the agent.
Anything the session can reach is in scope: source code, .env files, SSH keys, cloud credentials in the home folder, and every MCP server the project loads. A project-level .mcp.json file arrives with the repository, so a session in bypass mode can start servers nobody on the team reviewed. Our guide to Claude Code security risks covers the documented cases where repository files triggered actions before a trust prompt.
When Anthropic says skipping permissions is acceptable
The permission modes page gives one answer: isolated environments like containers, VMs or dev containers without internet access, where Claude Code cannot damage the host. For unattended runs it recommends a container, VM or sandbox runtime, run as a non-root user.
The dev container guide is specific about the limits. Because the container runs Claude Code as a non-root user and confines commands to the container, the flag is workable for unattended operation. But Claude can still modify any file in the bind-mounted workspace, which appears directly on the host, and reach anything the container's network policy allows. The guide also warns that a dev container does not stop a malicious project from exfiltrating anything inside the container, including the Claude Code credentials stored in ~/.claude. Its advice: use trusted repositories only, avoid mounting host secrets such as ~/.ssh, prefer short-lived tokens, and restrict outbound traffic with a firewall. Anthropic's reference container ships an init-firewall.sh script for that.
Safer ways to get fewer prompts
Allow rules for the commands you trust
Permission rules in settings approve specific actions without a prompt. Bash(npm run *) approves any npm script, WebFetch(domain:github.com) approves fetches to one domain, and mcp__github__* approves every tool from one MCP server. Rules are evaluated deny first, then ask, then allow, so a broad deny such as Read(./.env) cannot be undone by a narrower allow.
The Bash sandbox
Setting sandbox.enabled runs Bash commands in an operating-system sandbox on macOS, Linux and WSL2, with filesystem and network limits you choose. With sandbox.autoAllowBashIfSandboxed, sandboxed commands run without a prompt, so you keep speed while the sandbox holds the boundary. sandbox.failIfUnavailable refuses to start rather than running unsandboxed.
Auto mode
For long tasks, auto mode removes most prompts and keeps a classifier between Claude and each action. It is the documented middle ground between default mode and bypass.
A safer setup for unattended runs
Some jobs genuinely need a session that runs without a person watching: a nightly refactor, a batch of test fixes, a CI step. If you go that route, build the box around the session before you remove the prompts. Every item below comes from Anthropic's own guidance for containers and permissions.
Run Claude Code in a container or VM as a non-root user, since the CLI refuses the flag as root anyway. Restrict outbound traffic to the domains the job needs, as the reference container's firewall script does. Do not mount ~/.ssh, cloud credential files or other host secrets into the container; give the session a repository-scoped or short-lived token instead. Keep deny rules for secret files and network tools in managed settings, because deny rules still apply in bypass mode. Use only repositories you trust, since a project's own files and MCP servers are the most likely source of injected instructions.
Then treat the output like a pull request from a new contributor. Claude can modify any file in the bind-mounted workspace, and those changes appear directly on the host, so review the diff before anything is merged or deployed. If something looks wrong, the container can be thrown away; the workspace changes cannot be undone as easily.
How to turn Claude Code dangerously skip permissions off for a team
Set permissions.disableBypassPermissionsMode to "disable" in managed settings, and nobody on a managed machine can start a session in bypass mode. Where that setting comes from matters. The dev container guide notes that a managed settings file copied in by a Dockerfile can be changed by anyone with write access to the repository. For policy developers cannot edit away, deliver it through server-managed settings or your MDM.
Managed settings are also where to put organization-wide deny rules, such as reads of .env files and calls to curl, so they hold in every mode, bypass included. Then check what each machine actually loads: the MCP security checklist lists the 12 checks to run on every server those sessions can reach.
Next step: see what a session could reach before anyone skips a prompt
Claude Code dangerously skip permissions is only as safe as the environment around it, and that includes every MCP server the session loads. The MCP security scanner lists those servers across your machines and repositories and scores each one, so you know what an unprompted session could touch.