Remember the work.
Not everything.

01 / THE SHORT ANSWER

Yes, the native memory
is plain text.

Claude Code’s documented built-in memory uses Markdown files. You write instructions in CLAUDE.md; Claude writes selected learnings into auto memory. A bounded MEMORY.md index is loaded into context, and Claude reads detailed topic files with its standard file tools when needed. [1]

No separate embedding model or vector database is required for that documented path. It is file loading and model-directed reading—not a documented nearest-neighbor lookup over a vector index. This describes native memory, not every internal Claude Code feature or third-party plugin.

No embeddings ≠ no model work. Claude still decides what to save, reads notes, and reasons about them. Notes consume input tokens when loaded; writing them involves ordinary model/tool work. Memory does not train or update the model’s weights.

02 / WHAT LIVES WHERE

Your instructions.
Claude’s notebook.

Auto memory is enabled by default and machine-local. Worktrees and subdirectories of the same git repository share its auto memory directory by default; it is not automatically synchronized to another machine. Claude decides which useful learnings to save—not every message or every session. [1]

What Claude records

The current memory documentation tells Claude not to duplicate facts it can derive from code or git, or instructions already in CLAUDE.md. Use CLAUDE.md for explicit standing conventions and skills for repeatable procedures.

03 / FOLLOW ONE MEMORY

Saved is not yet recalled.

A synthetic correction: “For reviews, lead with the user-visible failure and reproduction. Skip praise-only summaries.” Here is one possible lifecycle; saving and reading the note are model decisions, not guaranteed steps.

---
name: Review feedback
description: How to structure code reviews
type: feedback
---
Lead with the user-visible failure and
reproduction. Skip praise-only summaries.

- [Review feedback](feedback_reviews.md)
  — Review structure and evidence.

IN CONTEXT:  applicable CLAUDE.md + MEMORY.md index
ON DISK:     feedback_reviews.md
NOT IMPLIED: full prior conversation

Task → recognize relevant index entry
     → read feedback_reviews.md
     → use the returned text in this task

The index is a retrieval aid, not the memory itself. Keep it short and descriptive. Moving a long note into a topic file saves startup context only if the index stays small.

04 / DON’T MIX THESE UP

Memory ≠ context
≠ compaction ≠ cache.

Retained conversation transcripts are another store. Resuming a conversation is not the same as starting a fresh conversation with selected auto memories. Claude Code’s memory files are excluded from its old-session transcript retention sweep. [1]

Memory is guidance, not a security boundary. CLAUDE.md and recalled notes are context. Use permission rules, hooks, and sandbox/OS controls to enforce restrictions. Stored text can be stale, malicious, or simply wrong.

05 / SAME WORD, DIFFERENT ARCHITECTURES

Compare retrieval,
not the word “memory.”

These are different layers: a native feature, a context database, a harness plugin, an agent runtime, and an application memory API. They are not drop-in substitutes. Recommendations below are architectural judgments, not measured rankings.

06 / MATCH THE PROBLEM

Start small.
Add retrieval for a reason.

1. “Stop making the same project mistake.” Start with concise CLAUDE.md instructions, scoped rules and native auto memory. Low setup cost; inspect exactly what was saved.
2. “Recover a decision buried in a long coding conversation.” Investigate Magic Context’s supported harness integration and transcript retrieval. Keep exact-history recovery distinct from curated project facts.
3. “Search many documents, skills and memories together.” OpenViking’s hierarchical context store and semantic retrieval target this problem. Budget for models, indexing and a service.
4. “Build an agent with versioned, editable memory.” Letta provides an agent runtime with Git-backed MemFS and optional background dreaming; it is not just a CLAUDE.md replacement.
5. “Add per-user memory to my own application.” Mem0 supplies an add/search memory layer. Your application still needs to decide when to save, retrieve and inject results.

Evaluate on your actual failure cases. Did it recall the right decision? Can it show the source? Does a correction replace stale advice? Can it isolate users/projects and delete data? Measure total model calls, tokens and latency—not just storage size or a vendor benchmark.

07 / INSPECT & MAINTAIN

Keep the notebook
small and accountable.

/memory   # browse/edit notes and toggle auto memory
/context  # inspect current context and loaded memory files

For explicit team instructions, ask to update CLAUDE.md or edit it directly. For a personal learning, ask Claude to remember it, then inspect what was actually saved. Do not infer persistence solely from an answer saying “I’ll remember.”

{
  "autoMemoryEnabled": false
}

This disables auto memory, not CLAUDE.md instructions, and does not itself delete existing notes. The environment alternative is CLAUDE_CODE_DISABLE_AUTO_MEMORY=1. See the current official settings.

• Store rationale and source pointers. Separate confirmed decisions from guesses. Recheck against current code and user instructions.
• Don’t save secrets. Machine-local notes can still enter a model request; a remote embedding or extraction provider may also receive text in external systems.
• Scope first. A cross-project notebook can leak advice or data into the wrong project. Shared services need explicit tenant/project controls.
• Correct all copies deliberately. Source notes, summaries, vector indexes, archives and backups can have different deletion lifecycles.
• Keep procedures separate. A skill describes how to perform a repeatable task; memory records durable facts and feedback. Neither guarantees execution or compliance.