Claude Code --dangerously-skip-permissions: usage and limits

claude --dangerously-skip-permissions starts Claude Code in bypassPermissions mode. It removes routine approval prompts for file changes, shell commands and tool calls. Use it for a bounded task inside a disposable environment whose files, credentials and network access you have already limited. The flag itself creates no sandbox.

claude --dangerously-skip-permissions

That is the command. Before adding it to an unattended job, check what the process can reach. A missed approval on a throwaway checkout has a different cost from a missed approval on a laptop that holds production credentials.

This guide covers the command, alternatives and a concrete run-and-review workflow. We checked Anthropic's documentation on October 6, 2026. The examples describe a setup; they are not results from a live Claude Code security test.

What does dangerously-skip-permissions do?

The flag selects the same permission mode as claude --permission-mode bypassPermissions. Claude can continue working without the usual approval stops. It keeps the operating-system identity and access of the process you launched: it does not grant root privileges, invent credentials or create access to a network your environment blocks. Claude Code permission modes.

There are still exceptions. Current releases retain explicit deny rules and ask rules, checks for certain critical-path removals, and actions that require user interaction. Do not treat those exceptions as protection for arbitrary files or cloud resources. A command can harm a project without deleting a filesystem root.

In particular, bypass mode can write to .git and .claude without the protected-path prompt. Some search summaries suggest that these folders always stay protected. That is not what the current documentation says. Permissions reference.

Consider a routine request: “Fix the failing tests.” Claude might edit a test, install a package or change configuration. If the same process can also read a cloud key and call its API, a disposable local folder alone does not restrict those remote actions. Your setup must limit that access before the run begins.

Commands for interactive and unattended use

Start an interactive session

Open a terminal inside your prepared environment and run:

claude --dangerously-skip-permissions

Check the displayed permission mode before giving the task. On the first interactive launch, Claude Code can show a warning that you must accept. For a root or sudo error, use a non-root account inside the environment instead of changing the host's protections. Mode setup and root restrictions.

Run one task and capture its result

For a current Claude Code release with API-key authentication:

claude --bare -p \
  "Fix the failing unit test in this checkout. Run the relevant tests. Report changed files and failures. Do not commit or push." \
  --dangerously-skip-permissions \
  --max-turns 12 \
  --output-format json > /tmp/claude-result.json

Here, -p runs a non-interactive task, and --output-format json makes its response easier for a runner to collect. --max-turns limits the agent loop; it does not impose a wall-clock deadline on the whole job. Configure that deadline in your runner too. CLI flag reference.

--bare avoids loading the usual ambient hooks, plugins, memory and repository instructions. For Anthropic's API it needs ANTHROPIC_API_KEY; it does not use your subscription's OAuth login. Supply that key through the runner's secret settings. On older releases, check support before copying this example. Programmatic runs and bare mode.

The prompt's “Do not commit or push” describes the task. Enforce the restriction by withholding write access to the remote repository. A sentence in a prompt cannot replace a credential scope or network policy.

For more on collecting results and handling failed jobs, see our Claude Code headless guide.

Enable bypass for later in the session

The similarly named flag has a different effect:

claude --permission-mode default --allow-dangerously-skip-permissions

--allow-dangerously-skip-permissions makes bypass selectable later; it does not start in bypass. Use the terminal's Shift+Tab mode cycle to switch. If the session did not enable bypass at launch, restart with the enabling flag. CLI reference.

Auto mode vs dangerously-skip-permissions

Choose the least permissive mode that lets the task finish:

The mode names and behavior come from the permissions reference.

Auto mode uses a separate classifier to review actions such as shell commands and external tool calls. It can block an action and let Claude try another approach. It can also make mistakes. Anthropic describes it as a way to reduce approval overhead, with tradeoffs that manual review and bypass do not share. How Anthropic built auto mode.

If repetitive prompts are your main problem, start by trying auto mode where your account supports it:

claude --permission-mode auto

If your job only needs known tools, consider dontAsk with narrow allow rules. It has a useful property for automation: missing permission fails the action instead of leaving the job waiting for a person. Inspect denied actions before widening the rules.

Does Claude Code's sandbox make bypass safe?

Claude Code's built-in Bash sandbox restricts shell access to files and the network. Its auto-allow option can approve sandboxed commands without a prompt. That option is separate from auto mode's classifier. Bash sandbox configuration.

The built-in Bash sandbox does not contain the whole application. File tools, MCP servers and hooks need their own boundary, or an outer environment that contains the entire Claude Code process. A VM and a container also provide different isolation. Choose based on what code you intend to run and what failure you can tolerate. Sandbox environment comparison.

Check the retry behavior too. With bypass enabled, an unsandboxed retry can run without asking. For supported setups, the following sandbox settings prevent that retry and require the sandbox to start:

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

Review any excludedCommands entries as well; they can still run outside the Bash sandbox. For centrally enforced settings, use managed policy that the agent cannot edit. Strict sandbox settings.

A practical workflow for an unattended run

Take a small failing-test task as an example. The output you want is a patch and a test report. There is no reason for this job to hold deployment access.

1. Prepare a separate checkout

Create a fresh container or VM and copy in the repository at a known commit. Prefer a copy to a writable mount of your main working directory. A worktree helps separate changes, but does not isolate the operating system or credentials.

Install the required runtime and packages during setup. Record the starting commit and tool versions. Use a non-root account for the agent. If you start with a dev container, inspect its mounts: a writable host directory exposes those host files to edits inside the container. Anthropic's dev container guide explains the setup and its limits.

2. Give the job only the access it needs

Pass the model credential separately. If the repository is private, use read-only repository access for checkout. Keep deployment keys, your SSH agent, the Docker socket and unrelated home-directory files outside the environment.

Allow the model endpoint and the package or source hosts the task needs. Restrict other outbound access in the environment's network controls. If a dependency download fails, identify the required host before opening more destinations.

This is also where you decide which MCP servers, if any, the task needs. A database or cloud MCP connection adds remote capabilities even when the local filesystem is disposable.

3. Run a task with a clear end condition

Use the headless command above once authentication and dependencies are ready. Put the job under a runner timeout and capture its exit status, stdout and stderr. Keep the test command under your control so that the result does not depend only on the agent's summary.

Start with a small change: one failing test or one documented bug. “Clean up the entire repository” leaves too much room for edits you did not intend to review.

4. Review the actual files

After the job ends, inspect the checkout:

git status --short
git diff --stat
git diff --check
git diff
git ls-files --others --exclude-standard

The last command lists untracked files, which a plain diff misses. Inspect them too. Compare the final commit with the starting commit so an unexpected commit does not hide changes from the working-tree diff. Re-run the relevant tests from your trusted runner, then review the patch before merging it.

Export the files you need before stopping the environment. Keep credentials out of logs and artifacts. Expire the task's credentials and destroy the disposable workspace after the review material is safe.

Where Lizard Sandboxes fit

Lizard Sandboxes can provide the remote workspace for this pattern: create an environment, execute a task, collect its files and stop it. Set an explicit lifetime so a failed runner does not leave the environment running indefinitely. Start with the Sandboxes quickstart.

Check the runtime before choosing it for your threat model. Lizard's documented default uses Kubernetes pods with runc and shares the host kernel. Firecracker support has a limited rollout for selected accounts and templates; do not assume that every sandbox uses a microVM. Use the runtime your account actually provides and keep credentials scoped accordingly. See the runtime documentation.

Remote execution helps when you need a fresh workspace for each job or many jobs at once. It still needs a network policy and a review step. A sandbox with a production database token can reach that database regardless of where the sandbox runs.

Frequently asked questions

Can I use dangerously-skip-permissions by default?

Yes. For a dedicated container or VM worker, merge this into that worker user's ~/.claude/settings.json:

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

New terminal sessions then start in bypass mode. Keep this default confined to the disposable worker; for individual jobs, use the explicit launch flag. In current releases, this value does not enable bypass from a repository's .claude/settings.json or .claude/settings.local.json. Managed policy may also disable the mode. Settings scope and precedence.

Do subagents inherit bypass permissions?

Yes. In the current documented behavior, a main conversation in bypass mode makes its subagents use the same mode, overriding their own permission-mode setting. A subagent is not a separate security boundary. Subagent permissions.

Why does Claude still ask a question?

An approval prompt and a question about the task are different. Some actions require interaction even in bypass mode, and configured ask rules can still apply. Read the actual prompt before assuming the flag failed. For unattended jobs, specify the expected output and failure behavior up front.

Does the flag make Claude Code free or remove rate limits?

No. It changes permission handling. Your model provider still controls authentication, usage charges and rate limits. Repeated retries can use more tokens even when no approval prompt appears.

For daily work, try auto mode or the Bash sandbox's auto-allow option first. For unattended bypass runs, make the environment disposable, restrict what it can reach, and review the resulting files before they affect your main project.