A Rule for You, Not Your Team: Local vs Shared Claude Code Settings

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 25)

▶ Watch on YouTube & subscribe to The Stack Underflow

You’ve got a personal habit: you always want Claude Code to write commit messages in a particular style, or you always want it to prefer rg over grep when it searches. It’s not a team rule — nobody else asked for it, and forcing it into every repo’s shared config would be presumptuous at best and annoying at worst. But you want it everywhere you work, on every repo you touch, without re-typing it into every session. Where does that rule live?

This is CCA practice question 2 of 10 in the Domain 3 “Agent Operations” set — Claude Code Configuration & Workflows, roughly 20% of the exam. Pause when prompted, pick an answer, then check the mechanism, not just the key.

The one-sentence version: A rule that follows you across every project, but nobody else, lives in your user-level memory file, ~/.claude/CLAUDE.md — outside any repo, so it never gets committed and never reaches a teammate’s checkout.

The question

A rule should apply to you across every project, but not your teammates. Where?

• A) Each repo’s CLAUDE.md
• B) Your user memory ~/.claude/CLAUDE.md
• C) settings.json
• D) A hook

Pause the video (or just stop scrolling) and pick your answer before you read on.

The answer

B — your user memory, ~/.claude/CLAUDE.md.

The mechanism is the memory hierarchy. Claude Code doesn’t have one CLAUDE.md, it has several, layered by scope, and each layer answers a different question about who is supposed to be affected.

MEMORY HIERARCHY (broadest → narrowest scope of PEOPLE affected)

┌───────────────────────────────────────────────────────────┐
│ ENTERPRISE / MANAGED  — org-wide policy, IT-deployed        │
│   affects: everyone at the company, every repo              │
├───────────────────────────────────────────────────────────┤
│ PROJECT   ./CLAUDE.md  — committed to the repo               │
│   affects: everyone who clones THIS repo                     │
├───────────────────────────────────────────────────────────┤
│ USER      ~/.claude/CLAUDE.md  — lives in your home dir      │
│   affects: only YOU, but on EVERY repo you open              │
└───────────────────────────────────────────────────────────┘

        repo-A  ──┐
        repo-B  ──┼──►  all read the SAME ~/.claude/CLAUDE.md
        repo-C  ──┘      (it never lives inside any of them)

The load order matters less here than the location order. A project’s ./CLAUDE.md sits inside the repository — it’s a file in the working tree, it gets committed, and the moment a teammate pulls the branch, Claude Code reads it in their session too. There is no way to put a rule in a project’s CLAUDE.md and have it apply to you alone; the file doesn’t know who’s typing.

~/.claude/CLAUDE.md, by contrast, sits in your home directory — outside every git working tree. Claude Code merges it into context on every project you open, because it always checks the same fixed path relative to your user account, not relative to the repo. Your teammate has their own ~/.claude/CLAUDE.md (or none at all) sitting in their own home directory. The two files never touch, never merge across machines, and never get committed anywhere — there’s nothing to git add. That’s the whole trick: scope is determined by where the file physically lives, not by anything you write inside it.

So the rule in the question — “always write commit messages this way,” “always prefer rg,” “always sign off with my initials” — goes in ~/.claude/CLAUDE.md. It travels with you like a dotfile, the same way your .gitconfig or shell aliases do, and it shows up whether you’re in repo A this morning or repo C this afternoon.

Why the other options fail

• A) Each repo’s CLAUDE.md is the opposite scope. It’s the shared memory layer — anything you write there is version-controlled and reaches every collaborator on that repo the moment they pull. It also fails the “every project” half of the requirement: you’d have to hand-copy the same block into every repo you touch, and it would still leak to teammates in each one. Two failures for the price of one option.
• C) settings.json solves a different problem. Settings files (.claude/settings.json, .claude/settings.local.json) configure behavior and permissions — allowed tools, model defaults, hook wiring — not freeform instructions or context for the model to read. Even the personal variant, settings.local.json, is scoped to a single project directory; it doesn’t travel with you to a different repo the way user memory does. Right category of “personal,” wrong mechanism for “a rule.”
• D) A hook is for guaranteed, deterministic actions — run this shell command every time this event fires, no exceptions. A hook is what you reach for when you need the linter to run after every edit, not when you want to express a standing preference for the model to read and reason about. Using a hook to say “please write commit messages this way” is the wrong tool: you’d be scripting enforcement for something that’s advisory context, not automating an action.

The concept behind it

The pattern under this question generalizes past CLAUDE.md specifically: in Claude Code, scope is a property of file location, not file content. Every configuration surface — memory files, settings files, permission rules — follows the same logic: ask “who should this reach?” and the answer tells you which directory the file belongs in.

Notice the two “only you” rows split on a second axis: this repo versus every repo. .claude/settings.local.json is the right home for a personal tweak that’s specific to one project — a local port override, an experimental permission you don’t want to inflict on the team yet. ~/.claude/CLAUDE.md is the right home for a personal habit that has nothing to do with any particular codebase. Getting this distinction wrong is a common early mistake: engineers new to Claude Code often dump personal preferences into a project’s shared CLAUDE.md because it’s the file they see first, and then wonder why a teammate’s commits suddenly start following a style nobody agreed to.

The deeper exam-relevant idea, which the practice set calls out repeatedly across this domain, is that Claude Code’s configuration surface is intentionally partitioned along two independent dimensions: scope (who is affected — enterprise, project, or user) and mechanism (what kind of thing is being configured — remembered context via a memory file, enforced behavior via a hook, or tool/access rules via a settings file). Domain 3 questions are almost always really asking you to place a requirement correctly on this two-axis grid. A rule is context, so it belongs in a memory file. “Just you” is user scope, so it belongs at ~/.claude/CLAUDE.md. Once you see the grid, the individual file paths stop needing to be memorized — you can derive them.

One caveat worth sitting with: this domain tracks live product behavior, and Anthropic has changed exact paths, flags, and precedence details before. Treat the specific filename ~/.claude/CLAUDE.md as the current, verifiable answer as of this writing, and re-check it against the official Claude Code documentation before you rely on it for anything — the underlying mechanism (user-scoped memory lives outside the repo, travels with you) is the durable thing to remember.

FAQ

Does ~/.claude/CLAUDE.md override a project’s CLAUDE.md, or do they combine? They combine — Claude Code merges memory from all applicable layers into context, it doesn’t pick one and discard the rest. Enterprise, project, and user memory are additive by default; conflicts are resolved by the precedence order (higher scope generally wins on genuine contradictions), but in the common case you simply get the union of enterprise policy, team convention, and your personal preferences in every session.

Is ~/.claude/CLAUDE.md ever checked into any git repository? No, and that’s the point. It lives in your home directory, outside any project’s working tree, so there’s no repository to add it to. If you want to back it up or sync it across your own machines, that’s your dotfiles setup’s job — Claude Code itself won’t commit or share it anywhere.

What if I want a personal rule that applies to one project only, not all of them? That’s the settings-local case, not the user-memory case: .claude/settings.local.json is gitignored by convention and scoped to a single project directory. If you need personal context (not settings) scoped to one repo, some setups also support a personal, untracked memory override at the project level — but the moment “just me, everywhere” is the actual requirement, user memory is the correct answer, not a per-project workaround.

Why not just tell Claude the rule at the start of every session? You could, but you’d be re-typing it every session, in every repo, forever — and it would compete for space in your prompt every single time. A memory file is read automatically and persists without you doing anything; that’s the entire value proposition of the memory hierarchy over ad hoc chat instructions.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the CCA series

This is question 2 of the Domain 3 practice set on the Claude Certified Architect (CCA) Exam Guide — start there for all five domains on one diagram. It pairs directly with Where Does a Team Convention Live? Project CLAUDE.md Explained, which covers the sibling question — the shared half of the same memory hierarchy. From there, The Setting You Must Not Commit: settings.local.json in Claude Code covers the personal-but-project-scoped case this page had to rule out, and Instructions or a Hook — Which Runs Every Time? CLAUDE.md vs Hooks covers why option D — a hook — is the wrong tool for advisory rules like this one. If exam logistics matter to you right now (Pearson VUE, $125, retakes, 60 questions in 120 minutes, pass at 720/1000 across five domains as of mid-2026), verify the current numbers on Anthropic’s official pages before you register. Browse all tutorials for the rest of the series.