--dangerously-skip-permissions: What It Actually Does and How to Contain It

Every engineer who has run a long agentic coding session has hit the same wall. The agent is nine steps into a refactor, it is working, and then it stops to ask whether it may edit a file. You approve. Three seconds later it asks again.

So people reach for the flag that makes it stop asking:

claude --dangerously-skip-permissions

The community calls it YOLO mode. It is genuinely useful, it is used constantly, and most of the people running it have never looked closely at what it removes. This is a look at exactly what the flag turns off, the three ways it actually goes wrong, and how to keep the speed without handing an agent your whole environment.

What the Flag Actually Does

Claude Code, like most coding agents, runs a permission check before every consequential action. Editing a file, running a shell command, calling a tool on an MCP server, reaching the network. Each of those is gated, and the gate is what produces the prompt.

--dangerously-skip-permissions removes the gate. Not some of it. All of it, for the whole session.

It is worth being precise about what that means, because a common assumption is that the flag only affects file edits. It does not. Once the gate is gone, the agent can:

• Write and delete any file the user account can write and delete, not only files inside the project
• Run any shell command with the user's full privileges
• Call any tool on any connected MCP server, including servers holding production credentials
• Reach the network, which means it can both fetch content and send data outward

The name is not marketing. Anthropic's own documentation is blunt that the flag can lead to data loss and system corruption, and recommends running it only in an isolated container without network access.

Two things matter here that people miss.

It removes the check, not the capability. The agent could always do these things. The permission prompt was the only thing standing between a proposed action and an executed one. Skipping it does not grant new power; it removes the last human review of power the agent already had.

The gate was also the audit trail. Every prompt was a record that a specific action was proposed and approved. Turn the prompt off and the decision still happens, just with nobody watching and nothing written down.

Why People Use It Anyway

It would be easy to say "never use this flag," and that advice would be ignored, because the reasons for using it are real.

Approval fatigue is the main one. A prompt every few seconds during a fifty-step task does not make anyone safer. It trains people to hit approve without reading, which is worse than no prompt at all because it manufactures the appearance of review.

Long autonomous runs are the second. The entire value of an agentic session is that it works while you do something else. An agent that blocks on question four of forty is not autonomous.

Automation is the third. In CI, a batch job, or a scheduled task there is no human to answer a prompt, so the run either skips permissions or does not run.

These are legitimate. The problem is not that people want fewer interruptions. It is that the usual way of getting them is all-or-nothing, when the actual need is narrow.

The Three Ways It Goes Wrong

Almost every incident traces back to one of these.

1. The destructive command that was technically correct. The agent decides the clean way to fix a broken migration is to drop and recreate. It is not wrong about the mechanics. It is wrong about which database it is pointed at, because the environment variable in that shell was still set from an earlier session. With permissions on, a human reads "DROP" and stops. With permissions off, it runs.

The category to watch is irreversible actions: deletions, force pushes, schema changes, sending messages, moving money. Those are the ones where a post-hoc alert has no value, because by the time it fires the thing is done.

2. Untrusted content becoming instructions. The agent reads a file, a web page, an issue comment, or a tool response, and that content contains text shaped like an instruction. This is not exotic; it is the normal consequence of a system that takes natural language as input and cannot cleanly separate data from directives.

With permissions on, the injected instruction still enters the context, but the resulting action surfaces as a prompt and looks wrong to a human. With permissions off, the chain runs unobserved. The flag does not create this problem, but it removes the only control most setups had against it.

3. Reach that nobody mapped. The agent stays in the repository. Its MCP servers do not.

This is the failure people underestimate most. A coding agent is rarely just a coding agent. It has a GitHub server, a database server, maybe Slack, maybe a cloud provider. Each was added at a different time for a different task, each carries a credential, and each credential reaches whatever it reaches inside the real system.

The agent's actual authority is the union of all of it. Not the most privileged server, the union. A read-only warehouse connection is fine. A messaging connection is fine. An agent with both can read customer records and post them into a channel, and no single permission was violated to do it.

Five Layers That Keep the Speed

The goal is not to reinstate the prompts. It is to make the blast radius small enough that skipping them is a reasonable trade. These layers stack, and the first three cost almost nothing.

Layer 1: Isolate the machine. Run the session in a container or VM that holds the repository and nothing else. No production credentials in the environment, no cloud CLI already authenticated, no SSH keys mounted, network restricted to what the task genuinely needs. This is the single highest-value control, because it caps everything downstream. Anthropic's own guidance for the flag is essentially this.

Layer 2: Deny the irreversible. Rather than approving everything one prompt at a time, pre-decide. Most coding agents support a persistent policy that allows routine operations and blocks specific dangerous ones. Allow the test runner, the linter, the build, reads across the repo. Deny destructive database commands, force pushes to protected branches, credential file access, and anything that sends outbound data. A short deny list catches the actions you would never have approved anyway, and it works during automated runs where no human is present.

Layer 3: Put a check in the execution path. A policy list is static. A pre-execution hook is code, so it can inspect the actual command and refuse it. This is where you catch the destructive command aimed at the wrong environment, because a hook can read which host the connection string points at and block anything touching production from a dev session. The important property is that it runs before execution rather than alerting after, which is the only thing that helps with irreversible actions.

Layer 4: Scope the credentials, not just the commands. Every control above governs what the agent may attempt. This one governs what succeeds. Give the agent's MCP servers their own credentials, scoped to what the workflow needs, separate from the developer's personal access. If the database server only ever reads from a replica, its credential should not be able to write to primary. Command-level controls fail open when the credential behind them is over-scoped.

Layer 5: Know what the agent can reach. You cannot scope credentials you have not enumerated. Most teams cannot produce a current list of which MCP servers are connected to which agents, who added them, or what those connections reach inside the connected system. Local MCP servers make this worse: they run as a subprocess with no port and no hostname, so they appear in no network scan and no asset inventory, and they are added in seconds without a provisioning request.

What This Looks Like at Organizational Scale

For one engineer on one laptop, layers one through four are enough.

Across an engineering organization the problem changes shape. The question stops being "is this session safe" and becomes "how many agents are running with unbounded permissions, what do they connect to, and which of those connections reach production data."

That question is not answerable from configuration. A config file records what somebody set up. The credential behind it records what can actually be reached, and the two drift apart continuously as scopes accumulate. Reviewing configuration tells you intent. Only runtime behavior tells you reach.

The practical version has three parts. Enumerate the MCP servers agents actually connect to, continuously rather than quarterly, since a point-in-time audit is stale within days. For each connection, resolve the effective access its credential holds inside the connected system, rather than what its config claims. Then score the combinations, because the risk is what one agent can reach across every server available to it in a single session.

Obsidian builds that inventory from runtime activity across connected AI platforms, maps the effective access each agent and MCP server actually holds inside your SaaS applications, and flags the toxic combinations that turn a convenient developer setup into a path from production data to an external destination. Runtime enforcement is available today for Claude and Microsoft Copilot.

The Short Version

--dangerously-skip-permissions is not reckless by itself. It is a reasonable response to a real ergonomic problem, and the people using it are not being careless.

What makes it dangerous is running it in an environment that was never scoped for it: a machine with production credentials in the environment, MCP servers nobody inventoried, and credentials broader than any single task requires. The flag does not create that exposure. It just removes the last thing that was interrupting it.

Contain the environment, deny the irreversible, check in the execution path, scope the credentials, and know what the agent can reach. Then skip the prompts.