The flag has two blast radii, and almost everything written about it covers one. --dangerously-skip-permissions stops Claude Code asking before it edits a file or runs a command. The obvious exposure is your filesystem. The one nobody writes about is your bill: an agent that never stops to ask is also an agent that never stops spending, and agentic failures are loops.
Both are containable, and neither needs you to stop using the flag. Here is what it actually does, then the three containments that cost about a minute each.
What it does
Claude Code normally pauses before a consequential action and waits for approval. The flag turns that pause off for the whole session. It does not grant the model new abilities and it does not change the model — it removes the review step between a plan and its execution.
That is why the honest framing is not “is this flag dangerous” but what can this session reach. The same command is unremarkable in a scratch checkout and genuinely reckless in a repo with production credentials in the environment. The flag is constant; the exposure is what you control.
Containment 1 — give it its own checkout
This is the cheapest one and it is usually enough. A git worktree is a full working directory on its own branch, so an unreviewed edit lands somewhere you can throw away instead of on top of your work.
# Containment that costs one command: give the agent its own checkout.
# A worktree is a real working directory on its own branch, so a runaway
# edit is contained to a branch you can delete rather than to your repo.
git worktree add -b agent/task-123 ../repo-agent-123
cd ../repo-agent-123
claude --dangerously-skip-permissions
# When it is done, review the branch like any other, then:
git worktree remove ../repo-agent-123The review still happens — it just happens once, on a branch, instead of forty times, on a prompt. That is generally a better use of your attention than approving individual file writes, which is the actual argument for the flag rather than impatience.
Containment 2 — give it its own credential
Whatever is in the environment of that shell is reachable by the agent. The fix is not to be careful; it is to put less there. Create a credential for the agent rather than reusing the one you have everywhere, so that stopping the agent is one revocation and not a rotation of everything you own.
# A key per agent, not a key per human. Revoking one key stops one
# agent; revoking the key you use everywhere stops your whole day.
export ANTHROPIC_BASE_URL=https://api.kunavo.com
export ANTHROPIC_AUTH_TOKEN=sk-kn-... # created for this agent only
export ANTHROPIC_MODEL=claude-sonnet-4-6
export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5
claude --dangerously-skip-permissionsOn Kunavo a key is revocable on its own — revocation is checked on every authenticated request, so a revoked key stops working immediately rather than at the end of a billing period. A key can also carry its own monthly spend limit and an IP allowlist, which is what turns “one key per agent” from tidiness into a real boundary: the agent's key can be capped and pinned without touching the key you use by hand. Creating a second key costs nothing. Setup detail is on getting an API key for Claude Code.
Containment 3 — bound the spend, not just the filesystem
This is the axis the rest of the internet leaves out. Consider what an unattended agent does when it is failing rather than when it is working: it retries. Every retry is a billed round trip that produced nothing, and a coding agent's context is large, so the round trips are not cheap ones. A twenty-step task is normal; a stuck loop is not twenty steps.
What bounds that depends entirely on how you are billed. A subscription bounds it with a usage window — a real ceiling, though it arrives as a stop rather than a warning. A card on file has no natural ceiling at all. On Kunavo there are two, and the second is the one worth setting before an unattended run: billing draws down a prepaid balance, so a request can never draw more than the balance holds, and a key can carry its own monthly spend limit. The limit is checked before the request runs, so the overspend never happens rather than being noticed afterwards; past it the call is refused with a message naming the key rather than the wallet, and it resets at the start of the next calendar month. Set one on the key the agent holds and the worst case stops being “the balance” and becomes a number you chose.
The arithmetic for what a run should cost — so you can tell a normal session from a loop — is on the Claude Code pricing page, and Claude Pro and Max limits covers the subscription side of the same question.
When to use it and when not to
| Situation | Reasonable? |
|---|---|
| Disposable worktree, scoped key, no production credentials in the shell | Yes — this is what the flag is for |
| Container or VM you can discard | Yes, and better still |
| A long unattended run you will review as one diff | Yes, with the balance sized for it |
| Your main checkout with uncommitted work in it | No — commit or stash first, then use a worktree |
| A shell holding cloud or production credentials | No |
| A machine that can reach production directly | No |
The pattern in that table is that every “no” is about reach and none of them is about the flag. Fix the reach and the flag stops being the interesting variable — which is the point.
FAQ
What does --dangerously-skip-permissions do in Claude Code?
It stops Claude Code asking for approval before each action, so file edits and shell commands run without a prompt. The name is accurate rather than dramatic: the permission prompt is the only thing standing between a plan the model made and that plan executing, and the flag removes it for the whole session. It changes nothing about what the model is capable of — only about whether a human sees each step before it happens.
Is --dangerously-skip-permissions safe to use?
It is safe in proportion to what the session can reach. The flag does not make the model more capable, it removes the review step, so the real question is what an unreviewed mistake can touch: which directory the agent starts in, which credentials are in its environment, and whether the machine has production access. In a disposable checkout with a scoped key, an unreviewed mistake is a branch you delete. In your main repo with your production credentials exported, it is not. Same flag, very different exposure.
How do I run Claude Code without permission prompts safely?
Contain the three things it can reach, in this order. Give it its own checkout — a git worktree on its own branch takes one command and turns a bad edit into a deletable branch. Give it its own credential rather than the key you use everywhere, so revoking it stops one agent instead of your whole day. And do not export credentials it has no business seeing into the shell it runs in, because everything in that environment is reachable. None of this needs a container, though a container is strictly better if you have one.
Can an autonomous agent run up an unbounded API bill?
This is the axis most discussions of the flag skip. An agent that never stops to ask also never stops spending, and agentic loops fail in the expensive direction — a retry loop is many billed round trips with nothing to show. Two things bound it on Kunavo. Billing draws down a prepaid balance rather than charging a card, so the balance is a hard ceiling. And a key can carry its own monthly spend limit, checked before the request runs: past the limit the call is refused with a message naming the key rather than the wallet, and the limit resets at the start of the next calendar month. Set one on the key you hand the agent and the worst case is a number you chose.
What is the difference between skipping permissions and a permission mode?
Claude Code's permission modes let you decide in advance which categories of action need approval, which keeps a human in the loop for the risky ones and out of the loop for the routine ones. The flag is the blunt version of the same idea with everything set to allow. For unattended runs the flag is often what you want; for interactive work a mode usually is, because the friction you remove with the flag is friction that was catching real mistakes.
Does the flag work the same way through a gateway?
Yes — the flag is entirely client-side. It governs whether Claude Code asks you before acting, and has nothing to do with which endpoint serves the model. Pointing ANTHROPIC_BASE_URL at a gateway changes where requests go and what they cost, not what the agent is allowed to do locally. The one thing an endpoint changes is the second axis above: how the spend is bounded.