name: how-it-works description: Explain how claude-mem captures observations, when memory injection kicks in, and where data lives. Use when the user asks "how does claude-mem work?" or "what is this thing doing?". metadata: version: "1.0.1"

How claude-mem works

What it does

Every Read, Edit, and Bash that Claude makes turns into a compressed observation. Observations get summarized at session end. Relevant ones get auto-injected into future prompts so the next session starts with context from the last one — no re-explaining the codebase, no re-discovering decisions.

When it kicks in

Memory injection starts on your second session in a project.

The first session in a fresh project seeds memory; subsequent sessions receive auto-injected context for relevant past work. Run /learn-codebase if you want to front-load the entire repo into memory in a single pass (~5 minutes, optional).

Getting better over time

claude-mem:harness-review reads the same store back and asks whether the setup is actually improving: how often you had to correct the agent, which facts it establishes from scratch session after session, which tool errors it routed around instead of telling you about, and which rules it was given and does not follow. It also looks for a procedure that worked and is worth keeping. Each finding comes out as one concrete change to a hook, a setting, or an instruction file, and every run scores the previous run's changes before measuring anything new.

Where data lives

Everything stays in ~/.claude-mem on this machine.

Nothing leaves your machine except calls to whichever AI provider you configured for compression (Claude / OpenRouter / Gemini). Local installs contact cmem.ai once, at signup, to create the sign-in link; nothing else is sent to cmem.ai. The SQLite database, vector index, logs, and settings all live under that directory and are removed cleanly on npx claude-mem uninstall.