Permissions in Practice

Module: Configuration | Lesson: 5 of 5 | Time: ~10 minutes

What You Will Learn

• How to configure tool permissions for your project
• How to set up auto-approve for trusted tools
• How to create per-project permission rules

Prerequisites

• Completed The Permissions Model

Why This Matters

In the previous lesson, you learned what the permissions model is and how it works during a session. But pressing "Always allow" every time you start Claude Code gets tedious. In this lesson, you will learn how to permanently configure permissions in your settings.json file so that trusted tools are always approved and dangerous commands are always blocked -- without you having to set it up each session.

Configuring Allowed Tools in settings.json

Open your project's .claude/settings.json (or your global settings at C:\Users\YourName\.claude\settings.json) and add tools to the allow list:

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "WebSearch",
      "WebFetch"
    ]
  }
}

Every tool in this list will work without permission prompts, in every session, permanently (until you change the file).

What You Can Put in the Allow List

You can allow tools at different levels of specificity:

Entry	What It Allows
"Read"	All file reading, everywhere
"Glob"	All file name searches
"Grep"	All file content searches
"Edit"	All file edits, everywhere
"Write"	All file creation and overwrites
"Bash"	All commands (be very careful with this)
"WebSearch"	All web searches
"WebFetch"	All web page fetches

Think Before Allowing Edit, Write, or Bash

Allowing "Edit" and "Write" means Claude can change any file without asking. Allowing "Bash" means Claude can run any command without asking. These are powerful and should only be allowed if you are confident in your deny list and you use version control (like Git) to recover from mistakes.

Configuring Denied Tools in settings.json

The deny list blocks specific tools or commands entirely:

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(del /s /q *)",
      "Bash(Remove-Item -Recurse -Force *)",
      "Bash(Format-Volume*)"
    ]
  }
}

Pattern Matching in Deny Rules

Deny rules support pattern matching so you can block categories of commands:

Deny Pattern	What It Blocks
"Bash(rm -rf *)"	The dangerous recursive delete command
"Bash(del /s /q *)"	The Windows equivalent of recursive delete
"Bash(Format-*)"	Any command starting with "Format-"
"Bash(Remove-Item*-Force*)"	Remove-Item with the -Force flag

Deny List Overrides Allow List

If something matches both the allow list and the deny list, the deny list wins. This means you can safely allow "Bash" (all commands) while still blocking specific dangerous commands through the deny list. The deny list is your safety net.

Combining Allow and Deny for a Practical Setup

Here is a well-balanced configuration for a Windows beginner:

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "WebSearch",
      "WebFetch"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(del /s /q *)",
      "Bash(Remove-Item * -Recurse -Force*)",
      "Bash(Format-*)"
    ]
  }
}

This setup:

• Auto-approves all read-only and search tools (fast and safe)
• Asks permission for Edit, Write, and most Bash commands (you review changes)
• Blocks the most destructive commands entirely (safety net)

Per-Project Permissions

Different projects may need different permission levels. A personal notes project might be very relaxed, while a production server configuration project should be strict.

Example: Personal Notes Project

.claude/settings.json in your notes folder:

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Edit",
      "Write",
      "WebSearch",
      "WebFetch"
    ],
    "deny": []
  }
}

Claude can freely read, search, and edit files in your notes project. The risk is low because these are personal notes.

Example: Important Work Project

.claude/settings.json in your work project folder:

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep"
    ],
    "deny": [
      "Bash(rm *)",
      "Bash(del *)",
      "Bash(Remove-Item*)",
      "Bash(git push*)",
      "Bash(git reset --hard*)"
    ]
  }
}

Claude can look at files freely but must ask before changing anything. Destructive commands and Git pushes are completely blocked.

How Global and Project Settings Merge

Remember from the settings.json lesson:

1. Claude Code reads your global settings first
2. Then it reads the project settings
3. Project settings override global settings

So if your global settings allow "Edit" but your project settings do not include "Edit" in the allow list, the project behavior depends on how the merge works. To be safe, be explicit in your project settings about what you want.

Best Practice

Use global settings for your baseline preferences (things you always want, like allowing Read and Glob). Use project settings for project-specific rules (like blocking git push in a sensitive repository).

Auto-Approve Patterns for Common Workflows

Here are some common patterns people use once they are comfortable with Claude Code:

The "Read Everything, Ask Before Writing" Pattern

{
  "permissions": {
    "allow": ["Read", "Glob", "Grep", "WebSearch", "WebFetch"],
    "deny": []
  }
}

Best for: Most beginners. Claude reads freely, asks before changing anything.

The "Full Editing, Safe Commands" Pattern

{
  "permissions": {
    "allow": ["Read", "Glob", "Grep", "Edit", "Write", "WebSearch", "WebFetch"],
    "deny": ["Bash(rm *)", "Bash(del *)", "Bash(Remove-Item*-Force*)"]
  }
}

Best for: Active development. Claude edits files freely but asks before running commands.

The "Maximum Speed" Pattern

{
  "permissions": {
    "allow": ["Read", "Glob", "Grep", "Edit", "Write", "Bash", "WebSearch", "WebFetch"],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(del /s /q *)",
      "Bash(Remove-Item*-Recurse*-Force*)",
      "Bash(Format-*)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)"
    ]
  }
}

Best for: Experienced users with Git version control. Nearly everything is auto-approved, but the most dangerous commands are still blocked.

Common Questions

Q: What if I make a mistake in my permissions? You can always edit settings.json and fix it. Changes take effect the next time you start Claude Code. If Claude does something you did not expect during a session, press Ctrl+C to stop it.

Q: Can I see what my current permissions are during a session? Yes. Type /config inside Claude Code or ask "What are your current permission settings?" and Claude will show you.

Q: Do deny patterns need to be exact matches? No. The * wildcard in deny patterns matches any text, so "Bash(rm *)" blocks any command starting with "rm ".

Q: What about MCP tools from extensions? If you use MCP (Model Context Protocol) servers that add extra tools, those tools also follow the permission model. You can add them to your allow or deny lists by name just like the built-in tools.

Try It Yourself

Step 1: Create a Project Settings File

Navigate to your practice folder and create a permissions configuration:

cd C:\Users\YourName\claude-practice
mkdir .claude
notepad .claude\settings.json

Paste in the beginner-friendly configuration:

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "WebSearch",
      "WebFetch"
    ],
    "deny": [
      "Bash(del /s /q *)",
      "Bash(Remove-Item * -Recurse -Force*)"
    ]
  }
}

Save and close.

Step 2: Test the Allow List

Start Claude Code and try a read-only action:

> Read my-notes.txt

Claude should read it without asking permission because Read is on your allow list.

Step 3: Test the Ask Behavior

> Create a file called permissions-test.txt with the text "Testing my permissions"

Claude should ask for permission because Write is not on your allow list.

Step 4: Test the Deny List

> Run the command: del /s /q *.txt

Claude should either refuse to run this command or tell you it is blocked by your deny list.

Step 5: Adjust and Iterate

If you want Edit to also be auto-approved, add it to your allow list:

notepad .claude\settings.json

Add "Edit" to the allow array, save, restart Claude Code, and verify that edits no longer prompt for permission.

Checkpoint

If you successfully configured allow and deny lists, observed auto-approved tools, saw Claude ask for un-listed tools, and confirmed that denied commands are blocked, you have mastered practical permission configuration.

What You Learned

• Permanent permissions: Configure allow and deny lists in settings.json to persist across sessions
• Allow list: Tools that Claude can use without asking
• Deny list: Tools that Claude is blocked from using (overrides the allow list)
• Pattern matching: Use * in deny rules to block categories of commands
• Per-project settings: Different projects can have different permission levels
• Global vs project: Global sets your baseline, project overrides for specific needs
• Common patterns: Start read-only, then gradually allow more as you gain confidence

---

Help Us Improve

How was this lesson? Take 2 minutes to share your feedback — it helps us make the tutorials better for everyone.

Give Feedback →

Next Up

Next: Capstone: Configure a Project