Why I Don't Use --dangerously-skip-permissions in Production

The --dangerously-skip-permissions flag in Claude Code disables every approval prompt. Once you pass it, the agent can write files, run shell commands, install packages, and hit the network without ever pausing to ask. Most tutorials recommend it for speed. I run Claude Code in production for paying clients, and I do not use it. The name of the flag is doing some of the work for you. Anthropic is telling you something. At Formaum, the flag stays off in client work. The whole value of Claude Code is that it shows you what it's about to do before doing it.

What the flag actually does

Claude Code ships with a permission layer. When the agent wants to write a file, run a bash command, push code, or call a tool with side effects, it stops and shows you exactly what it is about to do. You approve, deny, or approve-once-per-session. That is the whole product. The transparency is the value.

--dangerously-skip-permissions turns that off. Every action runs immediately. File writes, rm, npm install, force pushes, curl calls to anywhere on the internet. No prompt, no preview, no undo.

Why most tutorials recommend it

Speed. Approving every step gets tedious, especially when you are batching a refactor across forty files. Skip the prompts and Claude runs end to end. CI pipelines need it because nobody is sitting there clicking approve. Bulk lint fixes finish in one pass instead of forty. For solo experimentation on a throwaway repo, the flag does what it says on the tin.

The pitch is real. The risk profile is what gets buried.

Why I do not use it in production

If you are learning Claude Code on a toy repo, fine. If you are running it against client production code, no. Here is the math.

The agent is good. It is not perfect. It hallucinates file paths. It picks the wrong branch sometimes. It interprets vague instructions the way a junior dev would interpret them after one coffee. In a permission-on session, those mistakes show up as a prompt I can read and reject. In a permission-off session, those mistakes show up as a git diff I have to clean up, or a force push I have to recover from, or a deleted file that was not in version control yet.

The eesel AI study found 32% of developers using the flag hit at least one unintended file modification. 9% reported data loss. There is a public December 2025 case of a user whose home directory was wiped by an rm -rf with an unexpected path expansion. None of those people thought it would happen to them. I do not want that conversation with a client.

Speed is not worth a force-push to main.

The cost of an unwatched edit

The hidden cost is not the disaster scenario. It is the learning loop.

Every approval prompt is a chance to see what the agent is thinking. I catch the wrong file path before it writes. I catch the slightly-off bash command before it runs. I catch the missing flag, the wrong env var, the migration that was going to run against the wrong database. Those catches are how I get better at prompting the agent and how I learn what it gets wrong.

Turn the prompts off and you lose that signal. The agent finishes the task. You ship. A week later something breaks and you have no idea which of the forty silent edits caused it because you never looked at them.

That is the bigger long-term cost. Not the catastrophic rm. The slow drift of code you did not review going into client repos.

The alternatives are better than the flag

Claude Code has a permission system specifically so you do not have to nuke it. The tools I actually use:

Per-tool allowlist in .claude/settings.json. Pre-approve the safe stuff. Read, Grep, Glob, basic git status, ls. The agent runs those without asking. Anything with side effects still prompts.
Scoped bash patterns. Allow npm test, npm run lint, git status. Block everything else by default. The prompts only fire when the agent wants to do something that was not on the list.
Plan mode. Let the agent draft the full plan before writing anything. Review the plan. Then execute with normal permissions.
Auto-accept for edits, not for bash. File edits inside the project are usually safe. Shell commands are where the damage happens. Splitting those two is a different risk profile than turning everything off.

Maybe ten minutes to set up the first allowlist. After that the friction is gone for the common case and the brakes are still on for the uncommon one.

When the flag IS okay

I am not saying nobody should ever pass it. Three cases where the flag is fine:

Sandboxed learning. Throwaway repo, fresh container, nothing of value mounted. Break it, delete the container, start over. That is how you learn what the agent does.
Locked-down CI. Ephemeral runner, network-restricted, scoped credentials, the job runs and the container dies. The blast radius is contained by the environment, not the flag.
Container with no host access. Docker, no volume mounts to your real filesystem, no production credentials, no .env with real keys. Same logic. The container is the safety, not the prompt.

Notice the pattern. In every safe case, the safety comes from isolation, not from the flag itself. The flag is only acceptable when something else is doing the job the flag turned off.

The pattern I actually use in client work

For paying client repos I run Claude Code with permissions on, with a project-level .claude/settings.json that pre-approves the read-only and test-runner tools. The agent moves fast on safe stuff and pauses on anything that can break the repo or push to a remote. I read every bash prompt before approving. I review the diff before approving the write. It is not slower than YOLO mode by much, and the edits that land in the repo are edits I have seen.

That is the whole point of a code agent that shows its work. If you turn the work off, you are paying for an autocomplete with shell access.

FAQ

Run on a stack that's holding you back?

Book a 45-minute discovery call. I'll map what moves, what stays, and what makes sense for your operation.

Book a call

Frequently Asked Questions

Is --dangerously-skip-permissions safe if I am working in my own personal repo?

It is safer than in a client repo, but it is not safe. The flag still gives the agent unrestricted shell access on your machine. An rm -rf with a wrong path expansion can wipe directories outside your project. If you want speed on personal work, use a settings.json allowlist instead. Reserve the flag for sandboxed containers.

Does the flag work in CI pipelines?

Yes, and CI is the one case where it is genuinely useful. CI runners are ephemeral, network-scoped, and isolated from your real filesystem. The container is doing the safety job. Just make sure the runner does not have production credentials, write access to main, or unrestricted network egress.

What goes in a Claude Code allowlist?

Start with read-only tools: Read, Grep, Glob, ls, git status, git diff. Then add safe bash patterns: npm test, npm run lint, npm run build. Keep file writes and arbitrary bash on prompt. The goal is to remove friction for the safe 80% of actions, not all of them.

What is the real risk if I just use the flag once?

The two real risks are an unexpected destructive command (rm, force push, dropped database) and silent edits you never review going into the repo. The first is the disaster scenario. The second is the slow erosion of code quality because you stopped looking at the diffs. Both compound over time.

If Anthropic put the word dangerous in the flag name, why is it the default in so many tutorials?

Tutorials optimize for demo velocity. Skipping permissions makes the recording flow without interruption. That works for a five-minute demo. It does not work for a six-month client engagement where every silent edit goes into production. The flag name is honest. The tutorial framing is not.

Genevieve Claire

Founder, Formaum — Claude Code Expert & Full-Stack AI Engineer

Builds bespoke AI automation systems for multi-location operations. Previously EA Sports FIFA ($7B franchise) and Film/TV VFX on Skyfall, Avengers, Game of Thrones. Based in Vancouver, BC.