Claude Code Memory: Setup, Types, and Better Workflows

Claude Code memory helps preserve instructions and project knowledge you do not want to repeat in each session.

It can keep build commands, testing rules, architecture notes, coding preferences, and repository warnings available when the conversation starts fresh.

The useful part is not simply storing more context. The advantage comes from deciding what belongs in CLAUDE.md, what should remain local, and what Claude can save through auto memory.

In my technical documentation work, I have found that persistent instructions perform best when they are specific, easy to verify, and reviewed regularly.

This guide explains how to set up memory, write better instructions, and customize Claude Code with rules, commands, hooks, and subagents for more reliable coding workflows.

What is Claude Code Memory?

Claude Code memory is stored context that carries useful instructions and project knowledge into future coding sessions.

Each new session begins with a fresh conversation window, so Claude does not automatically retain every explanation, correction, or decision from earlier work.

Persistent memory solves this problem through developer-written CLAUDE.md files and notes Claude creates through auto memory.

Memory provides guidance rather than guaranteed enforcement. Instructions that must always block, permit, or trigger an action should use settings or hooks instead of relying only on written context.

Choose the correct memory type to prevent personal preferences, team standards, and temporary findings from mix-ups.

Types of Claude Code Memory

Claude Code uses different memory types to separate personal preferences, project instructions, organization policies, local settings, and task-specific knowledge.

• Managed Policy: Organization-wide rules and compliance.
• User Memory: Personal preferences across all projects.
• Project Memory: Shared repository instructions.
• Local Memory: Machine-specific private settings.
• Auto Memory: Saved lessons from coding sessions.
• Path-Specific Rules: Instructions for selected files or folders.
• Subagent Memory: Dedicated knowledge for specialized subagents.

Setting Up Project Memory in Claude

The most practical way to set up Claude Code memory is to begin with one short project-level CLAUDE.md file. Add only the commands, conventions, restrictions, and repository details that Claude cannot reliably identify from the code.

Only the first 200 lines or 25KB of MEMORY.md load at session start, so Claude keeps the index short and pushes detail into topic files.

The four steps below take you from an empty repository to a file you trust during real work.

1. Generate a Starting File

Run /init during the first Claude Code session in a repository to generate a starter CLAUDE.md. Claude examines available project information and proposes instructions based on the repository structure and existing configuration.

/init Give Claude a reusable briefing about the repository that is loaded whenever you start a new Claude Code session.

Treat the result as a draft. Check every command, framework assumption, testing step, and directory description.

Remove content Claude can determine directly from configuration files or source code because unnecessary details consume context without improving decisions.

2. Create CLAUDE.md Manually

Create CLAUDE.md in the repository root and organize it with short Markdown headings. Useful sections may cover commands, coding conventions, testing requirements, architecture limits, and known warnings.

Write direct instructions such as “Use pnpm for package installation” or “Run affected tests before completing changes.” Avoid broad requests such as “write good code.”

Specific wording makes each instruction easier for Claude and the developer to verify during review.

3. Separate Shared and Personal Rules

Place team-wide standards in the committed CLAUDE.md. These may include approved commands, file locations, required checks, naming conventions, and repository restrictions.

Store personal project preferences in CLAUDE.local.md. Local URLs, machine-specific commands, private test settings, and temporary workflow notes should not affect teammates.

Add the local file to .gitignore when it contains information that should remain outside version control.

4. Confirm Memory is Loaded

Start a new session and run /context to see which memory files actually loaded. Use /memory when you need to open, create, or review files across user and project scopes.

Ask Claude to summarize the project’s build command, testing process, architecture limits, and key warnings. If the response is incomplete, check the file name, location, scope, and wording before continuing.

After saving the file, verify that Claude has loaded it before beginning a large coding task.

I recommend testing a few important instructions immediately rather than assuming the file location and wording are correct.

Make Every Claude Memory Instruction More Effective (Tips)

Effective Claude Code memory instructions should be specific, brief, and easy to verify. Focus on details Claude cannot reliably infer from the repository, and remove broad, duplicated, or outdated guidance.

• Reading Limit: A CLAUDE.md file should ideally stay under 200 lines, with a sweet spot of 60 to 100 lines. Keeping it short prevents context bloat, token waste, and instruction degradation.
• Use Verifiable Language: Replace broad requests such as “write clean code” with instructions tied to a command, file location, condition, or expected result. Clear wording makes compliance easier to check during development and review.
• Record What Claude Cannot Infer: Include unusual commands, architecture decisions, known repository problems, deliberate exceptions, and required checks. Avoid copying dependency lists, directory trees, or information Claude can already obtain from configuration files.
• Keep Instructions Focused: Keep the main CLAUDE.md short and limited to guidance needed across most sessions. Move file-specific instructions into scoped rules and place repeatable procedures inside skills rather than expanding the primary memory file.
• Remove Conflicting Rules: Review user, project, local, nested, and path-specific files for competing instructions. Keep one authoritative rule for package managers, formatting, testing, file placement, and completion requirements, then delete outdated or duplicated versions.

Customize Your Claude Code to Work Your Way

Customize Claude Code by combining memory with features such as slash commands, hooks, subagents, and shared project settings.

Each customization can be adopted independently, but together they make Claude Code more reliable, reusable, and easier to maintain.

Memory stores instructions, while customization automates tasks and makes those instructions easier to apply consistently.

The table below summarizes the main ways to extend your memory setup into a reusable workflow.

Organizing Larger Memory Sets In Claude.md

Large repositories need more structure than one expanding CLAUDE.md file. Supporting documents, topic-based rules, and path conditions can keep instructions easier to review while limiting unrelated guidance.

Imports help separate stable reference material, although every imported file still enters the startup context. Rules inside .claude/rules/ offer more control because they can cover one subject or activate only for matching files.

Monorepos may also contain instructions owned by several teams.

1. Import Supporting Files

After separating reference material, divide active instructions into focused rule files.

1. Identify stable documents containing architecture decisions, testing procedures, package commands, or Git practices.
2. Add each document to CLAUDE.md using the @path/to/file format.
3. Use relative paths when the imported file belongs to the repository.
4. Review external files before approving access.
5. Confirm the imported instructions appear in Claude’s active context.

2. Split Rules by Topic

Rules needed only for selected files should include path conditions.

1. Create the .claude/rules/ directory if it does not already exist.
2. Add separate Markdown files for testing, security, API design, documentation, or code style.
3. Give each file a descriptive name, such as testing.md.
4. Keep every file limited to one subject.
5. Review rules without path conditions because they load across the project.

3. Add Path Conditions

Path conditions control individual rules, while monorepo settings reduce guidance from unrelated packages.

1. Open the rule file that requires limited scope.
2. Add YAML frontmatter at the top of the document.
3. Insert a paths field containing the relevant folders, extensions, or glob patterns.
4. Keep each pattern narrow enough to avoid unrelated files.
5. Test the rule with matching and non-matching files to confirm when it activates.

4. Reduce Monorepo Noise

Structured files manage deliberate instructions, while auto memory records findings produced during development work.

1. Place repository-wide instructions in the root. CLAUDE.md.
2. Add nested CLAUDE.md files inside packages that require different conventions.
3. Keep package instructions focused on commands and rules unique to that area.
4. Add unrelated instruction files to claudeMdExcludes when necessary.
5. Check the active context from different packages to confirm that only relevant guidance loads.

Configuring Auto Memory in Claude Code

Claude Code memory can save build findings, debugging lessons, architecture notes, coding patterns, and workflow preferences for later sessions. Claude decides what may be useful again, so it does not create a new note after every task.

Auto memory is active by default and stores information separately for each repository. Its main index loads at the start of a conversation, while longer topic files remain available when Claude needs them.

The controls below help keep saved context accurate and useful.

• Turn Auto Memory On or Off: Auto memory is enabled by default. Open /memory to toggle it, set autoMemoryEnabled to false for one project, or use CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 when turning it off through an environment variable.
• Understand the Memory Folder: Each repository receives a local directory at ~/.claude/projects/<project>/memory/. All worktrees and subdirectories from the same Git repository share it. MEMORY.md provides the concise index, while topic files hold detailed notes.
• Review What Claude Saved: Use /memory to inspect the notes Claude created. Remove outdated commands, temporary debugging details, duplicate entries, sensitive information, and unsupported assumptions. Because the files are editable Markdown, you can correct them directly.
• Move Important Findings: Move stable, team-relevant findings into committed CLAUDE.md files or project documentation. Keep temporary discoveries and personal preferences local. This prevents important knowledge from remaining available only on one developer’s machine alone.

Memory vs Other Claude Code Tools

Memory is the right choice for facts, preferences, and instructions that should remain useful across multiple coding sessions. Keeping these tools separate prevents permanent files from filling with temporary requests.

It also helps teams distinguish written guidance from actions and restrictions that require stronger technical control.

A Practical Memory Routine to Improve Claude Efficiency

A reliable memory routine keeps persistent instructions useful without allowing files to become crowded, outdated, or difficult to verify.

The steps below are the loop I run on a repository, from first setup through routine cleanup, and they scale from a solo project to a shared monorepo.

1. Create one short project-level CLAUDE.md.
2. Add verified commands and non-obvious repository constraints.
3. Move personal preferences into CLAUDE.local.md.
4. Use scoped rules for selected files and folders.
5. Let auto memory record useful development findings.
6. Review automatically saved notes for incorrect assumptions.
7. Promote stable team knowledge into committed documentation.
8. Run /context to confirm which files loaded.
9. Test important instructions with simple sample tasks.
10. Remove outdated guidance during regular code reviews.

I prefer a small, maintained system over several loosely organized files. Use hooks or settings when a requirement needs technical enforcement rather than written guidance.

Long Story Short

Claude Code memory works best when it stores only the instructions and project knowledge that remain useful across future sessions.

A strong setup separates shared project rules, personal preferences, path-specific guidance, auto memory, and technical controls. This reduces conflicting instructions and helps Claude apply the right context during each coding task.

In my technical documentation work, I have found that short, reviewed instructions are easier to follow than large files filled with details already visible in the repository.

Start with a focusedCLAUDE.mdconfirm it loads through and test one important rule before depending on it during larger changes.

Comment below with the Claude Code memory setup that has improved your coding workflow.

Frequently Asked Questions

Does Claude Code Remember Previous Sessions?

Claude Code starts sessions with fresh conversation context, but CLAUDE.md and auto memory can load saved instructions and useful project knowledge.

Where Is Claude Code Memory Stored?

Written instructions may live in user, project, local, or managed files. Auto memory is stored in a repository-based directory under ~/.claude/projects/.

Should CLAUDE.md be Added to Git?

Commit project instructions that apply to the team. Keep machine-specific settings, personal preferences, and sensitive information in ignored local files.

How do I Customize Claude Code Beyond Memory?

Add custom slash commands for repeated prompts, hooks for actions that must always run, and subagents for focused tasks. Commit them so they stay portable.

Why is Claude Ignoring My Memory File?

The file may not have loaded, its wording may be vague, or another instruction may conflict. Check /context, file scope, and rule specificity.