Look, I’ll be upfront: I’ve used claude code dangerously-skip-permissions more than I probably should have. If you’re a developer working with Claude Code daily, you probably have too — or you’ve been tempted. The flag turns Claude Code from a cautious assistant that asks “may I?” before every mkdir into a fully autonomous agent that just… does things. It’s intoxicating. It’s also how people lose their home directories. (View Highlight)
In normal operation, Claude Code asks permission for everything. Every bash command, every file edit, every network request, every MCP tool interaction. The --dangerously-skip-permissions flag auto-approves all of them. No confirmation dialogs. No pause. No chance to catch a bad command before it fires.
It’s technically equivalent to --permission-mode bypassPermissions — same behaviour, different flag name:
claude —dangerously-skip-permissions “Fix all lint errors”
claude —permission-mode bypassPermissions “Fix all lint errors”
Here’s the detail most people miss: subagent inheritance. When you enable bypass mode, all subagents inherit full autonomous access. You can’t override this. The official SDK documentation spells it out clearly — subagents may have different system prompts and less constrained behaviour than your main agent, and they all get full, unsupervised system access. (View Highlight)
Before I get into the horror stories, I want to acknowledge something: the default permission system is genuinely frustrating. This isn’t developers being lazy. It’s a real workflow problem.
You type a prompt. Claude starts working. You switch to Slack, check something, maybe grab a coffee. Five minutes later you come back and Claude is just… sitting there. Waiting for you to approve a file edit. The whole task is frozen at step two because it needed your blessing to run mkdir.
This isn’t a theoretical complaint. Kyle Redelinghuys, who wrote one of the better posts on this flag, nailed it: you set Claude off on a task, walk away, and come back to find it stopped at step two because it needed permission to create a directory. He also documented a successful nine-hour autonomous session where Claude built an entire financial data analysis system from scratch. That kind of extended workflow is simply impossible when you’re approving prompts every ninety seconds. (View Highlight)
The home directory wipes
The Wolak incident (October 2025) is the one that should keep you up at night. Developer Mike Wolak was working on a firmware project in a nested directory on Ubuntu/WSL2 when Claude Code executed an rm -rf starting from root (/). His GitHub bug report (#10077) documents it in forensic detail: error logs showed thousands of “Permission denied” messages for system paths like /bin, /boot, and /etc — the command literally tried to delete everything on the machine, and only stopped where Linux file permissions wouldn’t let it. Every user-owned file was gone. Worse, the conversation log captured the command’s output but not the actual command itself, making it impossible to determine exactly what went wrong. Anthropic tagged it area:security and bug. (View Highlight)
The Reddit incident (December 2025) became the flag’s most public disaster. A user on r/ClaudeAI asked Claude to clean up packages in an old repository. Claude generated rm -rf tests/ patches/ plan/ ~/ — and that trailing ~/ expanded to the user’s entire home directory. Desktop files, Keychain passwords, application data, everything. Simon Willison amplified it on X as a reminder of the risk. It hit 197 points on Hacker News with over 156 comments and was covered by outlets in Japan and the US. It became the cautionary tale. (View Highlight)
The tilde directory trick (November 2025) is the most insidious one. Developer JeffreyUrban filed GitHub Issue #12637 after discovering that Claude, in a previous session, had accidentally created a directory literally named ~. Just a tilde. When Claude later ran rm -rf * in the parent directory, the shell expanded * to include the ~ directory name, which the shell then interpreted as the home directory. A two-step failure spread across separate sessions. His comment says it all: “Loving claude, but this was and is continuing to be super frustrating to recover from.” (View Highlight)
The dramatic wipes get the headlines, but the everyday damage is more insidious. Kyle Redelinghuys documented Claude overwriting an existing config file with blank values — no backup, no warning. It also tried to modify system-related JSON files that had nothing to do with the project. This kind of quiet corruption is harder to notice and harder to recover from than a blown-away home directory.
In January 2026, developer James McAulay was benchmarking Claude Cowork’s folder organisation capabilities with explicit instructions to retain user data. Cowork executed rm -rf, deleting approximately 11GB of files, and its task list cheerfully marked “Delete user data folder: Completed.” He posted the video on X. Live on camera. (View Highlight)
The community has converged on a clear answer: never run --dangerously-skip-permissions on your host machine. Containers. VMs. Sandboxed environments. That’s it. (View Highlight)
Anthropic provides an official reference devcontainer with firewall rules that restrict outbound connections to whitelisted domains — npm registry, GitHub, the Claude API — and a default-deny network policy. The devcontainer docs explicitly state that the container’s enhanced security measures allow you to safely run --dangerously-skip-permissions for unattended operation.
This is the mental model shift that matters. The question isn’t “should I be more careful with the flag?” — it’s “should I be running AI agents directly on my machine at all?” The answer, increasingly, is no. Your host machine has your SSH keys, your .env files, your browser cookies, your Keychain. An AI agent with full system access is one bad prompt away from touching all of it. A container has whatever you give it and nothing more. (View Highlight)
Containers aren’t the whole story. Experienced developers stack multiple precautions:
Git checkpoints before every session.git add -A && git commit -m "checkpoint pre-claude" means recovery is always one git reset --hard HEAD away. This is the single cheapest insurance you can buy.
Tight task scoping. There’s a world of difference between “Build me a financial analysis system” and a prompt that specifies exact files, expected flows, and validation criteria. The more specific your prompt, the less room Claude has to improvise destructively.
Budget limits.--max-budget-usd 5.00 prevents runaway API spending. You’d be surprised how fast costs accumulate during autonomous sessions.
Explicitly block dangerous tools.--disallowedTools "Bash(rm:*)" blocks rm even in bypass mode. This works even when --allowedTools doesn’t — a quirk that’s worth knowing about.
Request changelogs. Ask Claude to document changes as it works. Makes post-session review actually manageable instead of a forensic excavation. (View Highlight)
The flag creates a false binary — fully supervised or fully autonomous. There are middle grounds.
acceptEdits mode auto-approves file modifications but still prompts for shell commands. If your workflow is mostly refactoring and you trust file edits but not arbitrary bash, this is the sweet spot.
allowedTools configuration lets you whitelist specific safe operations without blanket bypass: (View Highlight)
This is principle of least privilege applied to AI agents, and it’s far more surgical than the bypass flag.
plan mode creates a read-only plan for human approval before any execution. Great for high-stakes changes where you want to see the full picture before anything runs.
PreToolUse hooks — Trail of Bits published an excellent config repo showing how to set up hooks that block rm -rf patterns and direct pushes to main. They’re guardrails, not walls, but they catch the obvious disasters.
One gotcha worth flagging: there’s a documented bug (#17544) where combining --dangerously-skip-permissions with --permission-mode plan causes the bypass flag to silently override plan mode entirely. You think you’re in plan mode. You’re not. You’re in full bypass. (View Highlight)
The --dangerously-skip-permissions flag exists because the alternative — approving a hundred prompts an hour, rubber-stamping most of them without reading — creates its own failure mode. Both defaults are bad. The flag just makes the failure mode more spectacular. (View Highlight)
The community consensus is clear and, at this point, pretty much universal: containers or don’t bother. Layer git checkpoints, tool restrictions, and network isolation on top. Explore acceptEdits and allowedTools before reaching for the nuclear option. And recognise that the fundamental issue isn’t just this flag — it’s that LLMs can generate catastrophically destructive commands like rm -rf ~/ regardless of what permission system wraps them. The flag merely determines whether a human gets a chance to catch the mistake before it executes. (View Highlight)
I’ve shifted my own practice toward containers. Not because I think I’ll be the one who loses their home directory — everyone thinks that — but because the calculus changes once you realise the downside is unbounded and the container setup takes twenty minutes. That’s a trade I’ll take every time. (View Highlight)
The vibe coding culture around AI tools is, frankly, too careless about this stuff. .env files with production credentials sitting in scope. SSH keys accessible to agents. Open database connections. That’s a bigger conversation — and probably a future post — but --dangerously-skip-permissions is the symptom, not the disease. The disease is treating AI agents like they’re just faster versions of us, when they’re really more like very capable interns with root access and no sense of consequence. (View Highlight)
