Claude Code Settings and Permissions, Explained

TL;DR

• Claude Code settings live in a settings.json file at the project or user level.
• You control what Claude can do with three permission modes: allow, ask, and deny.
• You can allowlist specific tools so Claude never has to stop and ask.
• Safe defaults keep Claude cautious until you tell it otherwise.
• Get these right once and Claude stops interrupting you mid-task.

Claude Code settings control what the agent can and cannot do on your machine. If you have ever had Claude stop mid-task to ask if it can run a command, that is a permissions question. Get the settings right and you get a much smoother build session.

This post walks through the settings.json idea, how the three permission modes work, how to allowlist tools you trust, and what safe defaults to start with. If you are just getting started, read the Claude Code complete guide first.

Where do Claude Code settings live?

Claude Code reads from two settings files. One is global. One is project-specific.

The global file sits at the .claude folder in your home directory. It applies to every project you open. The project file sits at .claude/settings.json inside your repo. It applies only to that project and overrides the global file where they conflict.

You can also have a settings.local.json file in your project. That file is for personal overrides you do not want committed to git. Add it to your .gitignore.

The files are plain JSON. You do not need a special editor to change them. You can write them by hand or let Claude write them for you. If you want to share consistent settings across a team, commit the project settings.json and leave personal tweaks to settings.local.json.

Settings files are just JSON. If you can edit a config file, you can tune Claude Code.

---

What are the three permission modes?

Every tool Claude can use sits in one of three modes. These are the core of how Claude Code settings work.

Allow means Claude runs the tool without asking. It just does it. Use this for tools you trust completely, like reading files or searching with grep.

Ask means Claude stops and asks you before running the tool. You approve or deny each time. This is the default for anything that writes, deletes, or runs code.

Deny means Claude cannot use the tool at all. It will not ask. It will not try. It just skips it. Use this for tools you never want Claude touching.

The default out of the box is conservative. Most destructive actions are set to ask. Some are denied entirely. That is intentional. You build trust with the tools over time and loosen the rules as needed.

You can set permissions globally or per-tool. A global allow means Claude runs everything without asking, which is fast but risky on a shared machine. Per-tool rules give you fine control. In settings.json the rules live under a permissions key, with an allow list, a deny list, and anything not listed defaulting to ask.

---

How do you allowlist specific tools?

Allowlisting means putting a tool in the allow list so Claude never pauses to ask permission for it.

Good candidates for allowlisting are read-only actions. Things like reading files, listing directories, running grep searches, and checking git status are safe to allow. They do not change anything on your machine.

Tools that write files, run shell commands, or make network requests deserve more thought. You might allow some of them at the project level once you know the project well. But start with ask for anything that modifies state.

To allowlist a tool, add it to the allow array in your settings.json. The tool names follow a pattern: built-in tools use names like Read, Write, and Bash, and MCP tools use the format mcp then the server name then the tool name. To let Claude read files and use bash without asking, you put Read and Bash in the allow array. To block the computer-use tool entirely, you put it in the deny array.

If you use MCP servers, see the Model Context Protocol guide for how MCP tool names work in permission rules.

Allowlist read-only tools first. Add write access one tool at a time as you build confidence.

---

What are safe defaults to start with?

Safe defaults mean Claude has to ask before it does anything that changes your system. That sounds annoying, but it saves you from Claude running a command you did not mean to approve.

Here are the defaults worth setting on any new project.

Set Bash to ask. Shell commands are powerful. You want to see what Claude is about to run before it runs. Once you are comfortable with a project, you can move specific bash patterns to allow.

Set Write to ask. Same logic. Claude writing files is fine, but you want to see the diff first on anything important.

Set Read to allow. Reading files is harmless. Letting Claude read without asking speeds up every single task.

Set web search and web fetch to ask by default. Network requests can expose data or pull in content you did not intend. Ask keeps you in control.

Deny anything you never use. If you are not using computer-use or a specific MCP server, deny it explicitly. It removes the surface area.

The goal is to get to a state where allow covers your trusted daily actions, ask covers anything with side effects, and deny covers things you do not want at all. At Devwiz we set up project-level settings.json files as part of every Claude Code deployment. It takes ten minutes and saves hours of interruptions.

---

How do project and user settings interact?

The project settings.json overrides the global one where they conflict. If your global settings allow Bash but your project settings deny it, the project wins.

This is useful for projects with stricter requirements. A client project might have tighter rules than your personal experiments. You can set conservative project-level rules without changing your global setup.

The settings.local.json file adds a third layer on top of the project file. It applies last and overrides everything. Use it for your personal preferences on a shared project without pushing those changes to the team. If something is not working the way you expect, check all three files. The order is global, then project, then local. For more on how memory and configuration interact across sessions, read Claude Code memory explained.

---

What happens when Claude hits a denied tool?

Claude does not crash. It does not error. It tells you it cannot use that tool and explains why.

If the tool is set to ask, Claude stops and shows you the request. You approve or deny it in the moment. If you deny it once, Claude tries to find another way. If you approve it, Claude continues.

If the tool is in the deny list, Claude skips it entirely. It will tell you the tool is unavailable and either ask for an alternative approach or explain what it would have done if it had access.

This matters for understanding Claude's behaviour. If Claude seems to be working around something or producing unexpected results, check your deny list. You might be blocking a tool Claude needs to do the job properly. For a walkthrough of day-to-day use, see how to use Claude Code.

Denied tools do not break Claude. They just change how it works around the problem.

---

FAQ

What is the difference between settings.json and settings.local.json?
settings.json is committed to your repo and shared with the team. settings.local.json is personal and should be in .gitignore. Local overrides project, which overrides global.

Can I allow a tool for one project but deny it globally?
Yes. Project settings override global settings. Set a tool to deny in your global file and allow it in a specific project's settings.json. The project rule wins.

What tool names do I use in the permissions list?
Built-in tools use PascalCase names like Read, Write, Bash, Glob, Grep. MCP tools use the format that joins the server name and the tool name. Check the Claude Code docs for the full list.

How do I know which tools Claude is trying to use?
Claude shows you tool calls in the conversation as it works. If a tool is set to ask, you see the exact request before approving. If you want a log, run Claude Code with verbose output enabled.

---

Getting your Claude Code settings right is a one-time investment. Do it at the start of a project and Claude stops interrupting you. Allowlist what is safe, keep ask on anything with side effects, and deny what you never need.

If you want Claude Code set up properly inside your business from day one, book a free AI transformation call and we will walk through the setup with you.