Author(s): Rick Hightower

Originally published on Towards AI.

Part 7: The five layers of Claude Code memory that stop your AI from repeating its mistakes, and how to route each fact to the right one.

You tell Claude Code that your project uses pnpm, not npm. You tell it the auth service signs JWTs with RS256, not HS256. You tell it tests live in tests/ and mirror the source path. Useful facts, all of them. Then tomorrow you open a fresh session, and Claude suggests npm install. By Friday you have explained the build command nine times, and you are starting to wonder why this tool keeps forgetting things.

The article explains that Claude isn’t “forgetting” because each session starts with a fresh context window; instead, you failed to place persistent facts into Claude Code’s memory system. It breaks memory into five layered scopes (managed policy, user CLAUDE.md, project CLAUDE.md, local CLAUDE.md, and rules, plus auto memory), clarifying how the layers are concatenated each session and how later/more specific instructions win. It then gives practical guidance on keeping CLAUDE.md disciplined (short, specific, verifiable, and fix-focused), moving repeated corrections into the right files, and using path-scoped rules to grow instructions without bloating token cost. Auto memory is presented as a user-and-machine-local scratchpad Claude maintains for you, while the daily habit is to promote notes into the appropriate layer—project CLAUDE.md for team-wide facts, rules for file-scope conventions, and CLAUDE.local.md for your personal-but-stable preferences. Finally, it distinguishes memory (guidance) from enforcement (hooks that must run every time) and ends with a concrete “do this today” checklist using /memory and auditing + extracting from CLAUDE.md to stop the repeated re-explanation tax.

Read the full blog for free on Medium.

Published via Towards AI