.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Sooner or later every Claude Code thread gets the same reply: "just run claude --dangerously-skip-permissions". It may be the most-searched flag in the whole CLI, and I get the appeal, because permission prompts are the biggest friction in agent work and this makes all of them disappear at once. The flag also does exactly what its name warns. Here's what it enables, where it goes wrong and the setups I use instead on any machine that matters.
What --dangerously-skip-permissions does
The flag starts the session in bypassPermissions mode, the loosest of Claude Code's six permission modes. Every action executes immediately: file edits, shell commands, network calls, plus writes to paths the other modes protect, like your .git directory, shell rc files and Claude's own settings folder. It's equivalent to claude --permission-mode bypassPermissions, and you can bake it in through permissions.defaultMode in settings.json, which I'd only ever do inside a container image.
The first interactive run shows a one-time dialog asking you to accept responsibility for what happens next; decline and the CLI exits. A couple of things survive even in this mode: explicit ask rules keep prompting, and permissions.deny rules keep blocking. An rm aimed at a critical path like / or your home directory asks a human too. Everything else is Claude's call, with no classifier and no second look.
Why the flag exists
Unattended work. A claude -p job in a pipeline, an overnight batch fixing lint across forty repos, a container that upgrades dependencies while you sleep: nobody is present to press y, so a prompt hangs the job until a timeout kills it. The official docs pair "run fully unattended inside a container" with exactly this flag, and in a -p run the handful of calls that would still prompt are denied instead of stalling the pipeline.
So the intended home is a disposable environment. The trouble starts when people run it where they live.
Risks of running without permission checks
The failure reports cluster into two groups. The first is plain destruction: a wrong rm -rf path, a git reset --hard that ate uncommitted work, a force push over a colleague's branch. Prompts exist to catch the model's occasional confident mistake, and with them off the mistake completes before you've read it. I once watched Claude misread a monorepo layout and start "cleaning up" a directory it had decided was generated output. In Manual mode that's one rejected prompt and a laugh. In bypass mode it's a restore from backup.
The second group is quieter: prompt injection and exfiltration. An agent that fetches web pages, reads issues or processes files from strangers can be steered by instructions hidden inside that content, and without a permission gate there's no human moment where the session's drift gets noticed. There's already a real advisory in this category: CVE-2026-54316 (CVSS 9.1) let attacker-controlled repository paths on huggingface.co slip past the permission prompt, because the bare hostname was pre-approved, and leak data through public download counters. Fixed in 2.1.163, and worth noticing that it hit sessions with prompts turned on. Point an agent at hostile content with every gate removed and you're relying on model judgment alone.
Two habits fall out of that. I run claude update often, since the claude-code repository tracks fixes like this in its changelog and advisories. And I keep this flag away from anything that ingests untrusted input: public issue queues, scraped pages, files I didn't produce, repos from people I don't know.
The root and sudo restriction
Try the flag as root on Linux or macOS and Claude Code refuses to start:
--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasonsThe check is skipped inside a recognized container or VM, which tells you where Anthropic expects this mode to live. People hit the refusal most often on a fresh server where the only account is root; the fix is an unprivileged user, and the guide to running Claude Code on a VPS walks through that setup. Wrapping the command in sudo to "fix" it recreates the exact situation the check exists for, so create the user instead.
--allow-dangerously-skip-permissions
There's a middle-ground flag. --allow-dangerously-skip-permissions adds bypassPermissions to the Shift+Tab mode cycle without activating it, so the session starts in your normal default and you flip into bypass for a stretch of trusted grunt work, then flip back out. This matters because of a rule that isn't obvious: you can't enter bypassPermissions from a session that wasn't launched with it enabled. Without a flag at launch, the mode never appears in the cycle at all.
Safer ways to cut permission prompts
Most people reaching for the big flag want speed on their own machine, and there are four ways to get most of that speed without removing the seatbelt.
acceptEdits mode
One Shift+Tab from Manual. File edits and everyday filesystem commands run without prompting while other shell commands still ask, which covers the bulk of interactive coding, and git diff afterward is the review step. This plus tidy git habits is what I run for 80% of my sessions; the wider mode system, plan mode included, is covered in the article on Claude Code plan mode and permission modes.
Scoped allow rules
Pre-approve the specific commands you trust in settings.json and keep prompts for the rest:
{
"permissions": {
"allow": [
"Bash(npm run test *)",
"Bash(npm run lint *)",
"Bash(git diff *)"
],
"deny": [
"Read(./.env)"
]
}
}Deny wins over allow, and deny rules keep blocking even inside bypassPermissions mode, so a deny on .env reads belongs in every project regardless of how you launch the CLI.
dontAsk mode for CI
Pipelines get their own mode. dontAsk denies anything you didn't pre-approve and never waits for input, so the job either runs within its allowance or fails fast. The docs' own example is the shape to copy:
claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"That job can run tests and read files, and nothing else executes, which is the right posture for a runner touching pull requests from outside contributors. For per-call logic on top of the static rules, Claude Code hooks can approve or block individual tool calls from a script.
Containers, VMs and disposable servers
When a task genuinely needs full autonomy, give it a machine where the worst case is boring. Anthropic ships a dev container configuration that runs Claude Code as a non-root user, which satisfies the root check and keeps the blast radius inside the container. My own preference is a throwaway VPS: spin up a small box from LumaDock's Claude Code VPS hosting (a one-click template, deployment is instant), point the agent at a cloned repo, let it run in bypass mode overnight and destroy the box once the branch is pushed. Nothing on it is precious, because the box carries no SSH keys to other servers and no credentials beyond a scoped deploy token.
That's the whole position, really. The flag is a fine tool for environments built to be lost and I use it most weeks inside boxes that get deleted by Friday. Aimed at the home directory of the laptop holding your SSH keys and password manager, it's how the horror stories start. On the machine you'd grieve for, acceptEdits plus a handful of allow rules delivers 90% of the speed with none of the cleanup.
