Permissions & Tool Allowlisting in Claude Code: A Beginner's Guide

A developer published a beginner's guide to configuring permission rules in Claude Code, showing how allow/ask/deny gates in .claude/settings.json can block risky agent actions such as force-pushing a branch or running a DROP database command. The guide argues that skills and subagents govern code style and review but never decide whether a specific tool call should run at all, and warns that overusing "ask" rules erodes the gate's value because users stop reading prompts.

Remember the setup from the first article https://dev.to/alimurrazi/agents-and-skills-in-claude-code-a-beginners-guide-24hk — a project with CLAUDE.md , an api-conventions skill, and a code-reviewer subagent, all working together to keep new API endpoints consistent? Same project. But Claude Code doesn't only touch files — it can also run terminal commands and, if you've connected one, query your actual database. So now picture this: mid-session, Claude decides the fix for a bug is to push the branch straight to remote before you've looked at it. Or it runs a "quick" database command to test something, and that command is a DROP . Nothing in the skill or the subagent stops either of those — they only cover how code should look and who reviews it. Neither one ever asked "should this specific action be allowed to happen at all?" That question is what permissions answer. A permission is a gate : before Claude runs a tool call, a rule decides whether it's allowed, denied, or needs your OK first. It's not reasoning about risk — it's checking a pattern you wrote in advance. Every tool call lands in one of three buckets: Permission rules live in .claude/settings.json , right alongside the skill and subagent files from the first article: your-project/ ├── CLAUDE.md ├── .claude/ │ ├── settings.json ← permission rules go here │ ├── skills/ │ └── agents/ └── src/ Commit that file to the repo, and the project can share the same permission configuration across the team. Here's a rule set that directly stops both close calls from the opening — one rule per tool, so you can see this isn't just a Bash thing: { "permissions": { "allow": "Bash git " , "ask": "Bash git push " , "deny": "Database DROP " } } git status , git diff → git push → git rule DROP query against the database, through whatever tool gives Claude that access → Two different tools, same three-outcome idea. Once you understand the pattern, you can use the same allow/ask/deny idea across the tools Claude Code can use. The same rules aren't only useful for teams, either — they also protect you , three hours into a solo debugging session, from your own tired typo turning into a dropped table. More "ask" rules ≠ more safety. If Claude asks about everything, you stop reading the prompts and just click yes — and now the gate isn't protecting anything. A permission only helps if someone actually reads it.