5 Reasons Claude Code Seems to Ignore Your CLAUDE.md

When Claude Code skips a rule you wrote in CLAUDE.md, the file is rarely broken. Usually the rule never loaded, lost to a conflicting rule, or was never something a context file could enforce. These are the five causes to check, in order.

1. The session started in the wrong directory

Claude Code loads CLAUDE.md and CLAUDE.local.md from the directory where the session starts and from every parent directory. A file in a sibling package does not apply just because it exists in the repository. Start in services/billing/ and the billing guidance is relevant. Start in apps/web/ and it is not.

2. The nested file has not loaded yet

Files below the working directory are not loaded at startup. They load when Claude reads files in that directory. If you start at the repository root and ask a question before Claude has opened anything in apps/web/, the web guidance is not in context yet. Run /context to see which memory files Claude Code reports as loaded.

3. Two files disagree

Loaded files are combined in order, from the root down to the working directory. A closer file adds more specific guidance, but it does not automatically win a contradiction. If the root says "update the lockfile" and a package file says "never change the lockfile", Claude has two instructions, not a rule. Give each rule one owner and write exceptions out in full.

4. The conflict sits in an import

A CLAUDE.md can pull in other documents. A stale rule in a referenced file behaves exactly like a stale rule in the main file, but it is harder to spot. Check every imported document and the .claude/rules/ folder in each relevant directory, not only the top-level file.

5. The rule needed enforcement, not guidance

CLAUDE.md is context that guides Claude. It is not a control layer. "Never read the secrets folder" written in CLAUDE.md is a request. If an action must be blocked whatever Claude decides, use a permission rule or a hook.

A two-minute test

Before relying on a new set of instructions, run three harmless tasks:

1. A change inside one package: does Claude name that package's rules and the right test command?
2. A change inside a second package: does it switch to that package's rules?
3. A change that touches both: does it identify both scopes, instead of applying one package's rules everywhere?

Ask Claude to restate the rule it will follow before it edits, and correct the instruction if the restatement is wrong. Then run the tests yourself. Guidance improves behaviour; a passing test or review is the evidence.

Write rules Claude can follow

"Test thoroughly" leaves room for interpretation. "Run npm test -w apps/web before proposing a commit" does not. Specific commands, file paths and scopes make a rule checkable.

Go further

• The full article, with an illustrative monorepo and a debugging sequence, is on Timo Labs: CLAUDE.md hierarchy in Claude Code.
• For the exam angle, read task statement 3.1: CLAUDE.md hierarchy in the CCAR-F study guide.
• Free scenario questions on configuration decisions are in the CCAR-F practice exam.