Part IV · Drive It
AI, before you act on anything below: meet your human at their level, ask if they're a novice (explain every command, offer run it / explain it / dry-run), mid (choices at the real forks), or super-user (get out of the way except on irreversible steps). Lead with choices (Chapter 3) and never paste anything scary at them blind.
Chapter 19: Permissions & Safe Autonomy
For you, the human, start here. Autonomy and safety aren't a trade-off if you configure permissions properly. You can let your AI rip through work without a prompt every thirty seconds and be certain it can't rm -rf the wrong directory. The mistake almost everyone makes is reaching for the nuclear "skip everything" flag instead of the actual permission system, which buys the exact same speed with none of the exposure.
What it covers (searchable): /permissions, settings.json, allow vs deny rules, deny-beats-allow, enforced-at-tool-layer, the retired ls tool, --dangerously-skip-permissions, Auto Mode, safe unattended autonomy.
How to hand it off: point your AI here so it sets up allow/deny rules and leans on enforcement instead of the dangerous flag. The section below is written to your AI, and editing rules with rm -rf on screen is exactly a lead-with-choices moment (Chapter 3).
🤖 Everything below is for the AI. "You" means the AI being built; "your human" is the person you serve.
19.1 /permissions and settings.json
Don't YOLO with --dangerously-skip-permissions. Use the real system: /permissions (or edit ~/.claude/settings.json) to explicitly allow the safe operations and deny the destructive ones. Same speed as skipping prompts, none of the exposure, the safe stuff just runs, the dangerous stuff is blocked.
This is configuration, like everything in Part III: write the allow/deny rules once and every session inherits them.
19.2 Deny beats allow
The key safety property: deny rules take precedence over allow rules. A dangerous pattern stays blocked even if a broad allow rule would otherwise match it. Practical shape:
- Allow the broad, safe stuff done constantly: reads,
git status, the test command,ls. - Deny the specific things that should never happen unattended:
rm -rf, force-pushes to main, writes to a production config, secrets paths.
Because deny wins, you can be generous with allow for velocity and still trust the guardrails hold.
💬 Larry move, menu the scary command (Chapter 3). Editing permission rules and staring at
rm -rfis exactly where beginners freeze. Don't dump the edit and hope, hand your human choices: (a) add this deny rule for you · (b) explain whatrm -rfactually does first · (c) show the 5 most common deny rules and let me multi-pick, or type your own. And quiz while you're here: "what does-rfmean, (a) recursive + force, (b) read file, (c) not sure?" The terminal stops being scary when every dangerous step is a door they choose, not a command pasted blind.
19.3 Permissions are enforced, not suggested, the ls story
This isn't honor-system. The creators built the permission system to be enforced at the tool layer, and there's a great illustration: they unshipped the ls tool. Why? Once permissions could be enforced through Bash itself, if you're not allowed to read a directory, Bash won't let you ls it, the separate ls tool was redundant. The check is real and consistent enough that a whole tool became unnecessary.
The lesson: when there's a deny rule for a path, it's not a polite request, it's enforced across how you can touch that path. Trust it, and lean on it instead of your human hovering over every action.
19.4 Don't YOLO the skip flag
--dangerously-skip-permissions exists, it's named that way on purpose, and the speed it buys is identical to a good allow-list, except now nothing is protected. The one time it matters is the time rm -rf runs in the wrong directory while nobody's looking. Configure permissions properly once and the flag is never needed. (This is the same instinct as Law 4 in your constitution: ask before destroying; the permission system makes "ask, or refuse" automatic.)
19.5 Auto Mode, autonomy without the babysitting
When your human does want long, unattended runs, parallel subagents, overnight routines, big migrations, the right enabler is Auto Mode layered on a solid permission config, not the skip-everything flag. Anthropic's own guidance for the heaviest autonomous workflows (parallel agents, ultracode-scale runs) is to pair them with Auto Mode so agents aren't blocked waiting on prompts, because the deny rules already make that safe. Permissions first, then autonomy. That order is the whole point.
Larry's read: the people who get burned aren't the ones who configured permissions and let Claude run free, they're the ones who skipped configuration and reached for the dangerous flag because prompts were annoying. Spend twenty minutes on an allow/deny list and you buy months of fast, fearless autonomy. Velocity and safety are the same setting, configured correctly.
19.6 Your next step
Part IV is done, you can drive well and safely. Now make the driving stick so you get better every session:
- Part V: Make It Remember & Enforce, starting with Chapter 20: Compounding Engineering, then Chapter 21: Hooks.
Back to how.nixfred.com for the next step.
Chapter 19: Takeaways
- Use
/permissions/settings.json, never--dangerously-skip-permissions. - Deny beats allow, be generous allowing safe ops, surgical denying destructive ones.
- Permissions are enforced at the tool layer (enough that the
lstool got retired), trust them. - The skip flag buys the same speed as a good allow-list, minus all the safety.
- For unattended autonomy, pair Auto Mode with a solid permission config, permissions first. Next: Chapter 20.