How I Learned to Stop Worrying and Love --dangerously-skip-permissions

<p>The flag is called <code>--dangerously-skip-permissions</code>. A year ago, a few weeks into learning the then-new Claude Code, I got tired of approving every shell command and turned it on — on my main machine, no container, no VM. Every command auto-approved, including any command that could have wiped the disk.</p> <p>It never wiped anything. My throughput jumped visibly within days. And it started a pattern I have since repeated often enough to name it: <strong>find the human approval gate that no longer catches anything, remove it, and replace it with an automated check.</strong></p> <p>This is the story of four of those gates — three removed, one I am deciding on now.</p> <h2> Context </h2> <p>I'm a solo AI consultant and full-stack developer in Slovakia. I run multiple repos in parallel — my own products and client projects — with Claude Code as the primary implementation engine. Everything below is my real working setup, not a thought experiment.</p> <h2> Gate 1: per-command approval </h2> <p>Approving every Bash command feels like control. In practice it is mostly latency: after a few days you are pattern-matching on the shape of the command and pressing yes.</p> <p>So I made the YOLO decision and ran with <code>--dangerously-skip-permissions</code> for several weeks. I want to be honest about the order of operations: the trust came <em>after</em> the leap, not before it. What justified it retroactively was a simple observation — in weeks of auto-approved commands, the number of times the removed gate would have saved me was zero.</p> <p>Then I replaced my attention with something that doesn't get tired: hooks. A pre-execution hook pattern-matches destructive commands (recursive deletes and friends) and blocks them before they run. The gate didn't disappear — it was demoted from human to code.</p> <h2> Gate 2: my own server </h2> <p>On the strength of that experience I put Claude on my VPS and made it the server's administrator. Today I do the same thing over SSH from local sessions: the agent connects, diagnoses, fixes, and I read the report afterwards.</p> <p>Same pattern, bigger blast radius, same result: the catch rate of me hovering over every command on the server was not worth the hovering.</p> <h2> Gate 3: the implementation itself </h2> <p>This summer the pipeline looks like this. I write an assignment — for bigger things, a vision document. The agent interviews me about the unclear parts, then writes a GitHub issue, or a series of issues with an explicit dependency graph. Each issue is written to be self-contained: context and <em>why</em> first, settled decisions with the rejected alternatives named, scope and out-of-scope, verifiable acceptance criteria. The issue has to carry a first-time reader with zero context from the original conversation — because that is exactly what the worker agent will be.</p> <p>Then I type <code>/orchestrate-task queue 57 55</code> (a custom slash command) and walk away. Per issue, a worker with fresh context, in its own git worktree:</p> <ul> <li>implements the issue,</li> <li>writes tests, and the pipeline <strong>mutation-validates</strong> them — mutate the implementation, require the suite to go red; a test that survives mutation of the code it claims to cover gets rewritten or thrown away,</li> <li>runs a self-review, then a hostile critic review in a separate fresh context,</li> <li>runs a <strong>cross-vendor review</strong> — the diff goes to a different vendor's model (<code>codex exec review</code>) precisely because it does not share the implementer's blind spots,</li> <li>runs a <strong>blind assignment review</strong> — a fresh reviewer gets only the original issue text and the final diff, without the implementer's narrative, and answers one question: does this diff actually implement this assignment?</li> <li>fixes what the reviews found, or opens follow-up issues for what doesn't belong in this change,</li> <li>