🛡️ Module 6 of 10 14 min read Phase 2: Core Skills

Permissions

Controlling What Claude Code Can Do

▶

Video Lesson Coming Soon

A video walkthrough for this module is in production. For now, dive into the written content below.

What You'll Learn

✓ How the permission model works
✓ The five permission modes
✓ Tool-level rules: allow and deny
✓ Common permission patterns
✓ Sandboxing and safety defaults
✓ Configuring for your workflow

In this module 6 sections

How Permissions Work

Every time Claude Code wants to take an action that could change something — editing a file, running a shell command, accessing a tool — it asks for your permission.

This is not a limitation. It is a deliberate safety feature. Claude Code is powerful enough to edit any file in your project and run any command on your system. Permissions make sure it only does what you approve.

You can configure permissions to be strict (approve everything individually), relaxed (auto-approve safe operations), or anywhere in between. The right level depends on your comfort and the sensitivity of the project.

The Five Permission Modes

Mode	Behavior	Best For
default	Asks permission for file edits and commands	Most developers, most of the time
acceptEdits	Auto-approves file edits, asks for commands	Trusted projects where you want speed
plan	Read-only — no edits, no commands allowed	Investigation and exploration
dontAsk	Auto-approves known-safe tools, asks for the rest	Experienced users with clear boundaries
bypassPermissions	Approves everything without asking	CI/CD and disposable containers only

⚠️

Safety Warning

bypassPermissions should only be used in disposable environments like CI containers, Docker images, or sandboxed test environments. Never use it on your main development machine — it gives Claude Code unrestricted access to edit files and run commands without any approval.

Tool-Level Rules: Allow and Deny

Beyond the five modes, you can create fine-grained rules for specific tools. Rules use a simple syntax: the tool name, optionally with a pattern in parentheses.

.claude/settings.json

{
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run test *)",
      "Bash(npm run lint *)",
      "Bash(npm run build)",
      "Edit(src/**/*.ts)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Bash(DROP TABLE *)",
      "Edit(.env*)"
    ]
  }
}

Common Permission Patterns

✓ Allow all read operations — Read, Grep, Glob, and LS are always safe

✓ Allow test and lint commands — these never modify production code

✓ Require approval for git operations — commits, pushes, and branch changes deserve review

✓ Deny destructive commands — rm -rf, git push --force, DROP TABLE, and similar

✓ Deny editing sensitive files — .env files, credentials, and configuration with secrets

✓ Allow edits in src/ but not in config files — protect your project configuration

Sandboxing and Safety Defaults

Claude Code runs with built-in safety defaults that work alongside the permission system:

Filesystem sandboxing restricts which directories Claude Code can access. By default, it can only access your current project directory and its subdirectories.

Network restrictions prevent Claude Code from making arbitrary network requests. It can access the Anthropic API (for its own operation) and approved MCP servers, but it cannot fetch random URLs or connect to arbitrary services.

These defaults exist because an AI agent with unrestricted shell access is powerful but potentially dangerous. The sandbox ensures that even if you approve a command, it runs within safe boundaries.

Configuring for Your Workflow

Start with the default mode for your first week

Use the default permission mode for everything. Pay attention to which prompts you always approve and which you always deny.

Identify what you always approve

After a week, you will notice patterns. You probably always approve test runs, lint fixes, and file reads. Add these to your allow list.

Identify what you never want to happen

Some commands should never run — force pushes, recursive deletes, editing secrets. Add these to your deny list.

Test your configuration

After configuring, test by asking Claude Code to perform various operations. Make sure allowed operations proceed without prompts and denied operations are blocked.

Key Takeaways

Five permission modes (default, acceptEdits, plan, dontAsk, bypassPermissions) let you choose the right safety level

Tool rules create fine-grained allow and deny lists — approve npm test automatically, block rm -rf forever

Deny rules always win over allow rules — if something is in both lists, it gets denied

Start with the default mode, observe what you always approve, then gradually add allow rules for those operations

📝 My Notes▼

← Plan Mode IDE Integration →