CLAUDE.md and settings.json Scopes in Claude Code

1.Four places a CLAUDE.md can live

CLAUDE.md is how you give Claude standing instructions. It is a plain file you write, and Claude Code loads it at the start of every session. Auto memory is a separate mechanism: there, Claude writes the notes itself from your corrections. With CLAUDE.md, the configuration question is where you put the file, because the location decides who shares the instruction.

Project instructions are the team's copy, so you commit them. Local instructions hold personal, project-specific details such as sandbox URLs or preferred test data, and they belong in .gitignore. Write every instruction so it can be checked: 'Run npm test before committing' works, while 'Test your changes' leaves Claude guessing. When one file gets too big, a CLAUDE.md can pull in other files with @path imports, and you can split rules into .claude/rules/. A rule file can use a paths glob so it applies only to matching files:

---
paths:
  - "src/api/**/*.ts"
---

# API Development Rules

- All API endpoints must include input validation
- Use the standard error response format
- Include OpenAPI documentation comments

Sources1

2.When AGENTS.md loads instead of CLAUDE.md

By default, Claude reads only your CLAUDE.md files. It falls back to AGENTS.md only when there is no CLAUDE.md, .claude/CLAUDE.md or CLAUDE.local.md in the working directory or any directory above it. Some files don't count toward that check, and they keep loading alongside AGENTS.md: your user file, the managed file, and rules files. If a CLAUDE.md imports AGENTS.md, you get both, and the AGENTS.md content arrives through the import.

Sources1

3.Managed CLAUDE.md versus managed settings

The managed-policy CLAUDE.md is how IT or DevOps pushes instructions to every developer in the organization. You deploy it with your configuration management system. It is still only an instruction to Claude, though, and it is not a technical control. The documentation separates the two jobs. Anything that has to be enforced goes in managed settings. Anything that shapes Claude's behaviour goes in the managed CLAUDE.md.

Sources1

4.settings.json scopes and precedence

Permissions, hooks, plugins, environment variables and the default model are configured in settings.json, not in CLAUDE.md. Settings use the same layering: a user file, a shared project file, a project-local file and managed sources. The shared file at .claude/settings.json only reaches teammates after you commit it. Until then it is a file on your own disk.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Claude Code writes the local file itself. When you answer 'Yes, and don't ask again' to a Bash permission prompt, the approval is saved there as an allow rule. The first time it writes that file inside a git repository, it adds **/.claude/settings.local.json to your global git excludes. If you create the file by hand before that happens, you have to add it to .gitignore yourself. Levels merge key by key: a higher level wins on any key it sets, and a key it leaves out keeps the value from the level below.

Sources2

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Putting 'never push to main' in the managed CLAUDE.md technically stops Claude from pushing to main.Why is that wrong?

   A managed CLAUDE.md only carries behavioural instructions. To block a command outright, use managed settings with permissions.deny.

   Covered in Managed CLAUDE.md versus managed settings

2. 2.When a repository has both AGENTS.md and CLAUDE.md, Claude Code reads both by default.Why is that wrong?

   The default is claude-md-or-agents-md: once a CLAUDE.md or CLAUDE.local.md exists, only the CLAUDE.md files load, unless CLAUDE.md imports AGENTS.md or you change instructionFiles.

   Covered in When AGENTS.md loads instead of CLAUDE.md

3. 3.Passing a key with --settings on the command line overrides the same key in managed settings.Why is that wrong?

   Command-line settings rank above user, project and local files but below managed settings, so a managed key always wins.

   Covered in settings.json scopes and precedence