Claude Code for a team, what is shared, what is imposed and what is enforced

Sixty people use Claude Code across five repositories and each one configured it their own way: some approve every command, others allowed any shell command and a few let Claude read .env files with production credentials. Project conventions live in personal notes, so Claude behaves differently depending on who opens it. The problem isn’t the tool: it’s where each rule lives.

Four places, four scopes

File	Who it affects	What for
Managed settings	the whole organization it’s deployed to	security and compliance policies nobody can override
.claude/settings.json in the repo	everyone working on the project, once committed	team permissions, hooks and plugins
.claude/settings.local.json	you, in that project	personal exceptions; kept out of git
~/.claude/settings.json	you, in all your projects	personal preferences

On top of that is the project’s CLAUDE.md, committed to the repo, with the conventions Claude needs to know: how tests are run, the structure, the style rules.

Settings precedence, from highest to lowest, is: managed, command line, project local, shared project and user. A key at a higher level overrides the same key further down. Nothing in a person’s files, not even a session flag, overrides a managed key. Lists, such as permission rules, are merged across levels instead of replaced.

Context isn’t control

CLAUDE.md is context the model reads at the start of every session and usually follows, but it isn’t configuration that gets enforced. A line saying “NEVER edit already-applied migrations” will be respected almost always, and in a long refactoring session it may not be.

For an action to be blocked every time, without depending on what the model decides, you use a deterministic control:

• Deny rules in the permissions, for example for reading .env or editing a folder.
• A PreToolUse hook, which checks every call before it runs and blocks it if it violates the policy.

If the rule belongs to the team, it goes in the shared project settings. If it belongs to the organization and nobody may disable it, it goes in managed settings.

A reasonable split

• Organization: deny rules for secrets and sensitive paths, limits on allowed models, non-negotiable policies.
• Project: permissions for the usual commands (tests, lint), team hooks and a CLAUDE.md with the conventions.
• Person: theme, editor, default model, their own approvals for that repo.

The usual traps

• Giving everyone the mode that skips permissions (bypassPermissions) “so the differences stop mattering”. Besides, that mode doesn’t take effect from project settings.
• Publishing a wiki snippet and asking everyone to paste it into their personal settings: it isn’t versioned and can’t be verified.
• Putting security rules in settings.local.json: it’s personal and stays out of the repo.
• Rewriting the CLAUDE.md rule in capitals or repeating it in every folder.
• Relying on auto memory so Claude “remembers” the incident.

In the exam

If the scenario describes different configurations per person, look for the combination: shared settings and CLAUDE.md committed to the repo for team rules, and managed settings for what nobody may disable. If a rule written in CLAUDE.md was broken, the answer is a deterministic control (deny rules or a PreToolUse hook) in the shared settings, not more emphatic wording.