Permissions & Settings | Operating Manual

Claude's default stance is to ask before executing tools: Bash commands, file writes, MCP calls, URL fetches. That's safe but noisy. The permission model lets you declare what's safe to run without confirmation via settings.json, either scoped to a project or applied globally across all your sessions.

The config lives in two places: .claude/settings.json at the project root (committed with your repo, shared with the team) and a user-level global file for personal defaults. Project-level settings layer on top of user-level ones. You specify allowed tools and, for Bash, specific command patterns. Claude matches these at runtime and skips the prompt for anything on the list.

How you use it day-to-day

Allowlist read-only Bash patterns. Commands like git status, ls, cat, and test runners are safe to auto-approve at the project level. Add them to .claude/settings.json so the whole team benefits without a per-session prompt.
Use /permissions to allowlist domains. When you paste URLs for Claude to fetch, the /permissions command is how you approve those domains so Claude doesn't stop to ask on each fetch.
Share settings via git. Commit .claude/settings.json (and .mcp.json for MCP servers) so team members get the same approved toolset from the first clone. Don't commit your user-level file. That one is personal.
Allow safe operations to match your risk tolerance. The official advice: allow safe operations, stay conservative on destructive ones. A lint runner or test command rarely needs human review; a rm -rf does.
Use --dangerously-skip-permissions only in isolation. For fully autonomous runs (CI, containers, lint-and-commit scripts), this flag bypasses all permission checks. The source is explicit: only use it in containers without internet access. Don't run it in your main dev environment.
Lean on auto mode once you trust the loop. A year after GA, Boris Cherny (Claude Code's creator) said he runs auto mode over plan mode for most work and lets routines fix bugs before he ever sees them. The bottleneck shifts from typing to oversight. Start conservative, then widen the allowlist as your confidence in the workflow grows.

Gotchas

Project settings are visible to everyone with repo access. Don't allowlist anything that would be a security problem if a contributor ran it automatically.
Reducing prompts speeds things up, but so does tuning CLAUDE.md. Specific file references and a well-tuned CLAUDE.md cut down on exploratory tool calls in the first place, which matters more than approval speed.
--dangerously-skip-permissions is not a convenience flag. The source explicitly warns it should only run in containers without internet access, not as a way to avoid prompts in a normal session.
Allow lists are pattern-based for Bash. Overly broad patterns can auto-approve more than you intend. Be specific about the exact commands you're comfortable with.

Practical starting point: run the fewer-permission-prompts skill (/fewer-permission-prompts in your session) to scan your recent transcripts and generate a prioritized allowlist for your project .claude/settings.json. It extracts what you've already been approving and writes the config for you.