Memory and persistence

Out of the box, Claude doesn't remember you between sessions. Each new conversation starts fresh — no recollection of yesterday's work, no awareness that you've already explained your project's quirks ten times. That's usually a feature, not a bug. But for some workflows, it's the friction that stops you from going faster.

The default: no memory

When you start claude in a folder, Claude loads:

• The contents of CLAUDE.md in that folder.
• The active settings from .claude/settings.json.
• Nothing else from any previous session.

Whatever you taught Claude yesterday — your preferred patterns, the bug you ran into, the workaround you found — is gone unless you wrote it down somewhere it can read on startup. This is deliberate. It keeps sessions predictable and your context clean.

The two places that do persist

Persistent context lives in exactly two places:

1. CLAUDE.md (and friends)

You met this in Module 3. CLAUDE.md is the deliberate, human-curated context that survives. You edit it when something is worth keeping. Claude reads it on every session start in that project.

2. The memory system

Some Claude Code setups also have an opt-in memory system— a separate folder Claude can read and write to across sessions, holding facts it's learned about you, your preferences, and the projects you're working on. When enabled, Claude can decide to save a memory at any time ("the user prefers TypeScript over JavaScript") and will recall it in future sessions when relevant.

What memory is good for

Memory pays off when:

• The same facts about you keep being useful across many different projects. "I'm a data scientist, not a web developer" — handy in any session.
• You've corrected the same mistake twice and want it to stick. "Don't suggest jQuery — we use vanilla JS in this org."
• You're running a long-term project where context accumulates faster than you can curate it.

What memory is bad for

Conversely:

• Ephemeral state."Today I'm working on the login bug" — won't be true tomorrow. Belongs in the chat, not memory.
• Anything you wouldn't want Claude bringing up. Memory entries can resurface unexpectedly. If you don't want it referenced later, don't save it.
• Information that's available in the codebase. The file structure, the dependencies — Claude can read those. Memory is for what's NOT in the code.
• Anything privacy-sensitive.Memory is plaintext on your disk. Don't put credentials, personal details about other people, or anything you wouldn't put in a comment.

Categories of memory worth keeping

When memory is enabled, the entries that earn their keep usually fall into four buckets:

• User facts. Your role, your background, what kind of code you read fluently, what frustrates you in explanations.
• Feedback patterns.Corrections you've given that should generalise. "Don't add summary paragraphs at the end of replies; I can read the diff."
• Project context. Facts about an ongoing project that change too fast to keep in CLAUDE.md — current milestones, who's working on what.
• References."Pipeline bugs are tracked in Linear project INGEST." Pointers to where information lives, not the information itself.

Inspecting and editing your memories

Memory is stored in plain Markdown files on disk. You can open them in any editor. You can delete entries that have gone stale. You can add entries directly if you know what you want Claude to remember.

Treat the memory folder like a notes file you actively curate. A bloated, never-cleaned memory becomes worse than no memory: Claude trusts the outdated facts and starts confidently being wrong.

Memory vs. CLAUDE.md

The two overlap. A rough rule:

• CLAUDE.md is for what the project is and how it works. Committed to git. Shared with the team.
• Memory is for what you are like and what you prefer. Personal. Local. Crosses projects.

Some facts honestly fit either — your preferred TypeScript style might be a team thing (CLAUDE.md) or a personal thing (memory). When in doubt, pick the more public location; CLAUDE.md ages better.

The privacy stance

Memory exists to be useful, not to be exhaustive. The thing that makes "AI that remembers you" either delightful or creepy is whether the memory is being used to serve you or to perform attentiveness. Save the things that actually change future answers. Don't save the things that just demonstrate you're being watched.

A good test: would you tell a colleague this fact about yourself if you were working together long-term? If yes, fine. If it's a detail you'd find weird to be remembered, skip it.