Permissions & Security

Switch modes during a session with Shift+Tab.

🧠 Knowledge Check

Q: When you click "Yes, don't ask again" for a Bash command, how long does that permission last?

Permanently per project directory. For Bash commands, "don't ask again" persists across sessions for that specific project + command combination. For file edits, it only lasts until the session ends.

Permission Rules

Evaluation Order

First matching rule wins. Deny always takes precedence.

Example Configuration

Bash Rule Details

Wildcards (*) can appear anywhere in the command:

Gotcha: Bash(ls *) matches ls -la but not lsof. The space matters — Bash(ls*) (no space) matches both.

Read/Edit Path Rules

Follow gitignore-style patterns:

MCP Tool Rules

✍️ Recall Exercise

Fill in the blanks:

• Permission evaluation order: ___ → ask → allow
• To block all tools from an MCP server: mcp__servername_____
• To auto-accept file edits: permission mode ___

• deny
• mcp__servername__*
• acceptEdits

Sandboxing

Sandboxing provides OS-level enforcement that restricts Bash commands' filesystem and network access.

Why Sandboxing Matters

• Approval fatigue → Constantly clicking "approve" leads to carelessness
• Prompt injection → Malicious content could trick Claude into running harmful commands
• Supply chain → Compromised npm packages / build scripts

How It Works

Filesystem Isolation:

• ✅ Read/write: current working directory and subdirectories
• ✅ Read: entire computer (except denied directories)
• ❌ Cannot modify files outside the working directory

Network Isolation:

• Only approved domains can be accessed
• New domain requests trigger permission prompts

OS-Level Enforcement:

Enable Sandboxing

Sandbox Modes

Pro Tip: Auto-allow mode with sandboxing is the sweet spot — fast iteration with OS-level safety guarantees.

🧠 Knowledge Check

Q: With sandboxing enabled, what happens if Claude tries to modify ~/.bashrc?

The modification is blocked at the OS level. Sandboxing restricts write access to the current working directory and its subdirectories. Even if Claude is tricked via prompt injection, it physically cannot modify system files like ~/.bashrc, ~/.zshrc, or any file outside the project.

Security Best Practices

Built-in Protections

• Write access restriction: Only writes to launch directory and subdirectories
• Command blocklist: curl and wget blocked by default
• Isolated context windows: Web fetch uses separate context (prevents prompt injection)
• Trust verification: First-time codebase runs require trust verification
• Command injection detection: Suspicious commands need manual approval even if allowlisted

Working with Untrusted Content

1. Review suggested commands before approval
2. Avoid piping untrusted content directly to Claude
3. Use devcontainers for additional isolation
4. Report suspicious behavior with /bug

🧠 Knowledge Check

Q: Why are curl and wget blocked by default?

They're blocked to prevent data exfiltration. A prompt injection attack could trick Claude into sending sensitive data (API keys, source code, etc.) to an attacker's server. Blocking these commands by default prevents that attack vector.

Development Containers

Claude Code provides a reference devcontainer for maximum isolation:

Inside a devcontainer, you can safely use:

The container's firewall restricts network to necessary services only, and filesystem access is limited to the project.

Enterprise: Managed Settings

For organizations that need centralized control:

Deploy to:

• macOS: /Library/Application Support/ClaudeCode/managed-settings.json
• Linux: /etc/claude-code/managed-settings.json

✍️ Recall Exercise

Fill in the blanks:

• To enable sandboxing: /___
• macOS uses ___ for OS-level sandboxing
• To report suspicious Claude behavior: /___

• /sandbox
• Seatbelt
• /bug

🔨 Try It Yourself

1. Open your project's .claude/settings.json
2. Add permission rules:

   {
     "permissions": {
       "allow": ["Bash(pnpm *)"],
       "deny": ["Bash(rm -rf *)"]
     }
   }
   

3. Start a session and ask Claude to run pnpm test — it should auto-approve
4. Ask Claude to run rm -rf node_modules — it should be blocked
5. Run /sandbox to explore sandbox settings

Reflection: How does the permission system change your comfort level with Claude making changes?

🤔 What Would You Do?

Scenario: A junior developer on your team accidentally gave Claude "don't ask again" permission for git push to main. How do you prevent this from happening again?

Add a deny rule to the shared project settings (.claude/settings.json):

Deny rules always win — even if a user previously allowed the command. For enterprise teams, use managed settings with allowManagedPermissionRulesOnly: true to prevent users from adding their own allow rules.

📋 Key Takeaways (Review These Tomorrow)

Next up: Hooks — Automate Everything → — Learn how to trigger shell commands at every lifecycle event.