Master the dual memory system — CLAUDE.md instructions and auto memory
Claude Code has two memory systems that persist across sessions. Understanding them is the key to making Claude work effectively on your projects long-term.
| Type | Who Writes It | Purpose |
|---|---|---|
| CLAUDE.md | You (the developer) | Instructions, rules, preferences |
| Auto Memory | Claude (automatically) | Patterns, insights, project notes |
Both load into Claude's context at session start. Let's dive into each.
CLAUDE.md files form a layered instruction system:
| Type | Location | Scope | Shared? |
|---|---|---|---|
| Managed policy | /Library/Application Support/ClaudeCode/CLAUDE.md | Organization | All users |
| Project | ./CLAUDE.md or ./.claude/CLAUDE.md | Team |
Full access
Unlock all 14 lessons, templates, and resources for Claude Code Mastery. Free.
| Via git |
| Project rules | ./.claude/rules/*.md | Team | Via git |
| User | ~/.claude/CLAUDE.md | Personal | All projects |
| Local | ./CLAUDE.local.md | Personal | This project only |
/init
This generates a CLAUDE.md based on your project structure. Claude analyzes your codebase and creates relevant instructions.
# Project: My App
## Architecture
- Next.js 14 app router
- Prisma ORM with PostgreSQL
- React Server Components by default
## Commands
- `pnpm dev` — start dev server
- `pnpm test` — run tests
- `pnpm lint` — lint all files
- `pnpm typecheck` — TypeScript check
## Conventions
- Use server components unless interactivity required
- All API routes in app/api/
- Tests go next to source files (*.test.ts)
- Prefer Zod for validation
## Git
- Branch naming: feat/*, fix/*, chore/*
- Conventional commits required
- Run `pnpm typecheck && pnpm lint` before committing
## Don't
- Don't modify .env files
- Don't push directly to main
- Don't use `any` type
Pro Tip: The #1 most useful thing in CLAUDE.md is your build/test commands. Claude references these constantly.
For personal preferences that shouldn't be in git:
# Personal Settings
- My sandbox URL: http://localhost:3001
- Preferred test user: test@example.com
- Skip E2E tests during development
CLAUDE.local.md is automatically added to .gitignore.
Q: What's the difference between CLAUDE.md and CLAUDE.local.md?
CLAUDE.md is shared with your team (committed to git). It contains project-wide instructions like architecture, conventions, and commands.
CLAUDE.local.md is personal and gitignored. It contains your individual preferences like local URLs, test accounts, and personal workflow tweaks.
For larger projects, organize instructions into focused files:
your-project/
├── .claude/
│ ├── CLAUDE.md # Main project instructions
│ └── rules/
│ ├── code-style.md # Code style guidelines
│ ├── testing.md # Testing conventions
│ ├── security.md # Security requirements
│ └── api-design.md # API standards
All .md files in .claude/rules/ are automatically loaded as project memory.
Rules can be scoped to specific files using YAML frontmatter:
---
paths:
- "src/api/**/*.ts"
---
# API Development Rules
- All API endpoints must include input validation
- Use the standard error response format
- Include OpenAPI documentation comments
Rules without a paths field load unconditionally.
Q: You have a rule file at .claude/rules/api.md with paths: ["src/api/**/*.ts"]. When does Claude load this rule?
Only when Claude is working with files that match the pattern src/api/**/*.ts. Path-specific rules load on-demand, not at session start. Rules without a paths field load unconditionally for every session.
CLAUDE.md files can import other files using @path/to/file syntax:
See @README.md for project overview.
Check @package.json for available commands.
# Additional Instructions
- Git workflow: @docs/git-instructions.md
`@not/imported`/memoryFill in the blanks:
/___/___.claude/___/*.md/init/memory.claude/rules/*.mdAuto memory is where Claude writes notes for itself based on what it discovers during sessions.
~/.claude/projects/<project>/memory/
├── MEMORY.md # Index file (first 200 lines loaded at startup)
├── debugging.md # Detailed debugging notes
├── api-conventions.md # API design decisions
└── ... # Any topic files Claude creates
MEMORY.md load into Claude's system prompt automaticallyTell Claude directly:
> Remember that we use pnpm, not npm
> Save to memory that the API tests require a local Redis instance
> Note that the staging server is at staging.example.com
/memory # Open memory files in your editor
export CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 # Force off
export CLAUDE_CODE_DISABLE_AUTO_MEMORY=0 # Force on
Gotcha: Only the first 200 lines of MEMORY.md load automatically. Keep it concise! Topic files load on-demand.
Q: How many lines of MEMORY.md load automatically at session start?
200 lines. Only the first 200 lines of MEMORY.md are loaded into Claude's system prompt at startup. Topic files (like debugging.md) load on-demand when Claude needs that information.
1. Managed CLAUDE.md (/Library/Application Support/ClaudeCode/CLAUDE.md)
2. User CLAUDE.md (~/.claude/CLAUDE.md)
3. Walk up from cwd to root, loading CLAUDE.md / CLAUDE.local.md at each level
4. .claude/rules/*.md in project root
5. Auto Memory MEMORY.md (first 200 lines)
Child directory CLAUDE.md files and auto memory topic files load on demand as Claude works with relevant files.
When Claude's context fills up, it automatically compacts — summarizing the conversation to free space. This can lose important details.
/compact Focus on code samples and API usage patterns
You can also add instructions to your CLAUDE.md:
# Compact instructions
When you are using compact, please focus on test output and code changes.
Pro Tip: Use a
SessionStarthook with acompactmatcher to re-inject critical context after compaction. We'll cover this in the Hooks lesson.
Fill in the blanks:
~/.claude/projects/<project>/___/export CLAUDE_CODE_DISABLE_AUTO_MEMORY=___@___memory/1@path/to/file/init to generate a CLAUDE.md.claude/rules/ directory with one rule file (e.g., code-style.md)/memory to verify the auto memory was createdReflection: How does the generated CLAUDE.md compare to what you'd write manually?
Scenario: You have a monorepo with a React frontend and a Python backend. The frontend team wants Claude to use Prettier and ESLint. The backend team wants Claude to use Black and mypy. How would you organize memory?
Use path-specific rules in .claude/rules/:
<!-- .claude/rules/frontend.md -->
---
paths:
- "frontend/**/*"
---
# Frontend Rules
- Format with Prettier: `npx prettier --write`
- Lint with ESLint: `npx eslint --fix`
- Use React Server Components by default
<!-- .claude/rules/backend.md -->
---
paths:
- "backend/**/*"
---
# Backend Rules
- Format with Black: `black .`
- Type check with mypy: `mypy .`
- Follow PEP 8 conventions
The right rules load automatically based on which files Claude is working with.
| Concept | One-Liner |
|---|---|
| Two memory types | CLAUDE.md (you write) + Auto Memory (Claude writes) |
| CLAUDE.md hierarchy | Managed > User > Project > Local |
| Bootstrap | /init generates CLAUDE.md from your codebase |
| Modular rules | .claude/rules/*.md — auto-loaded, can be path-scoped |
| Imports | @path/to/file syntax in CLAUDE.md |
| Auto memory | First 200 lines of MEMORY.md load at startup |
| Local memory | CLAUDE.local.md — personal, gitignored |
| View memory | /memory opens files in your editor |
Next up: Permissions & Security → — Learn the tiered permission system, sandboxing, and enterprise security.