Guide · Claude Code for teams

How do you skip permissions in Claude Code safely?

Skip them only where a mistake cannot spread: in a container or VM as a non-root user, on a clean git tree or in its own worktree, with no production credentials in reach and deny rules for what must never run. On your own machine, auto mode or allow rules cut the prompts and keep a check in place. For a team, keep provider keys off the laptop and put a spend limit on each person.

What does --dangerously-skip-permissions turn off?

The flag starts Claude Code in bypassPermissions mode, the same as claude --permission-mode bypassPermissions. Every tool call runs without asking, including writes to protected paths such as .git and .claude.

Allow rules have no effect in this mode, but some checks still apply:

Deny rules still block.
An explicit ask rule still prompts.
Removing a critical path with rm still prompts.
On Linux and macOS, Claude Code refuses to start in this mode as root or under sudo, unless it recognises the sandbox it runs in.
With -p, a call that would still prompt is denied instead.

Anthropic's documentation says the mode offers no protection against prompt injection or unintended actions. It recommends the mode only in containers, VMs or dev containers without internet access.

Is there a safer way to get fewer prompts?

Yes: pick a permission mode that keeps a check. Each is set with --permission-mode:

acceptEdits runs file edits and common filesystem commands without asking.
auto has a second model, a classifier, review each action instead of you. From Claude Code 2.1.283 it is the starting mode for interactive terminal sessions.
dontAsk runs only pre-approved tools and denies anything that would prompt, which suits locked-down CI.

Allow rules in settings.json approve the commands you trust in any of these modes. Anthropic says auto mode reduces prompts but does not guarantee safety. Where something must never happen, a deny rule is the hard guarantee.

Where is it safe to skip permissions?

With the prompts off, nothing stops a bad edit as it happens. Before you start:

Isolate it. Use a container, VM or dev container, as a non-root user. Anthropic's dev container configuration runs Claude Code that way.
Commit or stash first. On a clean tree, git diff is the complete record of what it did, and git checkout . is the whole undo.
Give a long job its own worktree with git worktree add ../job my-branch, so it cannot touch what you are editing.
Start it in the directory you mean. It works from wherever the terminal is, and it will not ask again.
Deny what must never run. Deny rules hold in every mode, this one included.

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(git push *)"]
  }
}

Good to know: a Read deny rule covers Claude's file tools and commands like cat, but not a script that opens the file itself. A Bash rule does not match a program called by its path or inside sh -c. Where the line must hold, Anthropic pairs the rules with its sandbox.

What limits the damage is how much the session can reach, not how often it asks.

What changes when a whole team skips permissions?

A session with no prompts can read whatever its machine holds. Through Selan, a laptop holds no provider key: selan login leaves one revocable Selan session token, and selan claude drops an ANTHROPIC_API_KEY exported in the shell. How that works is in Claude Code without API keys.

seland is Selan's CLI under a second name. It runs selan claude --dangerously-skip-permissions, first printing the directory it is about to work in and waiting for one enter. It adds only Claude Code's own flag, so an organisation that sets permissions.disableBypassPermissionsMode to "disable" in Anthropic's managed settings blocks it too.

seland codex turns off both Codex's approval prompts and its sandbox. seland codex -s workspace-write keeps the sandbox and turns off only the prompts. See seland and seland codex.

How do you skip permissions in CI?

In CI the enter is skipped, because nobody is there to press it. An owner mints an API token, and the job carries it as SELAN_TOKEN. Nothing is written to disk, and the token spends as itself, under an address like ci-nightly@tokens.selan.ai.

- run: curl -fsSL https://claude.ai/install.sh | bash
- run: curl -fsSL https://dl.selan.ai/install.sh | sh
- run: seland claude -p "update every dependency with a patch release, run the tests, open a PR"
  env:
    SELAN_TOKEN: ${{ secrets.SELAN_TOKEN }}

Scope the runner as you would any other job: a runner with no production credentials cannot reach production, whatever it is asked to do. The details are in Running unattended, and the credential choices for a workflow in Claude Code in GitHub Actions.

What stops a runaway session?

A spend limit per person, by day, week or month in UTC. It binds the moment it is reached and counts every key in the company. It stops only what is billed per token, so a Claude seat keeps serving within its own 5-hour and weekly windows. How a limit is set is on the spend page.

With secret scanning on, every request body is swept with gitleaks' rules. A match is replaced before it goes upstream, including a secret the session read from a file. See Hiding secrets.

Good to know: scanning keeps a secret from the model provider. It does not stop a shell command from sending a file somewhere else. Deny rules and a network-isolated container do that.

Start for free

Free for up to three seats, and the Free plan needs no card.

The short version

--dangerously-skip-permissions runs every tool call without asking; deny rules, ask rules and critical rm prompts still apply.
Run it in a container or VM as a non-root user, on a clean tree or its own worktree, with no production credentials.
For fewer prompts on your own machine, use acceptEdits, auto mode or allow rules instead.
Through Selan, the laptop holds no provider key, CI jobs carry their own token, and a spend limit caps each person.

Claude Code's modes and rules are as Anthropic's permission-modes and permissions documentation (code.claude.com/docs/en/permission-modes and /permissions) stated them on 25 October 2026. They change: check the date before relying on one. What Selan does is as its CLI and docs stated it on that date.