Claude Code --dangerously-skip-permissions: When It's Safe, and What to Use Instead

Leave Claude Code running on a real task and come back an hour later, and there's a good chance you'll find it stopped four minutes in, waiting for you to approve npm test.

That's the permission system doing its job. By default Claude Code asks before running shell commands and before editing files, which is exactly right when you're watching and exactly wrong when you're not. The temptation is to switch it all off. There's even a flag for that, and its name — --dangerously-skip-permissions — tells you what Anthropic thinks of doing it casually.

There's a better middle ground, and a clear answer to when the flag is actually fine.

The permission modes

Claude Code has several modes that decide what needs your approval. From Anthropic's documentation:

Mode	What it does
`default` (Manual)	Asks the first time each tool is used
`acceptEdits`	Auto-accepts file edits and common filesystem commands in the working directory
`plan`	Reads and explores, but doesn't edit your source files
`auto`	Approves actions with background safety checks that they match your request
`dontAsk`	Never prompts — anything not pre-approved is denied
`bypassPermissions`	Skips prompts (apart from a small set of protected actions)

--dangerously-skip-permissions starts a session in bypassPermissions mode. Anthropic's guidance on it is direct: only use it in isolated environments, such as containers or VMs, where Claude Code can't cause damage.

The middle ground: allow and deny rules

Most unattended stalls come from a handful of commands a project runs constantly: the test runner, the linter, the build, the package manager. You don't need to bypass everything to stop those prompts. You can pre-approve them.

Rules live in .claude/settings.json (shared with your team) or .claude/settings.local.json (just you):

{
  "permissions": {
    "allow": [
      "Bash(npm run test *)",
      "Bash(npm run lint)",
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(rm -rf *)",
      "Read(./.env)"
    ]
  }
}

A few details matter:

Deny beats allow. A broad deny rule blocks a call even when a narrower allow rule also matches. You can't carve an exception out of a deny.
Rules understand shell operators. Allowing Bash(npm run test *) does not allow npm run test && curl something. Each part of a compound command has to match on its own.
Where the * goes matters. Bash(git log *) allows git log commands. Bash(git *) allows every git command, including push and reset --hard.
Command-pattern rules are not a security boundary. Anthropic's docs are candid that rules which try to constrain arguments are fragile — the same effect can often be reached by a different spelling. Deny rules keep an honest agent out of trouble; they don't contain a determined one.

Combine acceptEdits mode with a good allow list and most unattended sessions will run to completion without a single prompt, while pushes, deletions, and anything unusual still wait for you.

When skipping prompts entirely is reasonable

bypassPermissions is the right choice more often than its name suggests — but only when the environment is the safety boundary instead of the prompts. Before you use it, all of these should be true:

It's not your laptop. Your laptop has your SSH keys, browser sessions, cloud credentials, password manager, and every other project you've ever cloned. An agent with unrestricted shell access there can reach all of it.
The agent runs as a non-root user. No sudo. It can break the project, not the machine.
The filesystem is scoped. It can see this project and nothing else — no host filesystem, no Docker socket.
Resources are limited. Enforced CPU, memory, and process limits, so a runaway loop or fork bomb hits a ceiling instead of taking the host down.
Credentials are minimal. The environment holds only the secrets this project needs, and ideally scoped ones: a database user for this database, a deploy token for this repository.
Work is recoverable. Code is in git and pushed often. The database is backed up, and you know how to restore it.
Production is out of reach. The agent works against a development database, not the one your customers' data lives in. (We cover why at length in How to Stop an AI Agent From Deleting Your Production Database.)

If all seven hold, the worst case is "the agent made a mess of a disposable environment and I roll back." That's an acceptable worst case. If any of them fails, the worst case is much worse, and a flag is doing a job the infrastructure should be doing.

Sandboxing and hooks

Two more tools sit between "ask every time" and "never ask":

Sandboxing. Claude Code can run shell commands inside an OS-level sandbox with filesystem and network restrictions that don't depend on how a command is spelled. Where the sandbox is available, it's a meaningfully stronger boundary than command-pattern rules.
Hooks. A PreToolUse hook runs your own script before a tool call and can block it. That's the place for rules that must always hold — "never run a command containing DROP DATABASE" — because CLAUDE.md instructions are guidance the model reads, not enforcement.

A sensible progression

Start in default mode on a new project. Watch what the agent reaches for.
Promote the routine commands to allow rules as you approve them — the "Yes, don't ask again" option writes them for you.
Add deny rules for the handful of things that should always wait: pushing, deleting outside the project, touching secrets.
Move to acceptEdits once you trust the edit loop.
Use bypassPermissions only inside an isolated environment that meets the checklist above.

The underlying point

Permission prompts are a human standing in for isolation. They work while a human is present. The moment you want an agent to work without you, the job has to move from the prompt to the environment: a container that can't reach your machine, limits it can't exceed, credentials that can't touch production, and a project that can be restored.

Get the environment right and the permission question mostly answers itself.

EasySpawn runs Claude Code in an isolated container per workspace — non-root, with enforced CPU, memory, and process limits, no host filesystem or Docker socket, and daily database backups — so the environment carries the safety, not the prompt. See how it works or join the waitlist.