Claude Dangerously Skip Permissions

What the Flag Actually Turns Off

--dangerously-skip-permissions and --permission-mode bypassPermissions select the same mode. Claude can proceed with file changes, shell commands and other tool calls without the usual approval stops. The mode also permits writes to protected paths. The first interactive launch displays a responsibility warning; declining exits Claude Code. Anthropic’s bypass documentation

Think of permissions as an approval desk and isolation as the walls around the workshop. Removing the desk does not build walls. The practical benefit is an uninterrupted work session; the practical cost is losing your chance to catch a bad action before it runs.

That changes the workflow from approving individual operations to defining the environment first and reviewing the output afterward. It does not make the code correct or make hostile instructions harmless.

What It Still Does Not Bypass

The word “skip” does not mean every control disappears. These distinctions matter when a supposedly unattended run stops or refuses an action:

For the last row, the exact read setting is permissions.blockReadsOutsideWorkingDirectories: true. Recognized file-reading Bash commands can still prompt outside the permitted directories; sandbox-enforced blocks behave differently. In a noninteractive -p bypass run, calls that would still need a prompt are denied instead. Actions no mode auto-approves, outside-directory read setting

Blocking PreToolUse hooks also remain part of tool approval. There is a special exception for EndConversation: deny and ask rules do not constrain it while another tool remains available. Installed mods can override some non-managed permission decisions, so a team’s mandatory controls belong in managed policy. Administrators can prohibit bypass with "permissions": {"disableBypassPermissionsMode": "disable"}. A session started with --restricted refuses bypass mode too. Hook and rule precedence, disable-bypass setting

Protected Paths Are Writable in Bypass Mode

Do not assume .git or .claude remains behind a confirmation prompt. Protected-path writes are allowed in bypass mode. That is different from the critical-directory deletion checks above.

Anthropic’s protected-path list includes:

There are scoped exceptions within .claude, including Claude’s own worktrees, current plan files, background-session scratch space and certain memory Markdown files. In ordinary Manual and acceptEdits sessions, protected writes prompt; auto mode routes them to its classifier. A settings-file allow rule cannot preapprove these writes. Protected paths and exceptions

Four Safer Ways to Remove Interruptions

Choose the control that matches the interruption. Most developers need a more precise approval policy before they need bypass.

Use Auto Mode for General Coding Work

Start a session with claude --permission-mode auto. A classifier, a separate model reviewing proposed actions, handles routine approval decisions. For a persistent terminal default, merge "permissions": {"defaultMode": "auto"} into ~/.claude/settings.json.

Putting that value in .claude/settings.json or .claude/settings.local.json does not activate it. Auto mode also depends on supported models and organizational settings, and explicit ask rules still prompt. It reduces interruptions without guaranteeing safety. Default-mode setting, auto-mode requirements

Our Claude Code auto mode guide explains when that review model fits your workflow.

Allow Routine Work and Deny Specific Actions

Use permissions.allow for commands you have reviewed and permissions.deny for operations you want blocked. Claude Code evaluates deny before ask before allow. A broad allow cannot cancel a matching deny. Permission rules

For a trusted repository, the following example combines narrow approvals with a blocking hook. Merge it into .claude/settings.json; preserve existing keys. It deliberately starts terminal sessions in Manual mode so the listed approvals do the work. Check what the project’s test and lint scripts execute before approving them.

{
  "permissions": {
    "defaultMode": "default",
    "allow": ["Bash(npm test)", "Bash(npm run lint)"],
    "deny": ["Bash(git push *)", "Read(./.env)", "Read(./.env.*)"]
  },
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "if": "Bash(rm *)",
        "command": "echo 'Use the approved cleanup task instead.' >&2; exit 2"
      }]
    }]
  }
}

Use .claude/settings.local.json for a personal project override; add it to .gitignore if you create it yourself. Open /permissions to inspect the active rules and their source files. Settings scope

These patterns are not filesystem or network isolation. Alternate command spellings can escape a Bash pattern, and arbitrary scripts can read files indirectly despite file-tool deny rules. Keep secrets outside the environment and use sandbox enforcement where access must be impossible. Bash rule limits, file-rule limits

Use Plan Mode Before a Broad Change

Start with claude --permission-mode plan, or set "permissions": {"defaultMode": "plan"} in the project settings. Claude explores and proposes work before source edits are approved. The top-level setting "useAutoModeDuringPlan": false switches off classifier approval of planning commands, so commands beyond the built-in read-only set need your approval. Plan-mode configuration

Start a fresh plan session without bypass-enabling flags. In an interactive terminal session where bypass is available, plan mode does not enforce its usual edit and command blocks. That includes availability added by --allow-dangerously-skip-permissions, which enables later selection without immediately activating bypass. Plan mode and bypass availability

Use Hooks for Command-Specific Blocks

The example’s hooks.PreToolUse handler uses matcher: "Bash", type: "command" and if: "Bash(rm *)". When that condition matches, its shell command prints a reason and exits with status 2, blocking the tool call. It requires no separate script. The shell command is our small example using Anthropic’s documented hook fields and blocking exit status. Hook configuration, blocking exit codes

This blocks matching rm calls, not every possible way to delete a file. A team could replace it with a reviewed validator for its own deployment or cleanup commands. Keep the checks narrow enough to understand and test. Our Claude Code hooks page covers hook configuration and debugging.

Where Anthropic Says Bypass May Run

Anthropic’s common-setup table requires a container, VM or sandbox runtime, with a non-root user on Linux and macOS. Its bypass section describes isolated environments that cannot damage the host and calls out environments without internet access. The devcontainer guide provides a connected setup with restricted outbound access for Claude’s required services. Treat unrestricted networking as a separate exposure. Required isolation, devcontainer network restrictions

On Linux and macOS, launching bypass as root or through sudo is normally refused. The docs note an automatic exception inside a recognized sandbox; the documented devcontainer approach uses a non-root account. Do not solve a root error by weakening that boundary.

A Short Reference Devcontainer Setup

Use a disposable checkout of a trusted repository. With Docker, VS Code and the Dev Containers extension installed, begin with Anthropic’s reference project:

git clone https://github.com/anthropics/claude-code.git claude-code-isolated
code claude-code-isolated

1. In VS Code, run Dev Containers: Reopen in Container. The reference combines the CLI, persistent volumes and an outbound firewall. Check that remoteUser names a non-root account.
2. In the container’s terminal, run id -u and confirm it is not 0. Run claude to sign in, then exit that session.
3. In that same container terminal, run claude -p "Inspect this repository and summarize its structure. Do not change files." --dangerously-skip-permissions.
4. For your own project, copy the reference .devcontainer/ directory into a disposable checkout and adapt the Dockerfile to its toolchain. Review the workspace diff after each task.

This follows Anthropic’s reference-container workflow. The reference is a working example, not a maintained base image. Keep its outbound restrictions or supply equivalent network controls.

The mounted workspace remains writable from inside the container, and those changes reach the host. Avoid mounting ~/.ssh, cloud credential files or unrelated directories. A malicious project can still leak whatever is accessible inside, including Claude credentials. Use trusted repositories and monitor the work. Devcontainer limits

Cloud Sessions Ignore the Bypass Default

Cloud sessions silently ignore settings-file defaultMode: "bypassPermissions" and defaultMode: "dontAsk". They start in the mode shown in the cloud mode dropdown. A checked-in JSON setting cannot force a cloud session into bypass. Cloud mode behavior

Your local ~/.claude/settings.json does not travel into an Anthropic-hosted cloud session. Repository settings have their own limits too: sessions spanning several repositories do not load each repository’s permission rules and hooks. Inspect the cloud environment’s actual policy instead of assuming your terminal setup carried over. Settings in cloud sessions

Match the Mode to the Work

The highest-value change is usually removing repetitive approvals from an existing workflow. These are practical choices, ordered by where I would start:

For the CI case, claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read" is Anthropic’s documented starting point. It denies operations that would otherwise prompt. Common setups

Use our Claude Code best practices alongside whichever mode you choose. Permissions govern execution; verification governs whether the result is worth keeping.

Two Useful Tools a Team Could Build

A permission-configuration checker is the strongest opportunity. DataForSEO estimates 720 US searches per month for “claude code permissions.” That signals a discoverability problem, not proven purchase intent. A developer-platform team could build a small checker that explains settings scope, flags ignored defaultMode values and previews broad command rules before onboarding colleagues. Its first useful output is a report with suggested edits. The catch is maintaining it as Claude Code’s configuration behavior changes.

A disposable-run launcher could serve teams with repeat unattended tasks. The same demand check estimates 260 US searches per month for “claude code docker.” An MVP could validate a reviewed container template, permitted mounts, non-root execution and outbound policy, then collect the resulting diff and logs for a maintainer. Its value would be consistent setup. Its catch is that a launcher cannot make untrusted repository code safe or guarantee isolation just because Docker is present.

Both are internal tooling opportunities to validate with actual users. Neither requires turning bypass into a default on developers’ machines.

Your Monday move: choose one repetitive workflow, review its actual commands, and configure the smallest approval policy that lets it finish. Move to a disposable container only when the task needs unattended execution beyond that policy.

If your team needs that workflow built and maintained, AI production systems is where we can help.