Which Claude Code settings file wins and why one is ignored

You set the model in your settings, and Claude Code uses another one. You turn something off, and in one project it is still on. Almost always, another settings file is winning. This lesson explains the order and shows how to find the file that decides.

#Know the four files

Open Settings in Config Studio for Claude Code and then Where it lives. It lists every file, highest precedence first:

The rule: the more specific file wins, and a managed policy beats everything. Flags you pass on the command line also beat the local and project files for that run.

People often expect the opposite (that their own user file is the final word). It is the weakest one. That is by design: a project can require settings, and an organisation can enforce them.

#Set the values that are not rules

The Settings surface holds the values that are not permission rules. It is grouped, and starts empty on purpose: only what you set is written, so exporting never overwrites a value you did not touch. Some keys:

• model: which model answers by default
• theme: the colour scheme
• effortLevel: how much reasoning it spends before answering
• attribution: the co-author line it adds to commits and pull requests, or false for none

Every key has its explanation and a badge for where the fact comes from.

#Find out which file is deciding

Open Try it and pick Which file is deciding this? Type the setting you are asking about, and paste what each of the four files contains for it. The answer says which file won, what it shadowed, and what was ignored.

Try it with model set in both ~/.claude/settings.json and .claude/settings.json: the project file wins in that project.

#Know which settings combine

Not every setting is simply overridden. Permission lists combine: a deny in your user file and an allow in the project file are both active, and the deny still beats the allow. Which file is deciding this? says which behaviour applies for the key you ask about.

#Know which settings only count in some files

The other reason a setting does nothing: it is in a file that key does not count in. Claude Code does not override it there, it ignores it.

• A few keys only work in a managed policy, such as allowManagedHooksOnly, deniedModels and claudeMd.
• A few only work in your user file or a managed policy, such as processWrapper and prependPlugins. In a project or local file they are ignored.
• Most keys, availableModels and allowedMcpServers among them, work in any file.

Which file is deciding this? knows each key's files, so it says "ignored" rather than "lost" when that is what happened. What is actually set up here? warns when a folder sets a key where it does not count.

#See what a real folder leaves open

What is actually set up here? reads a real .claude folder in your browser, your own or a project's, and reports what is configured and what that leaves open. Use it on a repository you just cloned: a project's settings apply to you as soon as you work in it.

#Put each setting in the right place

A simple rule of thumb:

• Your personal taste (theme, your favourite model) goes in ~/.claude/settings.json
• What the whole team needs (shared allow rules, the formatter hook) goes in .claude/settings.json, committed
• Your exceptions for one project go in .claude/settings.local.json, which git should ignore

The next lesson is about the other file Claude Code reads every session: CLAUDE.md.