Claude Code / core concepts
Claude Code Memory
Memories are used to retain stable preferences and project rules, but the source of truth should still be the repository, configuration, and command output.
How Claude remembers projects
Claude Code's memory mainly comes from CLAUDE.md file and automatic memory. CLAUDE.md is suitable for stable project context, and automatic memory is suitable for experiences captured from historical sessions.
Memory is not the source of database truth. Project facts, commands and team agreements should be written first to the CLAUDE.md or rules file in the repository; personal preferences can be placed in user-level CLAUDE.md; temporary sensitive information should not be written to memory.
where to put
Different scopes have different file locations. The larger the scope, the more stable, short, and actionable the content should be.
| location | range | Suitable for content |
|---|---|---|
| ~/.claude/CLAUDE.md | global individual | Personal work preferences and common output formats. |
| Project CLAUDE.md | Current project/team | Project commands, architecture, testing, collaboration agreements. |
| CLAUDE.local.md | Locally private | Personal project preferences that should not be submitted. |
| .claude/rules | path matching | Short rules that only trigger on relevant files. |
How to write effective memory
Effective memorization should be like a project manual for a new colleague: short, clear, and verifiable. Don't write something that Claude can tell by reading the code.
- Write real commands, not "run tests".
- Writing non-default coding styles and project-specific pitfalls.
- Write important boundaries, such as don’t change payment, don’t deploy directly.
- Convert long tutorials and API documentation into links or skill references.
Complete usage points
Supplement the core concepts, operation sequences, permission boundaries and verification requirements that are easily compressed and missed in official documents, making it easier for English readers to learn completely by page.
Memory system supplement
Claude Code's memory comes from multiple levels: user-level CLAUDE.md, project CLAUDE.md, path rules, automatic memory, and the current session context. Different levels of services have different scopes, and writing in the wrong location may cause context pollution or leakage of sensitive information.
Long-term project facts are written into the project CLAUDE.md; personal preferences are written into user-level files; machine-related or sensitive configurations are written into local files or environment variables; path-specific conventions are written into rules; one-time task status is left in the session summary.
Effective memory should be short, stable, and executable. Don’t write long tutorials, keys, cookies, customer data, outdated deployment steps. The information that Claude can obtain by reading the code does not need to be written into memory.
Study Checklist
Put the content on this page into real tasks and use the five dimensions of entry, context, permissions, verification and team rules to check whether you have truly mastered it.
Study Checklist
After reading this page, do not just remember the concept name. You should be able to place "Claude Code Memory" back into a real Claude Code engineering workflow: where the task starts, what context the system loads, which actions need approval, how the result is verified, and how to roll back when it fails.
If this is a concept page, be specific about how it affects the real task: does it change context, permissions, execution paths, validation methods, or changes the team collaboration process.
- Be able to describe in your own words the specific problem this page solves, rather than just reciting the title.
- Able to write a minimal example task with goals, scope, prohibitions, and acceptance criteria.
- Be able to determine which information should be put into the current prompt and which should be captured as project rules or configurations.
- Be able to explain which long-term rules should go into CLAUDE.md, and which runtime behavior should be handled by settings, permissions, Hooks, Skills and MCP.
- Ability to check diffs, command output, test results, screenshots or PR notes after a task is completed instead of just trusting the natural language summary.
If this page is used for team training, ask learners to complete a small task with Claude Code: read and explain first, submit a plan, make the smallest useful change, and close with real verification commands plus human diff review.