Dubem WorkDubem Work

7 Tue Jul 2026

How Claude Consumes Context: A Simple Mental Model

Why Claude Code follows some instructions and shrugs at others comes down to where they live and when they load. A mental model for CLAUDE.md priority and the order of influence in the context window.

If you've ever wondered why Claude Code follows some instructions religiously and seems to shrug at others, the answer is almost always about where the instruction lives and when it gets loaded. Claude doesn't read your project the way you do. It assembles a briefing before every session, and the order of that briefing matters.

This article breaks down two things: the priority ladder of CLAUDE.md files, and the broader order of influence across everything in Claude's context window. Then we'll tie it together with one mental model you can actually remember.

The Mental Model: A New Employee's First Day

Imagine Claude as a brilliant contractor who shows up to your company every morning with total amnesia. Every session is day one. So each morning, someone hands them a stack of documents to read before they start working. That stack, in order:

  1. The company legal handbook: non-negotiable rules from HQ. (Enterprise policy)
  2. Their own personal notebook: habits and preferences they carry to every job. (User-level CLAUDE.md)
  3. The team playbook: how this team does things. (Project CLAUDE.md)
  4. Sticky notes on their desk: private reminders nobody else sees. (CLAUDE.local.md)
  5. Signs posted in each room: rules they only read when they walk into that room. (Subdirectory CLAUDE.md)

The rule for conflicts is intuitive: the more specific instruction wins, but the legal handbook beats everything. If the team playbook says "use 2-space indentation" and their personal notebook says 4, the team wins. They're on the team's turf. But if HQ says "never commit secrets," no playbook or sticky note can override it.

That's the whole model. Everything below is just detail.

Part 1: The CLAUDE.md Priority Ladder

CLAUDE.md files are markdown files of persistent instructions that Claude Code loads at the start of every session. They can live in five places:

LevelLocationWho owns itScope
1. Enterprise (managed policy)System-level path set by IT (e.g. /Library/Application Support/ClaudeCode/CLAUDE.md on macOS)Your org's IT/security teamEvery user, every project. Cannot be overridden or excluded
2. User~/.claude/CLAUDE.mdYouAll your projects, just your machine
3. Project./CLAUDE.md at the repo rootThe team (committed to git)Everyone who clones the repo
4. Local./CLAUDE.local.md (gitignored)YouThis project, this machine only
5. Subdirectoryfrontend/CLAUDE.md, api/CLAUDE.md, etc.Whoever owns that folderOnly when Claude works with files in that folder

Three things trip people up here:

It's additive, not replacing. All levels load together and stack. The hierarchy only matters when instructions conflict. Then the more specific level takes precedence, with enterprise policy as the one exception that always wins.

Subdirectory files load lazily. Files at or above your working directory load in full at launch. Files in child directories load on demand, only when Claude actually reads files there. This is why a rule in a nested CLAUDE.md sometimes seems ignored. It simply hasn't been loaded yet. Run /memory to see what's actually active.

It's guidance, not enforcement. Claude treats CLAUDE.md as context, not hard configuration. Clear, short, specific files get followed far more consistently than 400-line manifestos. Anthropic's docs note files over 200 lines consume more context and may reduce adherence. If something must never happen, use a hook or permission setting, not a CLAUDE.md line.

Part 2: The Order of Influence in the Context Window

CLAUDE.md is only one ingredient. When a session starts, Claude's context window gets assembled roughly like this, from most foundational to most immediate:

1. System prompt. The bedrock. Anthropic's instructions defining what Claude is, what tools it has, and its core behavior. You don't see it, and nothing you write outranks it.

2. MCP tools. Definitions of connected tools and servers get injected next. These shape what Claude can do, and their descriptions subtly shape what Claude thinks to do.

3. Skills. Folders of task-specific instructions (like how to build a spreadsheet or a PDF) that load when relevant. They're procedural knowledge: how to do a category of work.

4. CLAUDE.md files. The whole ladder from Part 1, concatenated in. Project knowledge: how things are done here.

5. Auto memory. Notes Claude wrote for itself in previous sessions: conventions it discovered, bugs it solved, preferences you expressed. Stored at ~/.claude/projects/<project>/memory/. It adds context but defers to your explicit instructions.

6. Your prompt. The most immediate and heavily weighted signal. What you type right now sits closest to the moment of action, which is why a direct instruction in chat can steer Claude away from a vague CLAUDE.md rule.

Back to our amnesiac contractor: the system prompt is their training and professional ethics, MCP tools are the toolbox they were handed, skills are the certification courses they took, CLAUDE.md is the morning briefing stack, memory is their own notes from yesterday, and your prompt is the manager walking over and telling them what to do right now.

The manager's words carry huge immediate weight, but they can't override professional ethics (the system prompt) or company law (enterprise policy).

Why This Matters in Practice

Once you have this model, the debugging habits follow naturally:

  • Claude ignoring a project rule? Check if it conflicts with a more specific file lower in the ladder, or lives in a subdirectory that hasn't loaded. /memory shows you the active stack.
  • Repeating yourself every session? That instruction belongs in a CLAUDE.md, not in your prompts.
  • A rule everyone on the team needs? Project level, committed to git. Personal quirk? User level or local. Non-negotiable? That's your org's managed policy.
  • File getting bloated? Split path-specific rules into subdirectory files or .claude/rules/ so they load only when relevant.

The core insight is simple: Claude has no memory of its own. It has a briefing. Control the briefing, and you control the behavior.


References

  1. Anthropic, How Claude remembers your project (official Claude Code memory docs): https://code.claude.com/docs/en/memory
  2. Anthropic, Claude Code overview: https://docs.claude.com/en/docs/claude-code/overview
  3. Anthropic, Memory tool (Claude Platform docs): https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool
  4. Rushi's, The Full CLAUDE.md Hierarchy: From Enterprise Policy to Subdirectory Rules: https://www.rushis.com/the-full-claude-md-hierarchy-from-enterprise-policy-to-subdirectory-rules/
  5. Developer Toolkit, Claude Code Memory System: https://developertoolkit.ai/en/claude-code/advanced-techniques/memory-system/
  6. Patryk Golabek, Project Context & Memory (Claude Code Guide): https://patrykgolabek.dev/guides/claude-code/context-management/
  7. Bijit Ghosh, The Complete Guide to CLAUDE.md (Medium): https://medium.com/@bijit211987/the-complete-guide-to-claude-md-memory-rules-loading-and-cross-tool-compression-97cc12ed037b
  8. Serenities AI, CLAUDE.md Guide: Configure Claude Code Like a Pro (2026): https://serenitiesai.com/articles/claude-md-complete-guide-2026
Dubem Izuorah

Written by

Dubem Izuorah

Design Engineer

With over 10 years of experience in design and software engineering, I build tools for startups across various industries, with a special focus on marketing tools that support businesses around the world. Lately I'm focused on the Human ↔ AI work loop, helping people collaborate with AI to do great work.