Claude Code project memory
Each Claude Code session starts with a fresh context window. CLAUDE.md files and auto memory carry knowledge forward; pair them with skills for repeatable procedures and hooks for enforcement.
- Last verified
- Applies to
- Claude Code 2.1.x. CLI spellings were checked on local version 2.1.198; official docs may describe newer 2.1.x behavior.
- Verification method
- CLAUDE.md loading, imports, local memory, auto-memory limits, and enforcement boundaries were checked against official docs. No user or project memory file was changed.
Reproducible practice
Turn one repeated correction into a scoped, testable project rule
Add only durable facts to a disposable CLAUDE.md and prove scope and load behavior before proposing a real repository change.
Prerequisites
- A repeated correction backed by repository evidence.
- A unique temporary git repository.
- No secret, personal preference, or one-off task text in the shared rule.
Steps
Create a disposable project
Keep the exercise outside every real repository.
Step 1 MEMORY_LAB=$(mktemp -d "${TMPDIR:-/tmp}/claude-memory.XXXXXX") printf '%s\n' "$MEMORY_LAB" cd "$MEMORY_LAB" && git init -qWrite one verifiable rule
State the exact command and when it applies rather than a vague quality preference.
Step 2 printf '%s\n' '# Verification' '- After changing TypeScript, run: pnpm exec tsc -b --pretty false' > CLAUDE.md wc -l CLAUDE.mdInspect loaded context
Use `/context` and `/memory` in an optional interactive session; this audit did not open or modify memory UI.
Choose enforcement separately
If the action must be blocked, move enforcement to permissions, sandboxing, or a hook instead of strengthening prose.
Expected result
The rule is short, scoped, source-controlled only when appropriate, visible in context, and distinguishable from enforced policy.
Validation
- Confirm the command exists in the real project before adoption.
- Use `/context` to verify the intended file loaded.
- Review imports and path-scoped rules for conflicts or irrelevant context.
Failure handling
Rule is ignored
Check load scope and rewrite it as one specific instruction with an observable result.
Context is bloated
Move procedures to skills and split path-specific rules instead of growing one file.
Cleanup or rollback
- Return to the original directory and remove only the printed MEMORY_LAB path.
- Revert a real shared rule through code review if it causes worse behavior.
Boundaries and when not to use it
- CLAUDE.md and auto memory guide behavior; they do not enforce security policy.
- Auto memory is repository-scoped and shared across worktrees, so do not store secrets or transient incident data.
CLAUDE.md vs auto memory
CLAUDE.md files are instructions you write. Auto memory is notes Claude writes from corrections and patterns it discovers. Both load at session start, but they solve different problems.
CLAUDE.md
Use for build commands, architecture boundaries, coding standards, and team workflows that should apply every session.
Read guideAuto memory
Use when Claude should learn preferences and debugging insights without you manually editing instructions each time.
Read guideHooks for enforcement
If an action must be blocked regardless of prompt context, use PreToolUse hooks instead of memory alone.
Read guideWhere memory files live
Memory can be scoped to the organization, user, project, or local workspace. More specific files should refine broader defaults rather than repeat them.
Write effective CLAUDE.md content
Good memory is factual, concise, and verifiable. Put commands, paths, naming rules, and review expectations here. Move one-off procedures into skills or path-scoped rules.
# Project memory
- Package manager: pnpm
- Test: pnpm test
- Lint: pnpm lint
- Do not edit files under dist/
- Auth changes require tests in src/auth/Add after repeated mistakes
When Claude makes the same error twice, write the fix as a durable rule.
Read guideKeep commands exact
Use the real command names developers run locally and in CI.
Read guideUse path-scoped rules
For large repos, scope instructions with `.claude/rules/` instead of one giant file.
Read guideConnect memory to other topics
Memory works best as part of a broader onboarding and review stack—not as the only source of project guidance.
Getting started
Run /init during first repo setup before broad edits.
Read guideCode review
Store review expectations and architecture constraints in CLAUDE.md.
Read guideSkills
Move multi-step procedures out of memory into skills.
Read guideSlash commands
Use /memory and /context to edit and inspect loaded instructions.
Read guideTroubleshoot memory loading
When instructions seem ignored, check whether the file loaded in the current session, whether a more specific rule overrides it, and whether the content is too vague to act on.
Memory checklist
Run /init early
Generate a starter CLAUDE.md, then refine it with facts Claude cannot infer reliably.
Read guidePrefer facts over taste
Write verifiable rules such as commands, paths, and constraints instead of vague style guidance.
Read guideSplit large repos
Use nested CLAUDE.md files or `.claude/rules/` for monorepos and multi-package layouts.
Read guideReview context cost
Long memory files consume tokens every session; keep them focused.
Read guide