Claude Code permissions are the rules that decide which actions Claude can run on its own and which it has to stop and ask you about first. Think of them as guardrails: you tell Claude ahead of time what is always fine, what needs a quick check, and what it must never touch. Get them right and Claude handles the safe, routine work automatically while still pausing on anything that could cause damage.
What Claude Code permissions do
Every time Claude wants to take an action -- read a file, run a command, edit your work, fetch a web page -- it checks that action against your permission rules. Depending on the rule, one of three things happens. The action runs on its own, or Claude pauses and asks you to approve it, or the action is blocked entirely. This is what lets you leave Claude working without either babysitting every step or handing it a blank check.
The three kinds of permission rule, from most permissive to most locked-down.
The three rule types: allow, ask, deny
Every permission rule falls into one of three buckets, and the names say exactly what they do.
- Allow lets Claude run the matching action automatically, with no prompt.
- Ask makes Claude stop and request your approval before running.
- Deny blocks the action completely, so it can never run.
A rule can point at a whole category of action or at something very specific. You can allow a tool by name, or you can allow it only for a certain pattern. For example, you might let Claude read a config file in your home folder but block it from reading anything in a secrets folder. That precision is what makes permissions useful: you are not stuck choosing between "trust everything" and "approve everything."
Rules can target a whole tool or a specific pattern. The exact syntax lives in your settings file.
A real example: safe git, gated pushes
Say you use Claude to help manage a project's version history. You are happy for it to check the status of your work and show you what changed, because those are read-only and harmless. But you never want it pushing changes up to a shared repository without you seeing it first.
Permissions let you split that hair exactly. You put the read-only commands on the allow list so Claude runs them freely, and you leave the push action on ask so Claude pauses for your approval every time. Now Claude moves fast on the safe parts and stops on the one thing you care about. You get speed and a safety net at the same time.
The /permissions command
You do not have to hand-edit anything to manage your rules. Inside Claude Code, run /permissions and it opens a dialog where you can review and change your rules directly. The same command is also available under the alias /allowed-tools, so either one gets you there.
Opens the permissions dialog. Click to copy.
The dialog is where you manage your rules by scope, review which working directories Claude is allowed to operate in, and review actions that got denied while Claude was running in one of its more automatic modes. It is the single place to see and shape what Claude is and is not allowed to do.
Where the rules live, and permission modes
Your rules are saved in a settings file (settings.json) so they stick around between sessions. There are a few levels: a personal setting that applies everywhere you work, a project setting shared with your team, and a local setting just for you on one project. A rule you set once keeps working the next time you open Claude Code.
On top of individual rules, Claude Code also has permission modes that set an overall posture for the whole session. A few of them:
Modes set the overall posture; individual allow, ask, and deny rules still apply within them.
Modes and rules work together. A mode sets the general stance, and your specific allow, ask, and deny rules fine-tune it. The goal is the same either way: let Claude run the routine, safe work automatically, while still gating anything that could cause real damage.
