Where each instruction goes in Claude Code, CLAUDE.md and settings.json

On a team of six, everyone explains the same conventions to Claude in their own words, and after two months each machine has a different version. The problem isn’t the model: the instructions are in the wrong place. Almost every question in this domain is solved by knowing which file each thing goes in and who receives it.

The CLAUDE.md hierarchy

The CLAUDE.md hierarchy has four levels:

File	Who receives it	What it’s for
Managed policy CLAUDE.md (deployed by the organization)	Everyone in the organization	Company standards and policies
./CLAUDE.md or ./.claude/CLAUDE.md	The team, through git	Architecture, build and test commands, conventions
./CLAUDE.local.md	Only you, in this project (it goes in .gitignore)	Your test URLs, your sample data
~/.claude/CLAUDE.md	Only you, in all your projects	Personal preferences

Three details that earn points:

• The files don’t override each other: they are concatenated into the context, and whatever is closest to the working directory is read last.
• For large projects, .claude/rules/ splits the instructions by topic and can scope them to certain paths, so they only load when needed.
• For repository initialization, /init analyzes the code and generates a starting CLAUDE.md with commands and conventions; you refine it by hand afterwards.

The settings.json hierarchy

Settings work the same way, but here there is precedence: when the same key appears in several files, the highest level wins.

1. Settings managed by the organization: nobody overrides them.
2. Command line (--settings), for that session only.
3. .claude/settings.local.json: the project local settings, personal and out of git.
4. .claude/settings.json: the shared project settings, which are committed.
5. ~/.claude/settings.json: your settings for every project.

allow, ask and deny permission rules from different files are combined instead of replaced, and a deny rule blocks even if another rule allows it. If the team needs common rules and one person needs a personal exception, the common rules go in .claude/settings.json and the exception in that person’s .claude/settings.local.json.

Context or control

The distinction that gets asked the most:

• CLAUDE.md is context. Claude follows it almost always, but it isn’t guaranteed.
• settings.json is control. A deny rule or a hook always applies, whatever the model decides.

If the requirement says “never”, the answer is not to rewrite CLAUDE.md with more emphasis.

The usual traps

• Team conventions in each person’s ~/.claude/CLAUDE.md: they aren’t versioned and drift apart.
• Personal notes in the project CLAUDE.md, which reach everyone.
• Personal exceptions committed to the shared .claude/settings.json.
• Granting full permissions “so it stops asking” instead of narrow allow rules.
• Relying on a prohibition written in CLAUDE.md for something destructive.

On the exam

Identify the scope the scenario asks for: the whole team, one person in this project, or one person in all their projects? That gives you the file. Then check whether the requirement is a preference (CLAUDE.md is enough) or a guarantee (permissions or hooks in settings.json).