PRODUCTION SCENARIO
A team needs rules that deny access to production configuration files in every clone of the repository. They have no administrator channel for deploying policy, so whatever they write has to travel in the repository itself. One engineer also wants Claude to start on a different model, but only in this repository and only for their own sessions: teammates keep the model the team already uses, and the engineer's other projects are unaffected.
Which configuration split fits both needs?
Answering here is anonymous. Nothing is saved unless you sign in.
Show answer and explanation
Answer: Deny rules in .claude/settings.json, the model in .claude/settings.local.json
The committed project file is what travels with a clone, so the deny rules reach everyone, and the project-local file is the engineer's own settings for this one project, which Claude Code keeps out of git. Putting the model in the committed file is right when the team wants a single shared default, and here teammates keep theirs. Keeping both in the user file is right when the rules are one engineer's own preference for their machine, and then no teammate gets deny rules. Managed settings are the right home for policy contributors must not be able to edit, and this team has no way to deploy them; a user-level model would also follow the engineer into every other project.
Official Source: https://code.claude.com/docs/en/settings ↗