Claude Code settings.json: The Config I Put in Every Project

Here is the whole answer up front. settings.json is Claude Code's configuration file. It sets what Claude is allowed to do without asking, what it can never do, which shell commands run automatically on events, which model runs by default, and what environment variables it sees. There are three locations and they stack: ~/.claude/settings.json applies to every project on your machine, .claude/settings.json lives inside a project and is checked into git so your team shares it, and .claude/settings.local.json sits beside it for personal overrides that stay out of the repo. The more specific file wins. Get this one file right and every session starts the way you want, instead of you re-approving the same commands and hoping the defaults are sane.

The permissions key is the part that pays for itself in a day. It takes three lists: allow, ask, and deny. Anything in allow runs without a prompt, so you stop clicking approve on the same safe commands you have run a thousand times. Anything in deny can never run, no matter what the model decides it wants. ask forces a confirmation. The rule I follow is simple: allow the read-only and cheap-to-reverse commands, deny the ones that can lose work or leak, and let everything else fall through to a prompt.

The hooks key lets you attach a shell command to an event - before a tool runs, after a tool runs, when a session starts. This is how you make Claude Code enforce your standards instead of just following them when it remembers. I use a hook to run the formatter and type check after any edit, so a broken build gets caught the moment it happens rather than three prompts later. A hook is deterministic: the harness runs it every time, which is exactly what you want for the checks that must never be skipped.

Two smaller keys punch above their weight. model pins the default model for that project, so a heavy codebase can default to your most capable model while a scratch repo runs something lighter, and you never have to remember to switch. env sets environment variables for the session, which is how you hand Claude the flags and paths a project needs without exporting them by hand every time. Both live in the project settings.json, so they travel with the repo - a teammate who clones it gets the same behavior you do.

Here is the pattern, not a copy-paste dump, because the exact commands depend on your stack. My baseline settings.json always has four things: a permissions.allow list of the read and test commands I trust, a permissions.deny list that blocks force pushes, recursive deletes, and reads of any env or secrets file, a hook that formats and type-checks after every edit, and a pinned model. I keep it in a template and drop it into a new project before I write a single line, the same way I keep a base prompt. The point is not my exact lists - it is that the first session in every repo is already safe, quiet, and consistent, so I am building instead of babysitting.