Claude Code memory · Hooks · Public Alpha

Claude Code memory that survives the session, the tool and the model.

Start where you left off.

Claude Code memory has two built-in layers: CLAUDE.md files you write, and auto memory Claude writes for itself into a per-repository MEMORY.md. Both are plain Markdown, loaded at session start, and stay on one machine inside one tool. Vodou adds a third layer with four Claude Code hooks: memory from a local SQLite database is injected at SessionStart and on every UserPromptSubmit, a PostToolUse guard protects your files, and SessionEnd extracts what the session learned. The same memory reaches Cursor, Codex, Claude Desktop and any MCP client — and the ChatGPT or Claude tab in your browser.

Download Vodou Read the hooks doc

4 hooksUnix socket, no DB accessSame memory in Cursor and CodexmacOS · Windows · Linux

TL;DR

Vodou gives Claude Code persistent memory through four hooks — SessionStart, UserPromptSubmit, PostToolUse and SessionEnd — installed by writing .claude/settings.json.
Vodou's hook binary is a zero-thread executable under 500 KB that talks to the Vodou daemon over a Unix socket and never opens the memory database itself.
Vodou renders a fresh MEMORY.md per session and project from a local SQLite database with full-text and vector search, instead of a hand-maintained 200-line file.
Vodou's memory is the same one Cursor, Codex, Claude Desktop, VS Code and 22 AI chat sites read — the model and the tool change; the memory doesn't.

Definition

What is Claude Code memory?

Claude Code memory is the set of mechanisms that carry knowledge across sessions, because each session starts with a fresh context window: CLAUDE.md files you write at managed, user, project and local scope, and auto memory — notes Claude writes itself into a per-repository MEMORY.md index plus topic files. Vodou adds a hook-driven memory layer on top of both.

The two built-in systems, as Anthropic documents them:

Property	CLAUDE.MD FILES	AUTO MEMORY
Who writes it	you	Claude
What it holds	instructions and rules	learnings: user, feedback, project, reference
Where	./CLAUDE.md, ./.claude/CLAUDE.md, ./CLAUDE.local.md, ~/.claude/CLAUDE.md, managed policy path	~/.claude/projects/<project>/memory/MEMORY.md + one topic file per memory
Scope	project, user or organisation	per repository, shared across worktrees, machine-local
Loaded	every session, in full (up to 4 MiB)	every session — the first 200 lines or 25 KB of MEMORY.md; topic files on demand
Control	edit the file; /memory; /context shows what loaded	/memory toggle, autoMemoryEnabled, CLAUDE_CODE_DISABLE_AUTO_MEMORY=1

CLAUDE.md files

Who writes it: you
What it holds: instructions and rules
Where: ./CLAUDE.md, ./.claude/CLAUDE.md, ./CLAUDE.local.md, ~/.claude/CLAUDE.md, managed policy path
Scope: project, user or organisation
Loaded: every session, in full (up to 4 MiB)
Control: edit the file; /memory; /context shows what loaded

Auto memory

Who writes it: Claude
What it holds: learnings: user, feedback, project, reference
Where: ~/.claude/projects/<project>/memory/MEMORY.md + one topic file per memory
Scope: per repository, shared across worktrees, machine-local
Loaded: every session — the first 200 lines or 25 KB of MEMORY.md; topic files on demand
Control: /memory toggle, autoMemoryEnabled, CLAUDE_CODE_DISABLE_AUTO_MEMORY=1

Both are treated as context, not enforced configuration, and both are files on one machine. Auto memory is "not shared across machines or cloud environments", and Claude Code reads CLAUDE.md, not AGENTS.md. Anthropic's advice is to keep CLAUDE.md under 200 lines and move procedures into skills or path-scoped rules — the ceiling is deliberate, because everything loaded costs context tokens.

The problem

Why does Claude Code memory matter?

Every Claude Code session starts empty; the built-in memory closes part of that gap but only inside Claude Code, only for this repository, only on this machine, and only for the first 200 lines of MEMORY.md. The correction you gave in Cursor, the decision you made in ChatGPT and the preference you set in Claude Desktop never arrive. Vodou puts one memory under all of them, on your machine.

A file, not a search

MEMORY.md is an index Claude keeps short by hand; anything past 200 lines or 25 KB is dropped at load. Facts that matter today were pruned last week.

Per tool, per repo, per machine

Auto memory lives under one project directory in ~/.claude; Cursor, Codex and your browser chats have no view of it.

Memory written by the model, unreviewed

Claude decides what to save. Nothing shows you why a memory came back or lets you say “that one is wrong, everywhere”.

How it works

How does Vodou give Claude Code persistent memory?

Vodou's installer registers four hooks in .claude/settings.json; a small hook binary forwards each event to the Vodou daemon over a Unix socket, which searches a local SQLite memory and hands back the relevant facts as additional context.

STEP 1
Install the hooks.
install.sh writes .claude/settings.json for Claude Code and .cursor/hooks.json for Cursor with the absolute path already filled in; vodou-core mem setup (or --global for ~/.claude/settings.json) does the same by hand. The hooks call vodou-hook-bin, a zero-thread binary under 500 KB with no database access; it talks to the daemon over a Unix socket and buffers if the daemon is down.
STEP 2
Four hooks, four jobs.
SessionStart loads the workspace bootstrap and a rendered MEMORY.md (synchronous, 15 s budget). UserPromptSubmit sends the prompt to the daemon, which searches memory and returns prompt-targeted chunks that Claude Code injects as additional context — on every turn, not just at start. PostToolUse runs a NUL-byte guard after every Edit or Write and blocks a file that would break grep and tsc. SessionEnd triggers extraction from the transcript, asynchronously, so the IDE never waits on it.
STEP 3
Render, don't hand-maintain.
MEMORY.md is a snapshot rendered from memory.db — pinned facts first, then project, then global — refreshed by the daemon about every 60 seconds and re-rendered per project at session start. Edits to the rendered file are overwritten; you pin, correct or reject memories in the Vodou Console or with vodou-core mem pin, and the next render carries the fix into every tool.
STEP 4
The same memory everywhere else.
Cursor gets the bootstrap at sessionStart as JSON additional_context; Cursor does not inject hook output per prompt, so the daemon writes a context file the agent is told to read each turn. Codex in Cursor or VS Code reaches Vodou in Agent (Full Access) mode. Claude Desktop, VS Code, Windsurf and Zed attach through the MCP host with a vault per client. In the browser, the Vodou Bridge extension types the same memory into ChatGPT, Claude and 20 other sites with Ctrl+B.
Deep dive: MCP gateway · Browser extension

Capabilities

What can you do with Vodou's Claude Code memory?

Claude Code memory across sessions — on every prompt

The UserPromptSubmit hook searches memory for each prompt, so the fact you need arrives when the question is asked, not only in the first 200 lines at start.

Claude Code persistent memory in a real database

SQLite with FTS5 full-text search, vector embeddings and a cross-encoder reranker; a precision floor injects nothing rather than noise. Facts keep a source, a date and a trust weight.

Claude Code memory search in the Vodou Console: FTS5 and vector results from a local SQLite database

A Claude Code memory hook you can read

The hook config is four JSON entries; the binary has no threads and no database handle. docs/claude-code-hooks.md on GitHub documents every command.

Cursor memory between sessions

The same binary via .cursor/hooks.json: bootstrap at session start, a per-turn context file, extraction at session end. Cursor's own hook API is the limit, not Vodou's.

Claude Code memory in Codex and MCP clients

Codex in Cursor or VS Code uses Vodou in Agent (Full Access) mode; Claude Desktop, Windsurf and Zed attach through vodou-core mcp install <client> and read the vault you assign.

See why a memory was used, then fix it once

Every injected fact carries its provenance; vodou-core mem why or the Console shows which conversation it came from. Correct, reject, pin or undo it and every tool gets the fix.

ProofCounted Sep 2026

hooks: SessionStart, UserPromptSubmit, PostToolUse, SessionEnd.

binary under 500 KB, 0 threads, 0 database handles — a Unix socket to the daemon.

config files written by the installer: .claude/settings.json and .cursor/hooks.json.

60 s

between MEMORY.md renders; 15 s hook timeout; extraction runs async with a 120 s budget.

AI chat sites and 6 named MCP clients read the same memory.

Vodou helps me pick up where I left off without constantly re-explaining the context. I'm able to stay in motion and move my work forward much faster.

Jon B. · Group Creative Director, Financial Services

Sources Anthropic, “How Claude remembers your project” · Claude Code hooks reference · Cursor hooks docs · Vodou docs: claude-code-hooks.md

Comparison

How does Vodou compare to Claude Code's built-in memory, Claude-Mem and Mem0?

Claude Code's built-in memory is free, on by default and needs nothing installed; Claude-Mem is a free, 94,000-star Apache-2.0 plugin that compresses tool observations into SQLite plus Chroma for Claude Code, Cursor, Codex and more; Mem0's Claude Code plugin keeps memory in Mem0's cloud and shares project memory across a team. Vodou's memory also comes from your browser chats and messaging apps and can run skills and tools — at $10 a month after 60 days, with a free account required.

→Scroll the table sideways to see 3 columnsall 5 columns

CAPABILITY	VODOU public alpha	CLAUDE CODE BUILT-IN	CLAUDE-MEM	OBSIDIAN VAULT + MCP	MEM0 CLAUDE CODE PLUGIN
What it stores	facts extracted from sessions, with source, date, trust weight	CLAUDE.md instructions + auto-memory notes Claude writes	AI-compressed “tool usage observations” + session summaries	your Markdown notes	memories extracted from your prompts, Claude's answers and changed file paths
Where	local SQLite memory.db (chmod 600)	Markdown under ~/.claude/projects/<project>/memory/, machine-local	local SQLite + Chroma; optional cmem.ai cloud mirror	your vault, via the Local REST API community plugin	Mem0 Platform cloud (local queue only)
Search	FTS5 + vector + reranker	none — first 200 lines / 25 KB of MEMORY.md loaded; topic files read on demand	FTS5 + Chroma vector (hybrid)	simple text search	Mem0 search (vector; graph on Pro)
Injected when	session start and every prompt	session start	session start; MCP search tools on demand	when the agent calls the tool	first prompt of a session (up to 5); search_memories / /mem0:search after
Extraction	session end, async, by the model you pick, provenance kept	Claude decides during the session	Claude Agent SDK compresses at Stop; 5 lifecycle hooks	none	every 5 exchanges + session end, sent to Mem0
Works in Cursor	yes (session start + context file)	no	yes	any MCP client	yes (Cursor plugin in repo)
Works in Codex / other agents	Codex (Agent Mode), MCP clients	no	OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode + more	any MCP client	Codex, Kimi Code; Platform MCP for any client
Memory from browser chats (ChatGPT, Claude…)	22 sites via Vodou Bridge	no	no	no	no (Chrome extension archived Mar 2026)
Memory from Slack, Telegram…	Unlimited (installable)	no	no	no	no
Shared with a team	no	CLAUDE.md via git; auto memory no	Team plan (cmem.ai)	if you share the vault	yes — shared project memory per repo
See why a memory was used	yes, per retrieval	open the file	observation IDs + web viewer	open the note	search results; local log of each search
Memory can run skills / tools	yes — unlimited skills and MCP servers	no	no	no	no
Adoption	public alpha	every Claude Code install	94.1k GitHub stars	4.4k stars (mcp-obsidian)	65.5k stars (mem0 repo)
Price	$10/mo BYOK · 60-day free trial	included with Claude Code	free (Apache-2.0); CMEM Cloud $20/mo optional	free (MIT)	Free: 10k adds + 1k retrievals/mo · $19/mo · $249/mo
Needs an account	yes (free; licenses the engine)	Claude account or API key	optional — installer asks for sign-in, skippable	no	yes — Mem0 Platform API key

Sources checked (2026-09-17); competitor columns are as of that date.

Claude Code built-in — code.claude.com/docs/en/memory
Claude-Mem — github.com/thedotmack/claude-mem (README; Apache-2.0, 94,075 stars via GitHub API) · hooks architecture · cmem.ai (CMEM Cloud $20/mo, Team $333/seat/mo)
Obsidian vault + MCP — github.com/MarkusPfundstein/mcp-obsidian (MIT, 4.4k stars, 7 tools) · obsidian-local-rest-api (MIT)
Mem0 — Claude Code plugin (README + hooks/hooks.json, v0.3.1) · mem0.ai/pricing · mem0.ai/blog/claude-code-memory · mem0 PR #6530 (OpenMemory removed from the monorepo 2026-07-29; snapshot at mem0ai/openmemory) · mem0-chrome-extension (archived)

Vodou column: 4 hooks and 22 AI sites, checked against the product on 2026-09-17.

FAQ

Frequently asked questions about Claude Code memory

How does Claude Code memory work?

Two ways, both documented by Anthropic: CLAUDE.md files you write are loaded at the start of every session, and auto memory lets Claude save notes about your preferences, corrections and project into a per-repository MEMORY.md plus topic files. Vodou adds a third: hooks that inject facts from a local SQLite memory at SessionStart and on every prompt, and extract new ones at SessionEnd.

Where is Claude Code memory located?

CLAUDE.md lives in your project (./CLAUDE.md, ./.claude/CLAUDE.md, ./CLAUDE.local.md) or your home directory (~/.claude/CLAUDE.md). Auto memory lives at ~/.claude/projects/<project>/memory/, with a MEMORY.md index and one file per memory. Vodou's memory lives in memory.db, a SQLite file in your Vodou workspace, and is rendered into a MEMORY.md for each project at session start.

What is the difference between CLAUDE.md and auto memory?

You write CLAUDE.md; Claude writes auto memory. CLAUDE.md holds instructions and rules for a project, your user profile or an organisation. Auto memory holds learnings — your role, corrections, in-flight work, external references — per repository, and only its first 200 lines or 25 KB load. Vodou sits under both: its hooks add a searched, provenance-tagged memory that is the same in Cursor, Codex and your browser.

Does Claude Code have persistent memory across sessions?

Yes — auto memory is on by default and carries notes between sessions of the same repository on the same machine; CLAUDE.md persists as long as the file does. What does not persist is anything outside that repo, that machine or that tool. Vodou's memory persists across all three: switch to Cursor, open ChatGPT, or start a new repo, and the same facts come back.

How do I give Claude Code persistent memory?

Turn on auto memory (it is on by default; check with /memory) and keep a CLAUDE.md in the project. For memory that is searched rather than truncated and that follows you into other tools, install Vodou: its installer writes four hooks into .claude/settings.json, and from then on relevant facts arrive on every prompt from a local SQLite database.

How do I disable Claude Code auto memory?

Run /memory in a session and toggle auto memory off, set "autoMemoryEnabled": false in ~/.claude/settings.json or a project's settings, or export CLAUDE_CODE_DISABLE_AUTO_MEMORY=1. Vodou's hooks are independent: you can keep auto memory off and still receive Vodou's memory, or remove the four entries from .claude/settings.json to stop Vodou.

Is there a Claude Code memory plugin?

Several. Claude-Mem (94,000+ GitHub stars, Apache-2.0) compresses tool observations into SQLite plus Chroma and works in Cursor and Codex too; smaller plugins add hybrid search or an Obsidian vault. Vodou is a memory layer rather than a plugin: four hooks in .claude/settings.json, a local SQLite memory that also comes from 22 browser AI sites and every messaging channel you connect, and skills and tools that act on it.

Does Cursor have memory between sessions?

Cursor does not ship a per-project auto memory like Claude Code's. With Vodou, Cursor gets the workspace bootstrap at sessionStart through its hooks API, a per-turn context file the agent is told to read (Cursor ignores hook output on prompt submit), and extraction at sessionEnd — all from the same memory.db Claude Code uses. The installer writes .cursor/hooks.json for you.

Can Claude Code memory transfer to Codex?

Not natively — auto memory is Claude Code's own directory. With Vodou the memory was never inside one tool: what Claude Code learned is in a local SQLite database, and Codex running in Cursor or VS Code in Agent (Full Access) mode reads it through Vodou, as do Claude Desktop and any MCP client. Vodou can also import existing ChatGPT, Claude and Obsidian exports.