v0.3.0@db0-ai/claude-code

Claude Code remembers your project.
db0 makes it remember you.

Claude Code's built-in memory is scoped per git repo. Teach Claude your preferences once — commit style, tool choices, output format — and db0 carries them into every project, on every machine.

10 MCP tools. No signup, no API key. Same db0 database accessible from CLI, web inspector, OpenClaw, or any TypeScript project.

Quick start

Option A: MCP Server (fastest)

Run in Claude Code:

claude mcp add --transport stdio db0 -- npx -y @db0-ai/claude-code

Or add to your project's .mcp.json:

{
  "mcpServers": {
    "db0": {
      "command": "npx",
      "args": ["-y", "@db0-ai/claude-code"]
    }
  }
}

10 MCP tools immediately. No signup, no API key. Persistent SQLite at ~/.claude/db0.sqlite.

Option B: Full Plugin (tools + skills + hooks)

/plugin marketplace add db0-ai/db0
/plugin install db0@db0-ai-db0

Adds MCP tools plus skills (/db0:inspect, /db0:ingest) and hooks.

Verify it works: ask Claude "what db0 tools do you have?" — it should list 10 tools starting with db0_.

Why Claude Code still loses knowledge

The re-teaching problem

Claude Code’s memory is project-scoped. Teach it “don’t add Co-Authored-By to commits” in one repo, start a new project, and you’re teaching it again. Every correction you’ve made is trapped in that one repository’s memory directory.

The machine problem

Memory is stored by absolute filesystem path. Work on the same project from two machines and you have two separate, diverging memory stores. There’s no sync.

The stale fact problem

When something changes — you switch frameworks, update a preference, change how you structure commits — the old fact stays in MEMORY.md alongside the new one. Claude has to guess which one is current.

The state problem

Claude Code memory stores facts about the codebase. It can’t store where you are in a task. Pause a multi-session refactor and come back: Claude knows your architecture but not which modules you’ve already touched.

What db0 adds

Out of the box, with no further configuration.

10 MCP tools

Memory CRUD, semantic search, fact updating, state checkpoints, and structured logging — all via standard MCP protocol.

Persistent storage

SQLite at ~/.claude/db0.sqlite. Survives restarts, survives sessions. Your agent accumulates knowledge over time.

Scoped memory

4 scopes (task/session/user/agent) with different lifetimes. User preferences persist forever; task scratch work stays temporary.

Memory superseding

When facts change, old memories are marked superseded, not deleted. Full audit trail preserved. Search returns only active memories.

Semantic search

Built-in hash embeddings, zero API calls, zero config. Similarity + scope filtering in a single search call.

L0 summaries

Auto-generated one-line summaries for token-efficient recall. More memories fit into the context window.

State checkpoints

Save and restore execution progress. Pick up where you left off across sessions.

Skills

/db0:inspect to browse memories, /db0:ingest to store facts. Natural language interface on top of MCP tools.

How it works in practice

You don't need to learn tool names. Just talk to Claude the way you normally would.

> Remember that I always want conventional commits.

Claude saves this as a user-scoped preference. It applies in every project from now on.

> Actually, switch to gitmoji for commits.

Claude finds the old commit preference and updates it in one call. The old fact is retired, not deleted.

> Where were we on the auth refactor?

Claude restores the last state checkpoint and picks up where you left off.

> What do you know about my preferences?

Claude searches user-scoped memories and lists everything it remembers about you across all projects.

MCP Tools

All 10 tools are available to Claude Code immediately after installation.

Tool	Description
db0_memory_write	Store a fact with scope, tags, summary, and optional superseding
db0_memory_search	Semantic search across memories with scope/tag filtering
db0_memory_list	List memories by scope
db0_memory_get	Get a specific memory by ID
db0_memory_update	Update a fact — finds the old version, supersedes it, writes the new one
db0_memory_delete	Delete a memory
db0_memory_stats	Memory statistics by scope and status
db0_state_checkpoint	Create a state checkpoint
db0_state_restore	Restore the most recent checkpoint
db0_log_query	Query structured log entries

Memory superseding in action

When facts change, old memories are preserved but excluded from search. Full audit trail.

Claude Code session

You: "remember I prefer dark mode"
  db0_memory_write({ content: "User prefers dark mode", scope: "user" })

You: "actually I switched to light mode"
  db0_memory_update({
    oldContent: "User prefers dark mode",
    newContent: "User prefers light mode",
    scope: "user"
  })

Memory scopes

Claude Code's built-in memory is equivalent to agent scope — per-project, per-machine. The user scope is what's new: preferences that follow you everywhere.

Scope	Lifetime	Example
user	Permanent, cross-project	Commit style, tool choices, output format
agent	Permanent, this project	Architecture, patterns, project conventions
session	Current session	In-progress decisions, temporary context
task	Current task	Scratch work, intermediate results

Cross-device memory with Postgres

Claude Code's built-in memory is stored by absolute filesystem path. If your username, home directory, or mount point differs between machines — and it almost always does — the memory directory hash is different. Same project, different machine, zero shared memory.

db0 uses the database connection as the source of truth, not the filesystem path. Point to any hosted Postgres with pgvector:

.mcp.json

{
  "mcpServers": {
    "db0": {
      "command": "npx",
      "args": ["-y", "@db0-ai/claude-code"],
      "env": {
        "DB0_STORAGE": "postgresql://user:pass@your-host/db0"
      }
    }
  }
}

Configuration

Environment variables for the MCP server.

Variable	Default	Description
DB0_STORAGE	~/.claude/db0.sqlite	Storage path. Use a PostgreSQL connection string for cross-device sync.
DB0_AGENT_ID	claude-code	Agent identifier for scoping memories.

How it fits

The plugin is an MCP server that wraps the db0 harness. Same SDK, same database, different entry point.

Claude Code
  │
  │ MCP protocol (stdio)
  │
  ▼
db0 MCP Server (@db0-ai/claude-code)
  │
  ├── memory tools  → db0 harness → memory()
  ├── state tools   → db0 harness → state()
  └── log tools     → db0 harness → log()
  │
  ▼
SQLite (local) or PostgreSQL + pgvector (cloud)

How it compares

db0 vs. other Claude Code memory solutions.

	db0	total-recall	Nemp	MemoryGraph	mem0	CLAUDE.md
Storage	SQLite / Postgres	Unknown (tiered)	JSON files	SQLite / Neo4j	Vector DB (cloud)	Plain text
Semantic search	Yes (built-in embeddings)	Unknown	Term expansion	Fuzzy matching	Yes (LLM-powered)	grep only
Memory scopes	4 (task/session/user/agent)	Tiered	Flat	Flat	3 (user/session/agent)	None
Superseding	Yes (audit trail)	Correction propagation	No	No	No	Overwrites
State management	Checkpoints + branching	No	No	No	No	No
Structured logging	Yes	No	No	No	No	No
Requires LLM	No	Unknown	No	No	Yes	No
Requires account	No	No	No	No	Yes	No
Cross-device sync	Yes (Postgres)	No	No	No	Yes (cloud)	git
L0 summaries	Yes (auto-generated)	No	No	No	No	No

Part of the db0 ecosystem

The same memory database is compatible with every db0 package.

@db0-ai/core

Core SDK — use db0 programmatically in any TypeScript project

@db0-ai/openclaw

OpenClaw ContextEngine plugin for full context lifecycle

@db0-ai/inspector

Web UI for browsing memory, state, and logs

@db0-ai/cli

CLI for memory operations (list, search, stats, export, import)

← All integrations

Claude Code remembers your project.db0 makes it remember you.