{"slug": "permissions-tool-allowlisting-in-claude-code-a-beginner-s-guide", "title": "Permissions & Tool Allowlisting in Claude Code: A Beginner's Guide", "summary": "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.", "body_md": "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.\n\nSo 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?\"*\n\nThat question is what permissions answer.\n\nA 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.\n\nEvery tool call lands in one of three buckets:\n\nPermission rules live in `.claude/settings.json`, right alongside the skill and subagent files from the first article:\n\n```\nyour-project/\n├── CLAUDE.md\n├── .claude/\n│   ├── settings.json          ← permission rules go here\n│   ├── skills/\n│   └── agents/\n└── src/\n```\n\nCommit that file to the repo, and the project can share the same permission configuration across the team.\n\nHere'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:\n\n```\n{\n  \"permissions\": {\n    \"allow\": [\"Bash(git *)\"],\n    \"ask\": [\"Bash(git push *)\"],\n    \"deny\": [\"Database(DROP *)\"]\n  }\n}\n```\n\n`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.\n\nThe 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.\n\nMore \"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.\n\n**A permission only helps if someone actually reads it.**", "url": "https://wpnews.pro/news/permissions-tool-allowlisting-in-claude-code-a-beginner-s-guide", "canonical_source": "https://dev.to/alimurrazi/permissions-tool-allowlisting-in-claude-code-a-beginners-guide-592i", "published_at": "2026-09-18 04:16:58+00:00", "updated_at": "2026-09-18 04:22:48.546496+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-safety"], "entities": ["Claude Code", "Anthropic"], "alternates": {"html": "https://wpnews.pro/news/permissions-tool-allowlisting-in-claude-code-a-beginner-s-guide", "markdown": "https://wpnews.pro/news/permissions-tool-allowlisting-in-claude-code-a-beginner-s-guide.md", "text": "https://wpnews.pro/news/permissions-tool-allowlisting-in-claude-code-a-beginner-s-guide.txt", "jsonld": "https://wpnews.pro/news/permissions-tool-allowlisting-in-claude-code-a-beginner-s-guide.jsonld"}}