Permissions are how Claude Code decides whether an action it wants to take — editing a file, running a shell command, fetching a URL, or calling an MCP tool — runs automatically or pauses to ask you first. By default Claude Code is conservative: it prompts before potentially impactful actions, and you can approve once, approve similar actions going forward, or reject.
Permission rules are expressed as allow, ask, and deny lists scoped to specific tools (for example, editing tools or particular shell commands). Rules can live at the user, project, and local levels and are stored alongside your other configuration in settings.json. Project-level rules can be checked into source control so a team shares the same guardrails, while local rules stay private to your machine.
Claude Code also has permission modes that change the overall posture for a session — from the default approval-first behavior, to plan mode (read and analyze only, no changes), to modes that auto-accept edits or skip prompts entirely. You can review and adjust permissions during a session, and they work alongside hooks, which can add programmatic checks on top. Because exact rule syntax, keys, and mode names evolve, treat the official Claude Code docs as the source of truth; the core idea is stable — permissions are the boundary between what Claude does on its own and what it asks you to confirm.
Why it matters
Permissions are the safety boundary for an agent that can edit your code and run commands — tuning them well means fewer interruptions for routine work while keeping risky actions like deleting files, running unfamiliar commands, or hitting the network behind explicit approval, so you stay in control without micromanaging every step.
See Permissions in action across releases — browse the Claude Code changelog.
Get release alerts