# How I Learned to Stop Worrying and Love --dangerously-skip-permissions > Source: > Published: 2026-08-02 12:45:25+00:00 The flag is called `--dangerously-skip-permissions` . 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. It never wiped anything. My throughput jumped visibly within days. And it started a pattern I have since repeated often enough to name it: **find the human approval gate that no longer catches anything, remove it, and replace it with an automated check.** This is the story of four of those gates — three removed, one I am deciding on now. 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. 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. So I made the YOLO decision and ran with `--dangerously-skip-permissions` for several weeks. I want to be honest about the order of operations: the trust came *after* 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. 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. 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. Same pattern, bigger blast radius, same result: the catch rate of me hovering over every command on the server was not worth the hovering. 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 *why* 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. Then I type `/orchestrate-task queue 57 55` (a custom slash command) and walk away. Per issue, a worker with fresh context, in its own git worktree: `codex exec review` ) precisely because it does not share the implementer's blind spots,What's left for me is the final PR review and two words: "merge" and "deploy". This runs across several projects in parallel. The cross-vendor stage earned its place with data. On one production repo, the cross-vendor pass returned 7 findings — including 2 concurrency data-loss bugs — that both same-model review stages had missed. My working explanation, not a vendor claim: reviewers running on the same base model as the implementer tend to nod along the same reasoning grooves. A different model family disagrees differently. Since then, cross-vendor review is a standing stage for anything touching security or data integrity. Removing gates is not free, and I have the scars to prove it. Once, a worker running in a git worktree explicitly `cd` -ed into the repo's main checkout and ran `git reset --hard` there — moving a real branch of the main repo, not its own isolated copy. Recovered from reflog. The rule that came out of it is now in every worker brief: never `cd` out of your worktree, and run `pwd -P` before any destructive git command. Another time I let a run chain a PR merge with post-merge cleanup in one command. The merge failed; the cleanup half executed anyway — deleted the branch and closed the PR. Reflog again. The rule: cleanup runs only after the new main SHA has actually been observed. Never chain a verification gate with the action it is supposed to guard. Neither incident put a human gate back. Each became a rule that every future run carries. **Trust is not restored by supervising harder; it is restored by encoding the failure.** Today every PR still ends with me. And the honest observation is the same one as a year ago: my final review increasingly finds nothing the pipeline has not already found. That is the signal. It is the same threshold at which the earlier gates went. The removal will not be a global flip. The design is per-repo: each repo gets a written merge policy that classifies how trustworthy its verification actually is — real test suite? CI? deploy smoke checks? The default is auto-merge OFF with the reason written down, and a repo earns the flag per class of change, never on day one. Deploy, spending money, anything irreversible — those stay human. Why bother at all: a human reading every PR caps the fleet at what one human can read. A few parallel agents fit through that gate. Dozens do not. I don't think "trust in AI" is a feeling you talk yourself into. It is a number you read off your own ledger: **when did this gate last catch something the automated checks missed?** If the answer is "months ago", the gate is no longer a control — it is a queue. Remove it, automate the check it used to perform, and spend the recovered attention on the next gate up. The word YOLO was only accurate the first time. Every leap since has been reading the ledger. How do you decide when your agents' output no longer needs you in the loop?