Memory System

Persistent project memory for Claude Code across sessions. Memories are markdown files in docs/memory/ (git-trackable, human-editable); an optional SQLite index adds fast search. Everything stays on your machine.

Updating

New install — nothing to do. cf install / cf mcp registers the server once for all your projects.

Upgrading from before v1.37.0 — older setups added a coding-friend-memory entry to each project's .mcp.json. That entry now shadows the global server (Claude Code precedence: local > project > user). In each affected project, run:

cf update      # registers user-scope, strips the legacy .mcp.json entry

then restart Claude Code (the stdio server does not hot-reload). Not migrating breaks nothing — the legacy entry still works; you just don't get the new benefits until removed.

Setup

cf mcp

Registers the Memory MCP at user scope — equivalent to:

claude mcp add --scope user coding-friend-memory -- npx -y coding-friend-cli mcp-serve

No path argument is needed: the server resolves the current project at runtime (CLAUDE_PROJECT_DIR → git repo root → docs/memory). Restart Claude Code after registering.

Each project stays isolated:

• Markdown source — <project>/docs/memory/ (committed in the project repo)
• Search index — ~/.coding-friend/memory/projects/<slug>/db.sqlite

Core ideas

• Markdown is the source of truth — every memory is a .md file with YAML frontmatter. The SQLite index is a rebuildable cache (cf memory rebuild re-creates it, never loses data).
• Always works — 3 tiers are auto-selected by what's installed: SQLite hybrid search (full) → in-memory daemon (lite) → plain markdown grep. The basic tier needs no setup.
• Local-only — nothing leaves your machine.
• Lazy — a project's database is created only when the first memory is stored.

Capturing memories

• /cf-scan — scan the project and populate memory (run once, or to refresh).
• /cf-remember — save knowledge from the current session.
• Automatic — enable memory.autoCapture to capture session summaries plus notable findings from /cf-fix, /cf-review, and /cf-sys-debug.

Skills use the MCP tools (memory_store, memory_search, …) behind the scenes — you rarely call them directly.

Memory types

Convention memories (preference) are also synced to a ## CF Memory: Project Rules section in the project's CLAUDE.md so rules stay loaded every session.

Markdown format

---
title: "API Authentication Pattern"
description: "Auth module uses JWT tokens in httpOnly cookies with RS256"
type: fact
tags: [auth, jwt, api, security]
importance: 3
created: 2026-03-12
updated: 2026-03-12
source: conversation
---
The auth module uses RS256-signed JWT tokens...

The description is the most important field for search quality — keep it a factual one-liner under 100 chars. importance is 1–5 (default 3); source is conversation or auto-capture.

Settings

All options live in .coding-friend/config.json under memory. See the full config reference.

Tier

memory.tier selects the backend — "auto" (default) picks the best available, or force one of "full" | "lite" | "markdown":

{ "memory": { "tier": "auto" } }

Embedding (semantic search)

Works out of the box (Transformers.js, Xenova/all-MiniLM-L6-v2, ~23 MB, auto-downloaded). For higher quality, use a local Ollama model:

{
  "memory": {
    "embedding": {
      "provider": "ollama",
      "model": "nomic-embed-text",
      "ollamaUrl": "http://localhost:11434"
    }
  }
}

Run cf memory rebuild after changing the model. Switching to different dimensions auto-disables vector search until you rebuild (keyword search keeps working; markdown is never affected).

Auto-capture

memory.autoCapture (boolean, default false) — automatically capture session summaries and skill findings.

Reference

Full tool list, resources, config snippets, and health checks: MCP Servers → Memory MCP.