Memory
The system remembers what happened and learns from it.
How Memory Works
Memory lives in .claude/memory/ inside the vault repository. It is version-controlled via git, which means every change is tracked and every session across every device shares the same memory state.
Each memory file has frontmatter with a type field that categorizes what kind of knowledge it holds. The index file at .claude/memory/MEMORY.md links to every active memory file.
Memory Types
Four types of memory, each serving a different purpose.
| Type | Purpose | Example |
|---|---|---|
user | Profile, preferences, timezone | user_maciek.md |
feedback | Corrections, confirmed approaches, style preferences | feedback_verify_before_done.md |
project | Project state, architecture, history | project_mysecondbrain.md |
reference | External tools, configs, templates | reference_starter_app_template.md |
What Gets Saved
- Your preferences and how you like things done
- Corrections you make so the same mistake does not happen twice
- Project state so sessions can pick up where they left off
- References to external tools, configs, and templates
- People context so the system knows who you are talking about
What Does Not
Not everything belongs in memory. Some information already lives in a better place.
- Code patterns. Read the code instead.
- Git history. Use
git loginstead. - Debugging solutions. The fix is in the code.
- Anything already documented in CLAUDE.md.
Cross-Device Sync
Memory syncs across all devices and sessions through git. The mechanism depends on where the session is running.
- Mac sessions: Write directly to .claude/memory/. Changes sync via the Obsidian Git plugin.
- Phone and cloud sessions: Read memory from the repo. After writing or updating memory files, commit and push immediately so other sessions stay fresh.
- Scheduled agents: Can read and write memory as part of vault processing. The Chronicle role updates memory with the day's learnings.