Permissions are the safety rules that keep a powerful coding assistant inside boundaries you chose.

The plain-words definition

A permission is a yes-or-no decision about one action. Claude Code is about to read a file, edit a file, run a command, fetch a web page, or call an outside tool. For each action, the system asks: is this allowed automatically, does it need the user’s approval, or is it forbidden? The collection of all such decisions, together with the rules that produce them, is called the permission system.

Why a coding assistant needs them

Most programs do only what their buttons allow. A coding assistant is different, because it can combine small actions into big effects. Reading a file is harmless, but editing many files can break a project, and a single terminal command can delete a folder, install software, or send data across the internet. Permissions exist so that the small harmless actions can flow freely while the powerful ones get your attention.

Claude Code acts through tools, and permissions are attached to tools according to how risky they are.

What is a tool?

In Claude Code, everything Claude does in your environment happens through a tool. There is a tool for reading files, a tool for searching, a tool for editing, a tool for running terminal commands, a tool for fetching web pages, and others. When Claude wants to do something, it asks to use a tool with specific inputs. The permission system looks at that request and decides what to do.

A ladder of risk

Tools are not equally dangerous. A helpful way to see them is as a ladder, from harmless at the bottom to serious at the top.

flowchart TD
  A["Request to use a tool"] --> B{"What kind of action?"}
  B -- "Look only: read, search, list" --> C["Lowest risk: usually allowed without asking"]
  B -- "Change files: edit, write" --> D["Medium risk: ask, or allow inside the project"]
  B -- "Run commands" --> E["Higher risk: ask unless the command is known safe"]
  B -- "Reach outside: web, network, outside tools" --> F["Highest variety: ask, or follow your rules"]
    

The ladder explains most of the default behavior. Looking at things is safe enough to allow freely. Changing files deserves a decision, because changes can be unwanted. Running commands is more serious because commands can do almost anything. Reaching outside the machine adds the risk of leaking data or pulling in untrusted content.

Out of the box, Claude Code is cautious. It reads freely and asks before it changes or runs things.

When you start Claude Code in its standard setup, it follows a careful default. Reading and searching within your project generally happen without interruption. When Claude wants to edit a file or run a command that is not already approved, it stops and shows you what it plans to do. You then choose whether to allow it. This is the safest everyday setting, and it teaches you how Claude works.

What an approval prompt tells you

An approval prompt is a small window of information. It names the tool, shows the specific input, such as the file to edit or the command to run, and offers choices. Typical choices are to allow this one time, to allow this kind of action from now on, or to refuse and tell Claude to try something else. Reading the prompt is the heart of the system, because it is the moment when you check what is really about to happen.

Learning from the prompts

Treat your first week of approvals as a free lesson. Each prompt shows you what Claude considers necessary to do your task. Over time you will notice patterns: it often runs the tests, checks the version control status, and searches for names. These repeated, low-risk actions are natural candidates for allow rules. The unusual prompts, such as a command you do not recognize or a file outside the project, are the ones deserving a pause. The skill you are building is the ability to tell routine from surprising at a glance.

A mode is a quick setting that changes how much Claude Code does without asking.

Instead of editing rules for every situation, you can switch the overall mode of a session. Modes are like gears in a car: each suits a different road. The set of modes and their names can change between versions, so treat the table below as a guide to the idea and check the documentation for the current list.

flowchart LR
  A["Plan only: think, no changes"] --> B["Default: ask for edits and commands"]
  B --> C["Accept edits: edits flow, commands asked"]
  C --> D["Bypass all checks: no questions asked"]
    

Choosing a mode

Think about the stakes and the reversibility. If your work is under version control and you can inspect and undo changes easily, allowing edits to flow can be comfortable. If you are exploring an unfamiliar codebase, plan-only mode lets Claude study and propose without touching anything. If the project is sensitive, stay with the default and add rules. The last mode, which skips all checks, removes your safety net entirely. It is meant for isolated, throwaway environments such as a container that can be destroyed, never for your everyday machine with real credentials.

Rules are standing decisions that save you from answering the same prompt again and again.

Modes are broad. Rules are precise. A rule names a tool, and optionally a pattern describing exactly what it applies to, and states what to do: allow it, ask about it, or deny it. For example, you might allow running the project’s test command, ask before any command that installs software, and deny reading your secrets file.

Which rule wins?

When more than one rule could apply, a simple order of strength decides. A deny rule beats an ask rule, and an ask rule beats an allow rule. This means a specific refusal always holds, even if another rule is generous. It is the same logic as a building where “staff only” on one door overrides a general welcome sign in the lobby.

Patterns: narrowing a rule

A rule can be broad, such as “any file read”, or narrow, such as “reading files in one folder only”, or “running only commands that begin with a given word”. Patterns often use wildcards, which are symbols that stand for “anything here”. The art of writing rules is to be narrow enough to be safe and broad enough to be useful. A rule that allows only the exact test command is safe but may need a companion for a variant. A rule that allows any command beginning with a common word may allow far more than you intended.

Keeping rules readable

Rules are read by people as well as by the program. Keep the list short, group similar rules together, and prefer many clear rules over one clever pattern that nobody can decode. When a rule exists for a reason that is not obvious, write the reason in your team notes. A policy that a new teammate can understand in ten minutes is far more likely to be kept up to date, and far less likely to hide a gap.

The same rule can apply to just you, to one project, to your whole team, or to a whole company, depending on where it is stored.

Claude Code reads its settings from several places, called scopes. Each scope has a different reach. Understanding them tells you where to put a rule and which one wins when they differ.

flowchart TD
  A["Managed policy: set by administrators, strongest"] --> B["Command-line options for this session"]
  B --> C["Local project settings: personal, this project"]
  C --> D["Shared project settings: team, this project"]
  D --> E["User settings: personal, all projects"]
    

The picture shows a chain of authority. An organization’s managed policy sits at the top and cannot be overridden by an individual. Below it, options you give for one session take priority over stored files. Among stored files, those closer to the specific project win over your general ones. Because the exact order is a detail that could change, confirm it in the documentation before relying on it for something critical.

Which scope for which rule?

You can adjust permissions as you work, instead of editing files by hand.

Claude Code gives you a way to view and change permissions from within a session. A dedicated command opens a screen listing your current allow, ask, and deny rules, and lets you add or remove them. There is also a quick way to cycle through modes during a session, so you can move from careful to fast and back again as the work changes. The exact commands and keys can change, so check the documentation or the in-product help for the current ones.

The “always allow” choice

When an approval prompt offers to allow an action from now on, it is creating an allow rule for you. This is convenient, and also the main way that permissions quietly grow. A rule made in a hurry on a Tuesday can still be there a year later, allowing something you have forgotten. Treat “always allow” as a real decision. Ask yourself whether you would be comfortable if this action ran every time, in any project covered by that rule.

A healthy review habit

When the prompts become noise

If you are being asked dozens of questions in a session, something is out of balance. Either the rules are too tight for the work you do, or the work is too varied for a single setting. Do not respond by turning everything off. Instead, note which prompts are repeated and harmless, turn exactly those into narrow allow rules, and keep the rest. Fewer, more meaningful prompts mean you read each one, and reading each one is what makes the system safe.

Claude Code normally works inside the folder where you started it, and that boundary is part of its safety.

When you start Claude Code in a project folder, that folder becomes its home base. File edits are generally limited to this working area and its subfolders. If Claude wants to go beyond, to a neighboring project, your home folder, or a system location, it usually needs your explicit permission. This keeps a task about one project from wandering into unrelated parts of your computer.

Adding more folders on purpose

Sometimes you genuinely need more than one folder, such as a shared library next to your main project. You can add extra directories to the session, which makes them part of the allowed area. Do this deliberately and only for the folders you need. Each added folder widens what Claude can read and change.

Start in the right place

A common mistake is to start Claude Code in a very high-level folder because it is convenient. That folder becomes the boundary, and everything below it is in reach, including old projects, downloads, and private files. Start as deep as the task allows. A smaller boundary is easier to reason about and safer if anything goes wrong.

The most valuable use of deny rules is to keep sensitive files completely out of reach.

Every project has files that Claude does not need and should not see: environment files with passwords, private keys, token files, local configuration for services, and folders of customer data. Reading is usually allowed freely, which is why a deny rule on these files matters. If Claude cannot open them, their contents cannot end up in a conversation, a log, or a message to an outside service.

What to protect

Reading is not the only risk

A good secret-protection policy denies reading and editing. It also pays attention to commands, because a command can read a file even when the file-reading tool is blocked. If shell access is allowed, a denied file might still be reachable by a command that prints it. So pair file-level denies with careful command rules, and with sandboxing, which we discuss later, for stronger protection.

Keep secrets out of the project in the first place

The strongest protection is not to have secrets lying in the project folder at all. Where possible, load credentials from a secure store at the moment they are needed, give them narrow rights, and rotate them on a schedule. Deny rules are a safety net, not a license to leave keys in plain files. If a secret has ever been exposed to a conversation or committed to a repository, treat it as compromised and replace it.

Running commands is the most flexible and most dangerous thing Claude Code can do, so it needs the most careful rules.

Why commands are special

A terminal command can do almost anything the user can do: read any file, change any setting, install software, contact the internet, or delete everything. Because of this breadth, it is not enough to say “allow commands” or “deny commands”. Rules need to be specific about which commands, and with what arguments.

Safe, careful, and dangerous commands

The trouble with wildcards and chains

Command rules often use a prefix match: allow any command that begins with a certain word. This is convenient, and it can be too generous. A rule that allows “anything starting with a common tool” may also allow variants with dangerous options. Commands can also be chained together on one line, so a harmless-looking first part can be followed by something harmful. Good systems look at the pieces of a chained command, but you should still write rules defensively and keep risky commands behind approval.

Reaching out to the internet brings in outside content and opens a path for data to leave.

Claude Code can fetch web pages and search the web when allowed. These abilities are useful for reading documentation or checking an error message. But they also raise two worries. First, the content that comes back is not under your control and may contain text designed to mislead an AI. Second, a network connection is a way for information to leave your machine.

Controlling where Claude may go

Permissions for web access can be set per site or domain. A good starting policy allows a short list of trusted documentation sites and asks about anything else. Where company rules are strict, an administrator can restrict network access to an approved list. Commands that use the network, such as downloads or uploads, should be treated with the same care as web tools.

Connected tools extend Claude Code’s reach, and each one needs its own permission decisions.

Claude Code can connect to outside tools through the Model Context Protocol, known as MCP. These might be an issue tracker, a database, a code host, or a monitoring service. Each connected tool offers its own set of abilities, and they are covered by the same permission ideas: allow, ask, and deny. A tool that reads information is lower risk than one that creates, changes, or deletes things in a real system.

Rules at several levels

Permissions can usually be set for a whole connected server or for individual tools within it. This lets you allow the harmless read tools and keep the write tools behind approval. For example, you might allow searching tickets freely while asking each time before a ticket is closed or a database record is changed.

Choose servers carefully

An MCP server is software that acts on your behalf. Install only servers from sources you trust, review what they can do, and keep them updated. A shared project can list the servers the team uses, which is helpful, yet each person should understand what they are enabling. Remove connections you do not use.

When nobody is there to answer a prompt, permissions must be settled in advance.

Helper agents

Claude Code can start helper agents, often called subagents, that handle part of a task separately. Helpers work under the permission rules of the session, and they may also have their own limits on which tools they can use. Giving a helper only the tools it needs, such as read and search for a reviewer, is a strong way to keep power low where it is not needed.

Running without a person present

Claude Code can also run in a non-interactive way, for example inside an automated pipeline, a scheduled job, or a script. There is no person to answer an approval prompt, so anything that would need approval will either be refused or will stop the run. This is why automated runs need their permissions decided ahead of time through rules and options, and why they should have very narrow rules.

Matching tools to the helper’s job

A good rule for helper agents is that their power should match their job. A reviewer needs to read and search, so it should not be able to edit or run commands. A test runner needs to run the test command, so it does not need web access. A documentation helper may need the web but not your source files. Writing each helper’s job description narrowly makes the whole system easier to reason about and far safer when something misbehaves.

Hooks let you attach your own checks to Claude Code’s actions, going beyond fixed rules.

Rules are good at simple decisions. But some policies need more thought: block any command that touches production, require a ticket number before a commit, or run a scanner before a file is saved. A hook is a small program you attach to a moment in Claude Code’s work, such as just before a tool runs or just after it finishes. The hook can inspect what is about to happen and approve it, block it, or add a message for Claude to read.

What hooks are good for

Rules and hooks together

Think of rules as the simple signs on the door and hooks as the guard who can think. Rules are fast, predictable, and easy to read. Hooks can express policies that rules cannot, but they are code that you must write, test, and maintain, and they run with your permissions. A buggy hook can fail to protect you or can block valid work. Keep hooks small, test them on safe examples, and treat them like any other security-relevant software.

Permissions decide what Claude Code may attempt. A sandbox limits what any command can actually reach.

The difference between a rule and a wall

A permission rule is a decision made by the program: it looks at a request and says yes or no. A sandbox is different. It is a restricted environment enforced by the operating system, in which the commands run. Inside it, a command simply cannot touch files outside allowed folders or connect to forbidden network locations, no matter how it is written. Rules are a guard at the door. A sandbox is the wall around the building.

flowchart TD
  A["Claude proposes a command"] --> B{"Permission rules"}
  B -- "Deny" --> C["Blocked"]
  B -- "Ask" --> D["You decide"]
  B -- "Allow" --> E["Command runs"]
  D -- "Approve" --> E
  D -- "Refuse" --> C
  E --> F{"Sandbox boundary"}
  F -- "Inside allowed folders and network" --> G["Works as normal"]
  F -- "Outside the boundary" --> H["Stopped by the operating system"]
    

The diagram shows defense in depth. A request first meets the permission rules. If it passes, it runs, but inside a sandbox, so a mistake or a cleverly disguised command is still contained. Even an approved command cannot reach the folders or network addresses outside the boundary.

What a sandbox adds

Companies can set rules that individual developers cannot loosen.

In a company, the safety of a coding assistant is not only a personal matter. The organization has duties to protect customer data, source code, and its own systems. For this reason, administrators can deploy managed settings that sit above personal and project settings. These can set mandatory deny rules, restrict which tools and servers may be used, and limit which permission modes are allowed.

What organizations usually decide

Working well with policy

If you are a developer and a setting is locked, treat it as a boundary set for good reasons. Ask the platform or security team if you need something changed, and explain the task. Often there is an approved path, such as a sandboxed environment where more freedom is allowed. If you are an administrator, keep the policy small, clear, and explained. Rules that people understand are followed. Rules that look random are worked around.

Communicating policy to developers

Policy works best when people understand it. Publish a short page that says what is blocked, what is allowed, and why. Give a clear route for requesting an exception, and answer requests quickly. Share stories of problems that the policy prevented, in general terms, so the rules feel purposeful and not arbitrary. When developers see policy as a partner, they bring concerns early, and the policy improves.

Understanding the threats shows why each rule is worth having.

The risky trio

Security specialists point to a dangerous combination: access to private data, exposure to untrusted content, and the ability to send things out. When all three are present in one session, a hidden instruction in an untrusted file could lead to private information being sent away. Permissions let you break the chain. You can deny access to private data, avoid fetching untrusted pages in sensitive sessions, or require approval for anything that sends data out.

Open unknown projects with care

When you open a project you did not write, such as one downloaded from the internet, remember that it may carry its own settings and scripts. Claude Code usually asks whether you trust a folder before applying its configuration. Read that question seriously. Review unfamiliar projects first, and for anything doubtful, work inside a disposable environment.

Good permissions are visible permissions. You should be able to see what was allowed, what was refused, and what actually ran.

Without records, nobody can answer simple questions after an incident: what did Claude run, which files did it change, which approvals were given, and by whom? Records also reveal where permissions are too tight, causing constant prompts, or too loose, allowing risky actions without anyone noticing.

What to keep track of

Useful measures

Version control is the most important log of all. If Claude’s changes are always committed in small steps with clear messages, you can see exactly what happened and roll back any step. Teams can also use hooks to write their own audit logs of commands and approvals. Protect those logs, because commands and paths can themselves contain sensitive information.

Reviewing after an incident

If something goes wrong, use your records to reconstruct the order of events. Which prompt appeared, who approved it, which rule allowed it, and what ran afterward? Then ask what single change would have prevented it: a deny rule, a narrower allow, a sandbox setting, or a hook. Make that change, and write a short note about it. Treat each incident as a free lesson that makes the next session safer.

A good policy is a few clear decisions, matched to your risk, and reviewed regularly.

A step-by-step method

Starter policies by situation

A few habits produce safe and pleasant sessions, and a few mistakes cause most of the trouble.

Most surprises come from rules clashing, a wrong scope, or an unexpected mode.

A calm approach

Start by asking which scope each rule lives in, since the answer often explains a surprise. Then recall the order of strength: deny, then ask, then allow. Finally, test on a safe project with a very simple action. Change one thing at a time and write down what you changed, so you can undo it. If you are in a company environment, remember that managed policy may be the cause, and ask your administrator.

Six examples show permissions chosen well.