Permissions

Permissions are the difference between a fast autonomous agent and a fast autonomous disaster. Designing them well is the single highest-leverage config decision you'll make.

The three modes

• manual, every tool call requires explicit approval. Safe. Slow.
• auto, pre-approved actions run; unknown actions prompt. The default for real work.
• plan, generate a plan first, user approves plan, execute.

Allow lists, what to say yes to

Think in tiers:

Always safe (allow widely)

• Read, Glob, Grep, reading files
• Bash(ls:*), Bash(cat:*), Bash(head:*), Bash(tail:*)
• Bash(git status), Bash(git log:*), Bash(git diff:*)
• Information-gathering MCPs: mcp__search__*, mcp__docs__*

Mostly safe (allow with patterns)

• Edit, Write, file modifications
• Bash(npm install:*), Bash(bun install:*), dependency installs (within trusted dirs)
• Bash(git add:*), Bash(git commit:*), local git work
• Most MCP read operations

Risky, require explicit approval

• Bash(git push:*), pushes to remote
• Bash(curl:*) with POST to unknown endpoints
• MCP tools that modify external state: mcp__github__create_pr, mcp__stripe__charge
• Anything touching production systems

Never, deny always

• Bash(sudo:*), no
• Bash(rm -rf:*), no
• Bash(security dump-keychain:*), keychain exfiltration
• MCP delete_* patterns on production services
• Bash(dd:*), mkfs:*, diskutil erase*, destructive disk ops

Pattern syntax

Allow/deny entries use a specific pattern syntax:

• Bash(ls), exactly ls with no args
• Bash(ls:*). ls with any args
• mcp__notion__*, any tool from the notion MCP
• Edit, allow the built-in Edit tool (no pattern needed, it's a non-Bash tool)

The deny list always wins

If a call matches both an allow pattern and a deny pattern, it's denied. Use this: broad allows + surgical denies.

"allow": ["Bash(git:*)"],
"deny": ["Bash(git push:*)", "Bash(git reset --hard:*)"]

Result: agent can do all git operations except push and hard-reset.

Auto mode strategy

The goal of auto mode is "zero interruptions for 95% of work." Design it in two passes:

1. Start conservative. Small allow list: read-only tools, safe shell commands, known MCPs.
2. Expand on friction. Every time you approve the same thing twice, consider adding it to the allow list.

The /fewer-permission-prompts skill in Claude Code can analyze your recent session history and suggest allow-list additions.

Per-project permissions

Drop a .claude/settings.json in a project directory to override permissions for that project. Useful for prod repos (stricter) vs, playground repos (looser).

Audit log

Claude Code records every tool call. Review periodically. If something surprising got auto-approved, tighten the allow list.