AutoGineer
Generated banner for Basic Memory
Generated logo for Basic Memory

Basic Memory

Memory serverOfficial Basic Machines project

Created by Basic Machines

Published in basicmachines-co/basic-memory. Publisher page

4,552 GitHub stars

What it is

AI conversations that actually remember. Never re-explain your project to your AI again. Join our Discord: https://discord.gg/tyvKNccgqN
— the description by Basic Machines

AutoGineer overview, from the brain’s own files

Basic Memory is a memory system designed to give AI agents persistent, long-term recall. It operates as an MCP server that bridges the gap between human-readable Markdown files and AI agent context. By treating a directory of Markdown files as a knowledge graph, it allows agents to read, write, and search information across sessions. It supports both local-first operation for privacy and an optional cloud-hosted service for cross-device synchronization. The system includes advanced features like semantic vector search, hybrid full-text retrieval, and a schema system for validating knowledge structure, ensuring that agents can reliably store and retrieve project context, learnings, and documentation.

How it works

Memory model: Hybrid

AutoGineer overview, from the brain’s own files

Basic Memory functions as an MCP server that monitors and manages a collection of Markdown files on your disk. It uses a hybrid memory model that combines standard file-based storage with a database layer (SQLite or Postgres) to enable semantic search and vector indexing. When an agent interacts with the server, it uses specific tools to ingest, curate, or retrieve information from these files. The system automatically handles file synchronization and provides metadata-rich search results, allowing agents to maintain context across different tasks and projects without needing to re-learn information.

Folders
FolderRoleFiles
.claudeagent-config15
.codexagent-config1
.githubagent-config20
docsdocs41
scriptsscripts16
skillsagent-instructions33
srcsource-code529
teststests595
.agentsfolder58
.claude-pluginfolder1
benchmarksfolder155
integrationsfolder175
pluginsfolder72
test-intfolder179

The agent reads

The agent writes

Requirements

Runtimes: Python >=3.12

Databases: Milvus, PostgreSQL, Redis, SQLite

API keys (by name): COHERE_API_KEY, OPENAI_API_KEY

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Google Antigravity, Kiro, OpenCode, Amp, Roo Code, Cline, JetBrains Junie, Devin (ex-Windsurf)

Set it up

  1. This brain runs code automatically: 4 hooks (claude-code, codex), 1 script. Review plugins/claude-code/hooks/hooks.json, plugins/codex/hooks/hooks.json, src/basic_memory/cli/commands/install.py before opening the folder in Claude Code. No step below turns a hook on for you.

    • plugins/claude-code/hooks/hooks.json: uv run --quiet --script "${CLAUDE_PLUGIN_ROOT}/hooks/session_start.py"
    • plugins/claude-code/hooks/hooks.json: uv run --quiet --script "${CLAUDE_PLUGIN_ROOT}/hooks/pre_compact.py"
    • plugins/codex/hooks/hooks.json: uv run --quiet --script "${PLUGIN_ROOT}/hooks/session_start.py"
    • plugins/codex/hooks/hooks.json: uv run --quiet --script "${PLUGIN_ROOT}/hooks/pre_compact.py"
    • src/basic_memory/cli/commands/install.py: python src/basic_memory/cli/commands/install.py
  2. Not scanned by AutoGineerIts dependencies are installed by pip or uv when you run it and were not scanned by AutoGineer (43 declared). https://pypi.org/project/basic-memory/

  3. Created by Basic Machines. Published in basicmachines-co/basic-memory. Licence: GNU Affero General Public License v3.0 only.

Usage

AutoGineer overview, from the brain’s own files

  • Connect the server to an MCP-compatible AI client like Claude Desktop, Cursor, or Codex.
  • Use natural language prompts to save project decisions, research findings, or daily logs directly into your memory vault.
  • Query the agent to retrieve specific information from past conversations or project documentation.
  • Edit notes manually in any Markdown editor while the agent simultaneously updates or references the same files.
“Create a note about our project architecture decisions.”
The agent creates a new Markdown file in the vault containing the documented architecture, which is then indexed for future retrieval.
“Find information about JWT auth in my notes.”
The agent performs a semantic search across the vault and returns relevant snippets or links to notes discussing JWT implementation.
“What have I been working on this week?”
The agent analyzes the recent file activity and notes to provide a summary of your progress and active tasks.

Documentation by Basic Machines

<!-- mcp-name: io.github.basicmachines-co/basic-memory -->

Image: MCP Toplist

Image: License: AGPL v3 Image: PyPI version Image: Python 3.12+ Image: Tests Image: Ruff Image: untitled Image: untitled Image: Ask DeepWiki

Skip the install — try Basic Memory in the cloud

Claude, Codex, or Cursor connected in 30 seconds. No Python, no JSON, no terminal. $15.00/mo locked in for life (12.50/mo yearly pricing). 7-day free trial — cancel any time before day 7 if it's not for you. Beta pricing — sign up now and your rate never goes up. OSS users: code BMFOSS takes another 20% off for 3 months.

Start free trial →

Basic Memory Teams is now available!

Give your team a single, shared cloud workspace. Knowledge isn't confined to one person — anything a teammate writes is immediately available to everyone else and to their AI assistants. Edit a note together in real time, hand work off between humans and agents, and build one connected knowledge base instead of scattered copies. Same pricing - start with one user and add more as needed.

Basic Memory

Your AI never forgets again.

Pick up right where you left off — in Claude, Codex, Cursor, ChatGPT, or anything that speaks MCP. Your knowledge lives as Markdown files that both you and your AI can read, write, and search.

  • Local-first. Plain text on your disk. Forever.

  • Two-way. AI and humans write to the same files; sync keeps them in step.

  • A real knowledge graph. Observations and wikilinks compound into context.

  • Semantic search. Find notes by meaning, not just keywords, with optional cross-encoder reranking for higher-quality vector and hybrid results.

  • MCP-native. Works with every major AI client and IDE.

  • Progressive tool discovery. Every tool is tagged with behavior hints (read-only, destructive, idempotent) so agents pick the right tool on demand — no wasted context trying things to see what they do.

  • Cloud, optional. Sync across devices when you want — never required.

Get started

Pick the path that fits you. Both run the same product on the same Markdown.

<table> <tr> <th width="50%">☁️ &nbsp; Cloud</th> <th width="50%">💻 &nbsp; Local install</th> </tr> <tr> <td valign="top">

30 seconds. Sign up, connect your AI client, done.

  • Works in any browser

  • Mobile, web, desktop

  • Cross-device sync built in

  • We handle hosting, backups, snapshots

$15.00/mo locked for life · 7-day free trial · cancel any time

Start free trial →

</td> <td valign="top">

2 minutes. Install, configure your AI client, run.

  • Free forever (AGPL-3.0)

  • All data on your disk

  • Air-gapped friendly

  • Requires Python via uv

uv tool install basic-memory --prerelease=allow

--prerelease=allow is required: Basic Memory 0.23 depends on a FastMCP 4 pre-release, and uv only accepts pre-releases of transitive dependencies when told to — without the flag it silently installs an older release. The same flag goes on every uvx / uv tool upgrade command below.

For Postgres deployments that store semantic vectors in Milvus, install the first-party optional extra instead:

uv tool install "basic-memory[milvus]" --prerelease=allow

Configure your client ↓

</td> </tr> </table>

What people are saying

Basic Memory changed my whole relationship with LLMs. I switched from GPT and Gemini to exclusively Claude and Claude Code because of this integration and am completely revamping all our company's processes around a Basic Memory workflow.

— Alex, TrainerDay

Basic Memory is the missing 'wow' factor in AI chatbots. Now I can't imagine Claude or Claude Code without it.

— Caleb, Caleb Picker Consulting

I don't code without Basic Memory anymore. It's such a time saver to be able to refer to projects I don't currently have active and keep a running log of all my learnings and ProTips.

— @groksrc, Developer

More on basicmemory.com.

Basic Memory Cloud

The hosted version of Basic Memory. Same product, same Markdown files, same MCP tools — we just host the database, run the sync, and put it on your phone.

What you get

  • Every device, same brain. Your knowledge graph on web, mobile, and desktop. No copy-paste between machines.

  • Connect any MCP client. Claude Desktop, Claude Code, Codex, Cursor, ChatGPT (Custom GPTs), VS Code — one-click connect from the web app.

  • Bidirectional sync to local. Edit on your phone, see it in Obsidian on your laptop. rclone-powered with conflict resolution.

  • Snapshots and backups. Point-in-time restore. Browse history. Never lose a note.

  • No lock-in. Your notes are plain Markdown. Export to local Markdown any time — same files, same format, same wikilinks. Cancel anytime, your data stays yours.

Built on WorkOS AuthKit, Neon Postgres, and Tigris S3.

Pricing

$15.00/mo, locked in for the life of your subscription (regular price $19). Sign up during beta and the rate never goes up — as long as you stay subscribed, you keep the price. One plan, no tiers, no surprise upgrades. Unlimited notes, unlimited projects, every feature.

  • 7-day free trial. Cancel any time before day 7 if it's not for you.

  • Cancel anytime after that too — export your notes whenever you want.

  • OSS users: code BMFOSS for another 20% off for 3 months (~$11.40/mo).

Start your 7-day free trial →

Cloud vs. local

CloudLocal
Setup time30 seconds2 minutes (requires Python)
Cost$15.00/mo, locked for life (7-day trial)Free
StorageWe host (Tigris S3)Your disk
Cross-device syncBuilt inManual (Git, Syncthing, etc.)
Mobile accessYes (web + app)No
Air-gappedNoYes
Your data stays yoursYes — export anytimeYes — already there
Source codeAGPL-3.0AGPL-3.0
Snapshots & backupsBuilt inRoll your own

Both paths use the same OSS engine and the same Markdown files. There's no lock-in either way — flip between them when your needs change.

Works with the tools you already use

ClientTransportNotes
Cloud web apphttpsSign in at basicmemory.com — no install
Claude Desktopstdio/httpsmacOS / Windows / Linux
Claude Codestdio/httpsclaude mcp add
Codexstdio/httpsOpenAI's coding agent
Cursorstdio/https.cursor/mcp.json
VS Codestdio/httpsNative MCP support
ChatGPThttpsCustom GPT actions (search / fetch)
Obsidian—Reads/writes the same Markdown directly
Anything MCPstdio/httpsIf it speaks MCP, it works

Official agent packages

This repository is also the canonical home for Basic Memory's host-native agent packages. The core Python package, Claude Code plugin, shared skills, Hermes plugin, and OpenClaw plugin all ship from the same source tree.

Maintainers can verify the whole consolidated surface from the repo root:

just package-check

Package-local justfiles are also available when working inside one host:

just package-check-claude-code
just package-check-skills
just package-check-hermes
just package-check-openclaw
Claude Code plugin

The Claude Code plugin is the bridge between Claude's working memory and Basic Memory — session-start briefings, pre-compaction checkpoints, an opt-in capture output style, and /basic-memory:bm-setup · :remember · :share · :status.

Connect the Basic Memory MCP server first — see Connect your AI client. The plugin's hooks and skills call it, so it's a hard prerequisite. Then install the plugin:

bm install claude-code

That registers the marketplace and installs the plugin through Claude Code. Add --scope project to declare both in the repository's settings for a team, or --dry-run to see the underlying claude plugin commands without running them.

Source: plugins/claude-code.

Shared skills

Framework-agnostic SKILL.md files live in skills/. If your Skills CLI supports repository subdirectory sources:

npx skills add basicmachines-co/basic-memory/skills -g

For Claude and ChatGPT, upload basic-memory.zip or basic-memory-chatgpt.zip from the skills-latest release; see skills/README.md.

If your installed Skills CLI cannot load that source, update the CLI or copy the memory-* directories from skills/ into your agent's skills directory.

Hermes

Hermes keeps its native plugin shape under integrations/hermes:

hermes plugins install basicmachines-co/basic-memory/integrations/hermes

Hermes does not install a plugin's Python dependencies, so also add the mcp package to the Hermes venv — see the plugin README for that step and the supported Hermes releases.

OpenClaw

OpenClaw stays package-native and publishes from integrations/openclaw:

openclaw plugins install @basicmemory/openclaw-basic-memory

Pick up where you left off

https://github.com/user-attachments/assets/a55d8238-8dd0-454a-be4c-8860dbbd0ddc

Connect your AI client

If you went the Cloud route, the web app walks you through client connect. The snippets below are for local installs.

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "basic-memory": {
      "command": "uvx",
      "args": ["--prerelease=allow", "basic-memory", "mcp"]
    }
  }
}

Restart Claude Desktop. Notes live in ~/basic-memory by default.

<details> <summary><b>Claude Code, Codex CLI, Cursor, VS Code, ChatGPT, Obsidian</b></summary>

Claude Code
claude mcp add basic-memory -- uvx --prerelease=allow basic-memory mcp

For the full memory bridge — session briefings, pre-compaction checkpoints, and the /basic-memory:* commands — also install the Claude Code plugin on top of this.

Codex CLI

Add to ~/.codex/config.toml:

[mcp_servers.basic-memory]
command = "uvx"
args = ["--prerelease=allow", "basic-memory", "mcp"]

Codex can keep its default MCP approval behavior, or you can pre-approve eligible Basic Memory tools by adding this server-scoped setting to the same table:

[mcp_servers.basic-memory]
command = "uvx"
args = ["--prerelease=allow", "basic-memory", "mcp"]
default_tools_approval_mode = "approve"

This does not disable Codex approvals globally or expand which Basic Memory projects the server can access. Codex still requires approval for tools that advertise a destructive annotation, including Basic Memory's writes, edits, and deletes. If you installed the Basic Memory Codex plugin, use its plugin-scoped configuration instead.

Cursor

Add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "basic-memory": {
      "command": "uvx",
      "args": ["--prerelease=allow", "basic-memory", "mcp"]
    }
  }
}
VS Code

Add to your User Settings (JSON):

{
  "mcp": {
    "servers": {
      "basic-memory": {
        "command": "uvx",
        "args": ["--prerelease=allow", "basic-memory", "mcp"]
      }
    }
  }
}
ChatGPT

Basic Memory exposes OpenAI-compatible search and fetch tools for Custom GPT actions. See the ChatGPT integration guide.

Obsidian

No setup. Point Obsidian at ~/basic-memory (or your project folder) and the same wikilinks, frontmatter, and Markdown your AI writes appear in your graph view. Edit either side — sync handles the rest.

</details>

Try a prompt:

"Create a note about our project architecture decisions."
"Find information about JWT auth in my notes."
"What have I been working on this week?"

What's New

  • Automatic updates. Basic Memory keeps itself up to date for uv tool and Homebrew installs; bm update triggers a manual check.

  • Semantic vector search. Find notes by meaning, not just keywords. Hybrid full-text + vector ranking with FastEmbed embeddings, on SQLite or Postgres.

  • Optional search reranking. Rescore the strongest vector and hybrid candidates with a local FastEmbed cross-encoder or a LiteLLM-backed provider.

  • Schema system. Infer, validate, and diff the structure of your knowledge base with bm_schema_infer(), bm_schema_validate(), and bm_schema_diff().

  • Per-project cloud routing. Route individual projects through the cloud while others stay local, via API key (bm project set-cloud).

  • Explicit note changes. bm_edit updates existing notes; bm_write creates notes and guards against accidental overwrites.

  • Richer search results. Matched chunk text is included so the LLM gets context, not just hits.

  • FastMCP 3.0 + tool annotations. Every tool ships with MCP behavior hints (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) so agents can discover capabilities progressively at runtime instead of guessing or burning tokens.

  • CLI overhaul. --json output for scripting, workspace-aware commands, and an htop-inspired project dashboard.

Full CHANGELOG for v0.18 → v0.20.

Optional cross-encoder reranking

Reranking adds a second relevance pass after vector or hybrid retrieval. It is disabled by default because it adds inference latency and, for the local provider, a first-run model download. Text, title, and permalink searches keep their existing ranking.

Enable the default local FastEmbed reranker:

export BASIC_MEMORY_RERANKER_ENABLED=true

The default model is jinaai/jina-reranker-v1-tiny-en. To use a hosted reranker through LiteLLM instead, first install the optional LiteLLM SDK, then configure it:

export BASIC_MEMORY_RERANKER_ENABLED=true
export BASIC_MEMORY_RERANKER_PROVIDER=litellm
export BASIC_MEMORY_RERANKER_MODEL=cohere/rerank-v3.5
export COHERE_API_KEY=...

The feature fails fast on invalid configuration and does not silently fall back to retrieval order when an enabled provider fails. See the semantic search guide for provider setup, all settings, tuning, pagination, and failure behavior.

Why Basic Memory

Most LLM conversations are ephemeral. You ask a question, get an answer, then everything is forgotten. Workarounds have limits:

  • Chat history captures conversations but isn't structured knowledge.

  • RAG lets the LLM query your documents but not write back to them.

  • Vector DBs need complex infra and usually live in someone else's cloud.

  • Knowledge graphs need specialized tooling to maintain.

Basic Memory takes a simpler path: structured Markdown files that humans and LLMs both read and write.

  • All knowledge stays in plain files you control.

  • Both sides read and write to the same files.

  • Familiar Markdown with semantic patterns — no new format to learn.

  • A traversable graph the LLM can follow link by link.

  • Works with the editors you already use (Obsidian, VS Code, anything).

  • Just files plus a local SQLite index. No servers required.

How it works

You're chatting normally about coffee:

I've been experimenting with brewing methods. Pour over gives more clarity than French press, water at 205°F seems best, and freshly ground beans make a huge difference.

Ask the LLM to capture it:

"Make a note on coffee brewing methods."

A Markdown file appears in your project directory in real time:

---
title: Coffee Brewing Methods
permalink: coffee-brewing-methods
tags: [coffee, brewing]
---

# Coffee Brewing Methods

## Observations
- [method] Pour over highlights subtle flavors over body
- [technique] Water at 205°F (96°C) extracts optimal compounds
- [principle] Freshly ground beans preserve aromatics

## Relations
- relates_to [[Coffee Bean Origins]]
- requires [[Proper Grinding Technique]]
- affects [[Flavor Extraction]]

Next session, the LLM picks up the thread. It follows the relations to surface what you already know about Ethiopian beans and burr grinders, and builds on it instead of starting over. You see the same files in Obsidian or your editor. Edit them by hand — the AI sees your changes too.

Real two-way flow: humans edit Markdown, LLMs read/write through MCP, sync keeps everything consistent, and the source of truth is always your files.

The Markdown format

Each file is an Entity. Entities have Observations (facts about them) and Relations (links to other entities). That's the whole grammar.

Frontmatter
---
title: <Entity title>
type: note
permalink: <uri-slug>
tags: [optional, list]
---
Observations

Facts about the entity. Categories in [brackets], tags with #, optional context in parens.

- [method] Pour over highlights subtle flavors
- [tip] Grind medium-fine for V60 #brewing
- [fact] Lighter roasts contain more caffeine than dark
- [resource] James Hoffmann's V60 technique on YouTube
- [question] How does temperature affect compound extraction?
Relations

Wiki-style links that form the graph. Single-token relation types, or quote multi-word ones.

- pairs_well_with [[Chocolate Desserts]]
- grown_in [[Ethiopia]]
- requires [[Burr Grinder]]
- "pairs well with" [[Dark Chocolate]]

Bare - [[Target]] and prose - Worth checking out [[Target]] index as links_to. Full reference in the docs.

MCP tools

Basic Memory exposes these tools to any MCP client. Every tool is annotated with MCP behavior hints (read-only, destructive, idempotent, open-world) so agents can pick the right one without trial-and-error:

  • Content: bm_write, bm_read, bm_edit, bm_move, bm_delete

  • Search & discovery: bm_search, bm_list, bm_find

  • Knowledge graph: bm_context

  • Projects: bm_project_list, bm_project_create, bm_recent; bm_project_delete is separate and requires server opt-in.

  • Schema: bm_schema_validate, bm_schema_infer, bm_schema_diff

  • Manual: bm_man

  • Cloud connector adapters: search and fetch are registered by Cloud only. Local diagnostics use bm doctor.

Most tools default to text; bm_context defaults to JSON. Pass output_format="json" for structured responses. Project-scoped tools accept a name, workspace/project, or external UUID through project. Use bm_man(page="bm-search(3)") for the installed contract, or see the tool guide. CLI commands retain their shell names.

CLI essentials

# Projects
basic-memory project list
basic-memory project add research ~/research
basic-memory project set-cloud research   # route through cloud
basic-memory project set-local research   # revert

# Config
basic-memory config list                        # all settings, effective values, env overrides
basic-memory config set cli_output_style plain  # validated through the config model
basic-memory config unset cli_output_style      # revert to default

# Health & maintenance
basic-memory status
basic-memory doctor              # report project problems and the commands that fix them
basic-memory tool edit ...  # CLI access to MCP tools
basic-memory update              # check for and install updates

# Imports
basic-memory import claude conversations
basic-memory import chatgpt
basic-memory import memory-json

Routing flags (--local / --cloud) force a target when you're in mixed mode. Full CLI reference in the docs.

Auto-updates

CLI installs check for updates every 24 hours by default and apply them silently (so the MCP server keeps responding).

  • Supported install sources: uv tool, Homebrew

  • Skipped for uvx (ephemeral runtime managed by uv)

  • Manual: bm update (check + apply) or bm update --check (check only)

Disable in ~/.basic-memory/config.json:

{ "auto_update": false }

Telemetry

Minimal, anonymous events to understand the CLI-to-cloud conversion funnel.

What we collect: cloud promo impressions, cloud login attempts and outcomes, promo opt-out events.

What we don't: file contents, note titles, knowledge base data, PII, IP addresses, per-command or per-tool tracking.

Events go to our Umami Cloud instance (open-source, privacy-focused) on a background thread — never blocks the CLI.

Opt out:

export BASIC_MEMORY_NO_PROMOS=1

This disables promos and all telemetry.

Logging

Basic Memory uses Loguru. Defaults vary by entry point:

Entry pointDefaultWhy
CLI commandsFile onlyDoesn't interfere with command output
MCP serverFile onlyStdout would corrupt JSON-RPC
API serverFile (local) or stdout (cloud)Docker/cloud uses stdout

Log file: ~/.basic-memory/basic-memory.log (10MB rotation, 10 days retention).

Environment variables
VariableDefaultDescription
BASIC_MEMORY_LOG_LEVELINFODEBUG / INFO / WARNING / ERROR
BASIC_MEMORY_CLOUD_MODEfalseAPI logs to stdout with structured context
BASIC_MEMORY_FORCE_LOCALfalseForce local API routing
BASIC_MEMORY_FORCE_CLOUDfalseForce cloud API routing
BASIC_MEMORY_EXPLICIT_ROUTINGfalseMark route selection as explicit
BASIC_MEMORY_ENVdevSet to test for test mode (stderr only)
BASIC_MEMORY_NO_PROMOSfalseDisable cloud promos and telemetry
BASIC_MEMORY_IMPORT_UPLOAD_MAX_BYTES104857600Max uploaded import size
BASIC_MEMORY_LOG_LEVEL=DEBUG basic-memory reindex
tail -f ~/.basic-memory/basic-memory.log

Development

Basic Memory supports SQLite (default, fast, no Docker) and Postgres (via testcontainers — Docker required).

just install          # Install with dev dependencies
just test-sqlite      # All tests, SQLite
just test-postgres    # All tests, Postgres (testcontainers)
just test             # Both backends
just fast-check       # fix/format/typecheck + impacted tests
just doctor           # File <-> DB consistency check (temp config)
just package-check    # Claude Code, skills, Hermes, OpenClaw package checks
just lint
just typecheck        # Pyright (primary)
just typecheck-ty     # ty (supplemental)
just format
just check            # All quality checks
just migration "msg"  # New Alembic migration

Tests use pytest markers: windows, benchmark, smoke. See justfile for the full list.

Contributions welcome — see CONTRIBUTING.md.

License

AGPL-3.0.

Built with ♥️ by Basic Machines

docs/cloud-cli.md

Basic Memory Cloud CLI Guide

The Basic Memory Cloud CLI provides seamless integration between local and cloud knowledge bases using project-scoped synchronization. Each project can optionally sync with the cloud, giving you fine-grained control over what syncs and where.

Overview

The cloud CLI enables you to:

  • Authenticate cloud access - OAuth/API key credentials are stored locally for cloud operations

  • Project-scoped sync - Each project independently manages its sync configuration

  • Explicit operations - Sync only what you want, when you want

  • Push/pull transfers - Additive, git-style transfers that work on Personal and Team workspaces

  • Offline access - Work locally, sync when ready

Personal vs Team workspaces

bm cloud pull and bm cloud push are the standard way to move files between a local project and the cloud. They work the same way on Personal and Team workspaces:

CommandDirectionBehaviorPersonalTeam
bm cloud pullcloud → localadditive — never deletes local✅✅
bm cloud pushlocal → cloudadditive — never deletes cloud✅✅

push and pull never delete on the destination, so they are safe on a shared Team bucket. On Personal workspaces they run over rclone; on Team workspaces they run over WebDAV, where the service applies per-project access. You run the same commands either way.

The rclone mirror commands (bm cloud sync, bm cloud bisync, bm cloud bisync-reset) were removed in 1.0. See Removed in 1.0: sync and bisync.

Prerequisites

Before using Basic Memory Cloud, you need:

  • Active Subscription: An active Basic Memory Cloud subscription is required to access cloud features

  • Subscribe: Visit https://basicmemory.com/pricing to sign up

  • Optional: Cloud is optional. Local-first open-source usage continues without cloud.

  • OSS Discount: Use code {{OSS_DISCOUNT_CODE}} for 20% off for 3 months.

If you attempt to log in without an active subscription, you'll receive a "Subscription Required" error with a link to subscribe.

Architecture: Project-Scoped Sync

The Problem

Old approach (SPEC-8): All projects lived in a single ~/basic-memory-cloud-sync/ directory. This caused:

  • ❌ Directory conflicts between mount and sync

  • ❌ Auto-discovery creating phantom projects

  • ❌ Confusion about what syncs and when

  • ❌ All-or-nothing sync (couldn't sync just one project)

New approach (SPEC-20): Each project independently configures sync.

How It Works

Projects can exist in three states:

  1. Cloud-only - Project exists on cloud, no local copy

  2. Cloud + Local (synced) - Project has a local working directory that syncs

  3. Local-only - Project exists locally and is not routed to cloud

Example:

# You have 3 projects on cloud:
# - research: wants local sync at ~/Documents/research
# - work: wants local sync at ~/work-notes
# - temp: cloud-only, no local sync needed

bm project add research --cloud --local-path ~/Documents/research
bm project add work --cloud --local-path ~/work-notes
bm project add temp --cloud  # No local sync

# Now you can sync individually:
bm cloud pull --name research
bm cloud push --name research
bm cloud pull --name work
# temp stays cloud-only

What happens under the covers:

  • Config stores each project's local sync path (local_sync_path)

  • push/pull compare the local directory with the project's cloud copy and transfer only new or changed files

  • Personal workspaces transfer through the rclone remote basic-memory-cloud; Team workspaces transfer over WebDAV

  • Projects can live anywhere on your filesystem, not forced into a sync directory

Quick Start

1. Authenticate Cloud Access

Authenticate with cloud:

bm cloud login

What this does:

  1. Opens browser to Basic Memory Cloud authentication page

  2. Stores authentication tokens in ~/.basic-memory/basic-memory-cloud.json

  3. Validates your subscription status

  4. Leaves routing behavior unchanged (auth only)

Result: Cloud credentials are available for cloud-routed commands. Apply OSS discount code {{OSS_DISCOUNT_CODE}} during checkout to receive 20% off for 3 months.

2. Set Up Sync (Personal workspaces)

Personal workspaces transfer over rclone, so install it and configure credentials once. Team workspaces transfer over WebDAV and need neither rclone nor storage credentials: Team members skip this step.

bm cloud setup

What this does:

  1. Installs rclone with a supported package manager (if needed)

  2. Fetches your tenant information from cloud

  3. Generates scoped S3 credentials for sync

  4. Configures single rclone remote: basic-memory-cloud

Result: You're ready to sync projects. No sync directories created yet - those come with project setup.

Rclone setup uses package managers such as Homebrew, MacPorts, apt, dnf, yum, pacman, zypper, snap, winget, Chocolatey, or Scoop when available. It does not run remote install scripts with sudo; if no supported package manager is found, the CLI prints manual install instructions.

3. Add Projects with Sync

Create projects with optional local sync paths:

# Create cloud project without local sync
bm project add research --cloud

# Create cloud project WITH local sync
bm project add research --cloud --local-path ~/Documents/research

# Or configure sync for existing project
bm cloud sync-setup research ~/Documents/research

What happens under the covers:

When you add a project with --local-path:

  1. Project created on cloud at /app/data/research

  2. Local path stored in config for that project (local_sync_path)

  3. Local directory created if it doesn't exist

Result: Project is ready to sync, but no files synced yet.

4. Pull Cloud Files

Fetch the project's cloud files into your local directory. Preview with --dry-run first:

# Preview what would be downloaded
bm cloud pull --name research --dry-run

# Download new and changed cloud files
bm cloud pull --name research

What happens:

  1. Compares cloud and local

  2. Downloads files that are new or changed on the cloud

  3. Leaves local-only files untouched (never deletes local)

  4. If a file differs on both sides, aborts and lists the conflicts

Result: Your local directory has the cloud files. There is no baseline to set up and no --resync step.

5. Push Local Changes

After editing locally, upload your changes:

bm cloud push --name research --dry-run
bm cloud push --name research

What happens:

  1. Compares local and cloud

  2. Uploads files that are new or changed locally

  3. Leaves cloud-only files untouched (never deletes cloud)

  4. If a file differs on both sides, aborts and lists the conflicts — pull first, like a rejected git push

Result: The cloud has your local changes. Day to day, run pull before you start and push when you are done.

6. Verify Setup

Check status:

bm cloud status

You should see:

  • OAuth: token valid (or missing/expired)

  • API Key: configured (or not set)

  • Cloud instance is healthy

  • Instructions for project sync commands

Working with Projects

Understanding Project Commands

Key concept: Use regular bm project commands (not bm cloud project).

# Local route
bm project list --local
bm project add research ~/Documents/research

# Cloud route
bm project list --cloud
bm project add research --cloud
Creating Projects

Use case 1: Cloud-only project (no local sync)

bm project add temp-notes --cloud

What this does:

  • Creates project on cloud at /app/data/temp-notes

  • No local directory created

  • No sync configuration

Result: Project exists on cloud, accessible via MCP tools, but no local copy.

Use case 2: Cloud project with local sync

bm project add research --cloud --local-path ~/Documents/research

What this does:

  • Creates project on cloud at /app/data/research

  • Creates local directory ~/Documents/research

  • Stores sync config in ~/.basic-memory/config.json

  • Does not transfer any files yet

Result: Project ready to sync. Run bm cloud pull --name research to fetch cloud files, and bm cloud push --name research to upload local changes.

Use case 3: Add sync to existing cloud project

# Project already exists on cloud
bm cloud sync-setup research ~/Documents/research

What this does:

  • Updates existing project's sync configuration

  • Creates local directory

  • Does not transfer any files yet

Result: Existing cloud project now has a local sync path. Run bm cloud pull --name research to download its files.

Listing Projects

View all projects:

bm project list

What you see:

  • Local projects always

  • Cloud projects when credentials are available

  • Default project marked

  • Route-related metadata (for example, local/cloud presence and sync info)

Example shape (single row for dual-presence projects):

Name   Path            Local Path           Cloud Path   CLI Default   MCP (stdio)
main   /basic-memory   ~/basic-memory       /basic-memory   local       local
specs  /specs          ~/dev/specs          /specs          cloud       local

Team workspace projects can have a local sync path just like Personal ones, so they are listed the same way.

When a Project Exists in Both Local and Cloud

Use routing flags to disambiguate command targets:

# Force local target for this command
bm project info main --local
bm project ls --name main --local

# Force cloud target for this command
bm project info main --cloud
bm project ls --name main --cloud

Default behavior for no-project, no-flag commands is local. For MCP stdio, routing is always local.

File Synchronization

push / pull (additive, git-style)

push and pull are the supported transfer commands on Personal and Team workspaces. They model git push / git pull:

  • bm cloud pull fetches changes from the cloud into your local directory.

  • bm cloud push uploads your local changes to the cloud.

Both are additive — they never delete on the destination. A conflict (a file that differs on both sides) is never resolved silently: by default the command aborts and lists the conflicting files, exactly like git refusing to clobber your changes. Neither command needs a baseline or a --resync step. Both respect .bmignore.

OptionPurpose
--name <project>Project to transfer (required)
--dry-runPreview the transfer without changing anything
--on-conflict <strategy>How to handle files that differ on both sides (default fail)
--workspace <workspace>Workspace slug, name, or tenant ID, when the project name exists in more than one workspace
--verboseShow detailed output
Pull: fetch cloud changes
# Preview first (recommended)
bm cloud pull --name research --dry-run

# Fetch new/changed cloud files into local
bm cloud pull --name research

What happens:

  1. Compares cloud and local

  2. Downloads files that are new or changed on the cloud

  3. Leaves your local-only files untouched (never deletes local)

  4. If any file differs on both sides, aborts and lists the conflicts (unless you pass --on-conflict)

Push: upload local changes
bm cloud push --name research --dry-run
bm cloud push --name research

What happens:

  1. Compares local and cloud

  2. Uploads files that are new or changed locally

  3. Leaves cloud-only files untouched (never deletes cloud)

  4. If any file differs on both sides, aborts and lists the conflicts — pull first, like a rejected git push

Resolving conflicts

When push/pull reports conflicts, re-run with --on-conflict to choose how differing files are handled. The value names exactly what survives, so it reads the same in both directions:

--on-conflictBehavior
fail (default)List the conflicting files and exit without transferring anything
keep-cloudTake the cloud version (pull: overwrite local; push: skip those files)
keep-localKeep the local version (pull: skip those files; push: overwrite cloud)
keep-bothKeep both — write the incoming version beside the existing one as name.conflict-<date>.md
# A teammate edited notes you also changed locally — pull reports a conflict:
bm cloud pull --name research
# pull aborted: 1 file(s) differ between local and cloud.
#   * notes/decisions.md
# Re-run with one of: --on-conflict keep-cloud | keep-local | keep-both

# Take the cloud copy:
bm cloud pull --name research --on-conflict keep-cloud

# Or keep both versions to merge by hand:
bm cloud pull --name research --on-conflict keep-both
Ambiguous project names

If you belong to more than one workspace and the same project name exists in several of them, pass --workspace to pick one:

bm cloud pull --name research --workspace acme
Limitations

push/pull are deliberately simple, conflict-aware byte transfers — not a full reconciler. Without a sync baseline:

  • Deletions are not propagated. A note deleted on one side is not removed from the other (we cannot tell an intentional delete from a file the other side never had). This is surfaced in the command output. A later transfer in the other direction can copy the deleted file back.

  • Renames are not propagated as moves. The file at its new path transfers, and the old path remains on the destination until you remove it.

  • Every divergence is treated as a conflict. We cannot tell a teammate's edit from your stale copy, so any differing file prompts a decision rather than auto-resolving. There is no automatic three-way merge.

For conflict-aware editing, write through the MCP/API tools (which merge at the note level). A bidirectional reconciler with a real baseline is tracked in issue #862.

Advanced: List Project Files by Route

Use case: Inspect local or cloud project files explicitly.

# List local project files (default target when no route flag is given)
bm project ls --name research
bm project ls --name research --local

# List cloud project files
bm project ls --name research --cloud

# List files in subdirectory
bm project ls --name research --cloud --path subfolder

What happens:

  1. Resolves route from flags (or local default when no route is given)

  2. Lists files for the chosen project instance

  3. No files transferred

Result: See file listing for the target route.

Multiple Projects

Syncing Multiple Projects

Use case: You have several projects with local sync and want to sync them all.

# Setup multiple projects
bm project add research --cloud --local-path ~/Documents/research
bm project add work --cloud --local-path ~/work-notes
bm project add personal --cloud --local-path ~/personal

# Fetch cloud changes for each
bm cloud pull --name research
bm cloud pull --name work
bm cloud pull --name personal

# Upload local changes for each
bm cloud push --name research
bm cloud push --name work
bm cloud push --name personal

Each command acts on one project. Run them per project.

Mixed Usage

Use case: Some projects sync, some stay cloud-only.

# Projects with sync
bm project add research --cloud --local-path ~/Documents/research
bm project add work --cloud --local-path ~/work

# Cloud-only projects
bm project add archive --cloud
bm project add temp-notes --cloud

# Sync only the configured ones
bm cloud pull --name research
bm cloud push --name research
bm cloud pull --name work
bm cloud push --name work

# Archive and temp-notes stay cloud-only

Result: Fine-grained control over what syncs.

Per-Project Cloud Routing (API Key)

Route individual projects through cloud using an API key. This lets you keep some projects local while others route through cloud.

Setting Up API Key Auth

Option A: Create a key in the web app, then save it locally:

bm cloud api-key save   # prompts for the key without echoing it

Option B: Create a key via CLI (requires OAuth login first):

bm cloud login                         # One-time OAuth login
bm cloud api-key create "my-laptop"    # Creates key and saves it locally

The API key is account-level — it grants access to all your cloud projects. It's stored in ~/.basic-memory/config.json as cloud_api_key. On POSIX systems, Basic Memory writes ~/.basic-memory/ as user-private (0700) and config.json as user-read/write only (0600). Treat this config file as a credential file when an API key is saved.

Setting Project Modes
# Route a project through cloud
bm project set-cloud research

# Revert to local mode
bm project set-local research

# View project modes
bm project list

What happens:

  • set-cloud: validates the API key exists, then sets the project mode to cloud in config

  • set-local: reverts the project to local mode (removes the mode entry from config)

  • MCP tools and CLI commands for that project will route to cloud_host/proxy with the API key as Bearer token

How It Works

When an MCP tool or CLI command runs for a cloud-mode project:

  1. get_client(project_name="research") checks the project's mode in config

  2. If mode is cloud, creates an HTTP client pointed at cloud_host/proxy with Authorization: Bearer bmc_...

  3. If mode is local (default), uses the in-process ASGI transport as usual

Routing priority (highest to lowest):

  1. Factory injection (cloud app, tests)

  2. Explicit route override (--local / --cloud)

  3. Per-project cloud mode (API key)

  4. Local ASGI transport (default)

Route override environment variables:

  • BASIC_MEMORY_FORCE_LOCAL=true

  • BASIC_MEMORY_FORCE_CLOUD=true

  • BASIC_MEMORY_EXPLICIT_ROUTING=true

No-project, no-flag CLI commands default to local routing.

Configuration Example
{
  "projects": {
    "personal": "/Users/me/notes",
    "research": "/Users/me/research"
  },
  "project_modes": {
    "research": "cloud"
  },
  "cloud_api_key": "bmc_abc123...",
  "cloud_host": "https://cloud.basicmemory.com",
  "default_project": "personal"
}

In this example, personal stays local and research routes through cloud. Projects not listed in project_modes default to local.

Sync Behavior

Cloud-mode projects are automatically skipped during local file sync (background sync and file watching). Their files live on the cloud instance, not locally.

OAuth Logout

bm cloud logout

What this does:

  1. Removes stored OAuth token(s)

  2. Does not change per-project route configuration

  3. Does not change command routing defaults

Result: OAuth session is cleared. API-key-based routing still works if cloud_api_key is configured.

Filter Configuration

Understanding .bmignore

The problem: You don't want to sync everything (e.g., .git, node_modules, database files).

The solution: .bmignore file with gitignore-style patterns.

Location: ~/.basic-memory/.bmignore

Default patterns:

# Hidden files and directories
.*

# Basic Memory internals
*.db
*.db-shm
*.db-wal
config.json

# Version control
.git
.svn

# Python
__pycache__
*.pyc
*.pyo
*.pyd
.pytest_cache
.coverage
*.egg-info
.tox
.mypy_cache
.ruff_cache

# Virtual environments
.venv
venv
env
.env

# Node.js
node_modules

# Build artifacts
build
dist
.cache

# IDE
.idea
.vscode

# OS files
.DS_Store
Thumbs.db
desktop.ini

# Obsidian
.obsidian

# Temporary files
*.tmp
*.swp
*.swo
*~

How it works:

  1. On first sync, .bmignore created with defaults

  2. Patterns converted to rclone filter format (.bmignore.rclone)

  3. push/pull skip matching paths on both sides (rclone filters on Personal, the same patterns over WebDAV on Team)

  4. Same patterns used by all projects

During conversion, file patterns exclude the direct match and recursive contents. For example, config.json becomes both - config.json and - config.json/**, while .* becomes both - .* and - .*/**. Directory-only patterns keep their trailing slash, so cache/ becomes - cache/ and - cache/**.

Customizing:

# Edit patterns
code ~/.basic-memory/.bmignore

# Add custom patterns
echo "*.tmp" >> ~/.basic-memory/.bmignore

# Next transfer uses updated patterns
bm cloud push --name research

Troubleshooting

Rclone Setup Cannot Install Automatically

Problem: bm cloud setup cannot find a supported package manager, or package-manager installation fails.

Explanation: The CLI avoids remote privileged install scripts. It only invokes known package managers and otherwise asks you to install rclone manually.

Solution: Install rclone with your OS package manager, then rerun setup:

# macOS
brew install rclone

# Debian/Ubuntu
sudo apt install rclone

# Fedora
sudo dnf install rclone

# Arch
sudo pacman -S rclone

# After rclone is on PATH
bm cloud setup
Authentication Issues

Problem: "Authentication failed" or "Invalid token"

Solution: Re-authenticate:

bm cloud logout
bm cloud login
Subscription Issues

Problem: "Subscription Required" error

Solution:

  1. Visit subscribe URL shown in error

  2. Sign up for subscription

  3. Run bm cloud login again

Note: Access is immediate when subscription becomes active.

Push or Pull Reports Conflicts

Problem: push or pull aborts with "file(s) differ between local and cloud"

Explanation: The listed files changed on both sides. The default --on-conflict fail stops before transferring anything so nothing is overwritten silently.

Solution: Re-run with the strategy you want:

bm cloud pull --name research --on-conflict keep-cloud   # take the cloud copy
bm cloud pull --name research --on-conflict keep-local   # keep your local copy
bm cloud pull --name research --on-conflict keep-both    # keep both, merge by hand

See Resolving conflicts.

Deleted Files Come Back

Problem: A note you deleted locally is still on the cloud (or reappears after pull).

Explanation: push and pull never delete on the destination, so deletions are not propagated.

Solution: Delete the note on the other side as well, for example through the web app or the MCP bm_delete tool.

Project Name Is Ambiguous

Problem: push or pull reports that the project "does not have an unambiguous cloud workspace" (the same project name exists in more than one workspace).

Solution: Name the workspace:

bm cloud pull --name research --workspace acme
Project Not Configured for Sync

Problem: "Project research has no local_sync_path configured"

Explanation: Project exists on cloud but has no local sync path.

Solution:

bm cloud sync-setup research ~/Documents/research
bm cloud pull --name research
Connection Issues

Problem: "Cannot connect to cloud instance"

Solution: Check status:

bm cloud status

If instance is down, wait a few minutes and retry.

Removed in 1.0: sync and bisync

bm cloud sync, bm cloud bisync, and bm cloud bisync-reset were removed in 1.0 (#1845). sync made the cloud match your local folder and deleted cloud-only files, including notes created in the cloud by teammates and agents. Running any of the three now prints migration guidance and exits nonzero. It transfers, deletes, and provisions nothing.

Replace them with bm cloud pull and bm cloud push:

Old commandReplacement
bm cloud sync --name researchbm cloud push --name research (add --on-conflict keep-local for local precedence)
bm cloud bisync --name researchbm cloud pull --name research, then bm cloud push --name research
bm cloud bisync-reset researchNothing to reset: push and pull keep no sync state

How the replacements differ from mirroring:

  • Deletions are not propagated. Delete the cloud copy yourself if you deleted a file locally, and the reverse.

  • Renames are not propagated as moves. The old path remains on the destination until you remove it.

  • Any differing file is a conflict. The transfer stops before copying anything. Re-run with --on-conflict keep-local, keep-cloud, or keep-both.

  • push --on-conflict keep-local is not an exact mirror. Local content wins for differing files, but cloud-only files remain.

Old bisync state in ~/.basic-memory/bisync-state/ is no longer used. Basic Memory does not delete it; remove it yourself if you like. To clean up cloud files that match .bmignore, use bm cloud prune --name <project> --dry-run on Personal workspaces.

check (legacy): verify mirror integrity
bm cloud check --name research
bm cloud check --name research --one-way   # faster, one direction

Compares checksums between local and the default Personal workspace remote. No files are transferred. Use bm cloud pull --dry-run / bm cloud push --dry-run to preview differences instead.

Security

  • Authentication: OAuth 2.1 with PKCE flow

  • Tokens: Stored securely in ~/.basic-memory/basic-memory-cloud.json

  • API keys: Stored in ~/.basic-memory/config.json, which is written with private file permissions on POSIX systems

  • Transport: All data encrypted in transit (HTTPS)

  • Credentials: Scoped S3 credentials (read-write to your tenant only)

  • Rclone setup: Uses package managers or manual instructions; no remote privileged install-script fallback

  • Isolation: Your data isolated from other tenants

  • Ignore patterns: Sensitive files automatically excluded via .bmignore

Command Reference

Cloud Authentication
bm cloud login              # Authenticate and store OAuth credentials
bm cloud logout             # Remove stored OAuth credentials
bm cloud status             # Check auth state and instance health
bm cloud promo --off        # Disable CLI cloud promo notices
API Key Management
bm cloud api-key save [key]      # Save a cloud API key (bmc_ prefixed); prompts if omitted
bm cloud api-key create <name>   # Create API key via cloud API (requires OAuth login)
Setup
bm cloud setup              # Personal only: install rclone and configure credentials
Project Management
bm project list --local                   # Local project list
bm project list --cloud                   # Cloud project list
bm project add <name> --cloud             # Create cloud project (no sync)
bm project add <name> --cloud --local-path <path> # Create with local sync
bm cloud sync-setup <name> <path>       # Add sync to existing project
bm project rm <name>                      # Delete project
Per-Project Routing
bm project set-cloud <name>  # Route project through cloud (requires API key)
bm project set-local <name>  # Revert project to local mode
File Synchronization
# Pull: fetch cloud changes (cloud → local) - additive
bm cloud pull --name <project>
bm cloud pull --name <project> --dry-run
bm cloud pull --name <project> --on-conflict [fail|keep-local|keep-cloud|keep-both]
bm cloud pull --name <project> --workspace <workspace>

# Push: upload local changes (local → cloud) - additive
bm cloud push --name <project>
bm cloud push --name <project> --dry-run
bm cloud push --name <project> --on-conflict [fail|keep-local|keep-cloud|keep-both]
bm cloud push --name <project> --workspace <workspace>

# List project files by route
bm project ls --name <project>          # Default target: local
bm project ls --name <project> --local
bm project ls --name <project> --cloud
bm project ls --name <project> --cloud --path <subpath>
Legacy (Personal only)
bm cloud check --name <project>             # Legacy integrity check
bm cloud prune --name <project> [--dry-run] # Delete cloud files matching .bmignore

Summary

Basic Memory Cloud uses project-scoped sync:

  1. Authenticate cloud access - bm cloud login

  2. Install rclone (Personal workspaces only) - bm cloud setup

  3. Add projects with sync - bm project add research --cloud --local-path ~/Documents/research

  4. Fetch cloud changes - bm cloud pull --name research

  5. Upload your changes - bm cloud push --name research

  6. Resolve conflicts explicitly - re-run with --on-conflict keep-cloud|keep-local|keep-both

The same workflow applies to Personal and Team workspaces; Team workspaces skip step 2.

Key benefits:

  • ✅ Each project independently syncs (or doesn't)

  • ✅ Projects can live anywhere on disk

  • ✅ Explicit sync operations (no magic)

  • ✅ Push/pull never delete on the destination

  • ✅ Git-style conflict aborts instead of silent overwrites

  • ✅ Full offline access (work locally, sync when ready)

Future enhancements:

  • Project list showing sync status

  • Watch mode for automatic sync

512 files · 461 not served here

Advantages

  • Local-first architecture ensures data remains on your disk, providing air-gapped compatibility and full ownership. evidence: README.md
  • Bidirectional synchronization allows both humans and AI agents to edit the same files, keeping the knowledge base consistent. evidence: README.md
  • Progressive tool discovery via MCP behavior hints allows agents to select the most appropriate tool for a task without wasting context. evidence: README.md

Limitations

  • Local installation requires Python 3.12+ and familiarity with command-line tools. evidence: README.md
  • Cross-device synchronization for local-only setups requires manual configuration of tools like Git or Syncthing. evidence: README.md
  • Advanced features like cross-encoder reranking may introduce inference latency and require additional model downloads. evidence: README.md

Security

Risk level: Medium risk

This brain runs

Agent instructions that run or fetch something (322)

  • .agents/skills/adversarial-review/SKILL.md: To **run** it, use `"${DIFF[@]}"` (quoted, no word-splitting).
  • .agents/skills/adversarial-review/SKILL.md: Run `"${DIFF[@]}"`.
  • .agents/skills/adversarial-review/SKILL.md: `RUN=$(mktemp -d)` — scratch dir for the other model's output.
  • .agents/skills/adversarial-review/SKILL.md: **The other model's pass** — run, from the repo root, the row that matches you:
  • .agents/skills/adversarial-review/SKILL.md: # You are Claude → run Codex:
  • .agents/skills/adversarial-review/SKILL.md: -o "$RUN/other_findings.json" \
  • .agents/skills/adversarial-review/SKILL.md: # You are Codex → run Claude (read-only via plan mode; parse the JSON block it returns):
  • .agents/skills/adversarial-review/SKILL.md: $(cat "$SKILL_DIR/schemas/findings.schema.json")" </dev/null > "$RUN/other_raw.json"
  • .agents/skills/fix-pr-issues/SKILL.md: Run the smallest meaningful verification first, then widen as needed.
  • .agents/skills/fix-pr-issues/SKILL.md: Commit changed code or documentation with `git commit -s`.
  • .agents/skills/fix-pr-issues/SKILL.md: For each addressed comment or blocker, reply with the fix commit, verification run, and current Codex gate status.
  • .agents/skills/infographics/SKILL.md: uv run --script scripts/generate_pr_infographic.py \
  • .agents/skills/infographics/SKILL.md: uv run --script scripts/generate_pr_infographic.py \
  • .agents/skills/infographics/SKILL.md: `--dry-run` is an alias for `--print-prompt`;
  • .agents/skills/infographics/SKILL.md: changed-file orientation: `git diff --stat` plus key file reads
  • .agents/skills/infographics/SKILL.md: uv run --script scripts/generate_infographic.py \
  • .agents/skills/instrumentation/SKILL.md: The reason this skill exists is that Claude tends to get a few things subtly wrong with Logfire - especially the ordering of `configure()` vs `instrument_*()` calls, the structured logging syntax, and which extras to install.
  • .agents/skills/instrumentation/SKILL.md: Install `logfire` with extras matching the detected frameworks.
  • .agents/skills/instrumentation/SKILL.md: uv add 'logfire[pydantic-ai]'
  • .agents/skills/instrumentation/SKILL.md: For PydanticAI, each agent run becomes a parent span containing child spans for every tool call and LLM request.
  • .agents/skills/instrumentation/SKILL.md: Launch with: `node --require ./instrumentation.js app.js`
  • .agents/skills/instrumentation/SKILL.md: Run `logfire auth` to check authentication (or set `LOGFIRE_TOKEN`)
  • .agents/skills/pr-create/SKILL.md: Return the PR URL, current head SHA, validation run, check status, and Codex gate evidence.
  • .agents/skills/pr-description/SKILL.md: git log --oneline --decorate -n 10
  • .agents/skills/pr-description/SKILL.md: Testing section must include exact commands run and outcomes.
  • .agents/skills/pr-review-loop/SKILL.md: If the comment identifies a real issue, patch it, run focused validation, push, and restart the loop on the new head.
  • .agents/skills/pr-review-loop/SKILL.md: Only run `gh pr merge` when the gate is `approved` or `overridden` and tests are passing on that same head.
  • .agents/skills/pull-request/SKILL.md: After activation, run Python scripts as `python ...`.
  • .agents/skills/pull-request/SKILL.md: For one-off commands where activation is awkward, prefer `./.venv/bin/python ...` or the repo's `uv run ...` patterns.
  • .agents/skills/pull-request/SKILL.md: Run focused tests for the changed surface.
  • .agents/skills/pull-request/SKILL.md: Run the repo's required gate, such as `just fast-check` for source changes or `just package-check` for agent/package changes, before calling the branch ready.
  • .agents/skills/pull-request/SKILL.md: `Testing`: exact commands run and whether they passed.
  • .agents/skills/pull-request/SKILL.md: If the feedback is correct and in scope, patch, run focused validation, push, and restart the loop on the new head.
  • .agents/skills/pythonic-code/SKILL.md: Run the narrowest command that proves the change, then widen according to risk:
  • .agents/skills/pythonic-code/evals/context/AGENTS.md: Run the focused tests under `evals/files` and the configured Ruff checks for changed Python.
  • .claude/commands/release/beta.md: When the user runs `/beta`, execute the following steps:
  • .claude/commands/release/beta.md: While `pyproject.toml` pins a FastMCP pre-release (`fastmcp==X.Y.Zb1`), `just beta` refuses to run: every documented install passes `--prerelease=allow`, which uv applies to basic-memory itself, so a beta on PyPI would become the default install for stable users (#1338).
  • .claude/commands/release/beta.md: Execute the automated beta release process:
  • .claude/commands/release/beta.md: Test beta installation: `uv tool install basic-memory --pre`
  • .claude/commands/release/beta.md: # Install/upgrade to beta
  • .claude/commands/release/beta.md: uv tool install basic-memory --pre
  • .claude/commands/release/beta.md: uv tool upgrade basic-memory --prerelease=allow
  • .claude/commands/release/beta.md: Install/test with:
  • .claude/commands/release/beta.md: uv tool install basic-memory --pre
  • .claude/commands/release/beta.md: **Test features**: Install and validate new functionality
  • .claude/commands/release/changelog.md: When the user runs `/changelog`, execute the following steps:
  • .claude/commands/release/changelog.md: git tag -l "v*" --sort=-version:refname | grep -v "b\|rc" | head -1
  • .claude/commands/release/changelog.md: git log --oneline ${last_tag}..HEAD
  • .claude/commands/release/changelog.md: uv tool install basic-memory --prerelease=allow
  • .claude/commands/release/release-check.md: When the user runs `/release-check`, execute the following validation steps:
  • .claude/commands/release/release-check.md: 2. Run `/release v0.13.0` when ready
  • .claude/commands/release/release-check.md: Can be run multiple times safely
  • .claude/commands/release/release.md: When the user runs `/release`, execute the following steps:
  • .claude/commands/release/release.md: Execute the automated release process:
  • .claude/commands/release/release.md: ✅ Builds the package using `uv build`
  • .claude/commands/release/release.md: Test installation: `uv tool install basic-memory --prerelease=allow`
  • .claude/commands/release/release.md: Test Homebrew installation: `brew install basicmachines-co/basic-memory/basic-memory`
  • .claude/commands/release/release.md: gh workflow run mcp-registry-publish.yml
  • .claude/commands/release/release.md: curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=basic-memory" · uses the network
  • .claude/commands/release/release.md: Pull latest from GitHub: `git pull origin main` · uses the network
  • .claude/commands/release/release.md: Create release branch: `git checkout -b release/v{VERSION}`
  • .claude/commands/release/release.md: Commit (`git commit -s -m "..."`), push, and open a PR against `basicmachines-co/basicmemory.com`
  • .claude/commands/release/release.md: Pull latest from GitHub: `git pull origin main` · uses the network
  • .claude/commands/release/release.md: Create release branch: `git checkout -b release/v{VERSION}`
  • .claude/commands/release/release.md: Commit: `git commit -s -m "docs: add v{VERSION} release notes"`
  • .claude/commands/release/release.md: Install with pip/uv:
  • .claude/commands/release/release.md: uv tool install basic-memory --prerelease=allow
  • .claude/commands/release/release.md: Install with Homebrew:
  • .claude/commands/release/release.md: brew install basicmachines-co/basic-memory/basic-memory
  • .claude/commands/release/release.md: uv tool upgrade basic-memory --prerelease=allow
  • .claude/commands/release/release.md: To bump only the plugin/agent artifacts out of band, use `just set-packages-version <version>` (preview with `just set-packages-version-dry-run <version>`).
  • .claude/commands/spec.md: Execute the spec command: `/spec $ARGUMENTS`
  • .claude/commands/test-live.md: Execute comprehensive real-world testing of Basic Memory using the installed version.
  • .claude/commands/test-live.md: `phase` (optional): Specific test phase to run (`recent`, `core`, `features`, `edge`, `workflows`, `stress`, or `all`)
  • .claude/commands/test-live.md: When the user runs `/project:test-live`, execute comprehensive test plan:
  • .claude/commands/test-live.md: Run `git log --oneline -20` to examine recent commits
  • .claude/commands/test-live.md: Run the bash `date` command to get the current date/time.
  • .claude/commands/test-live.md: Execute test scenarios systematically
  • AGENTS.md: Install: `just install` or `pip install -e ".[dev]"`
  • AGENTS.md: Run all tests (SQLite + Postgres): `just test`
  • AGENTS.md: Run all tests against SQLite: `just test-sqlite`
  • AGENTS.md: Run all tests against Postgres: `just test-postgres` (uses testcontainers)
  • AGENTS.md: Run unit tests (SQLite): `just test-unit-sqlite`
  • AGENTS.md: Run unit tests (Postgres): `just test-unit-postgres`
  • AGENTS.md: Run integration tests (SQLite): `just test-int-sqlite`
  • AGENTS.md: Run integration tests (Postgres): `just test-int-postgres`
  • AGENTS.md: Run impacted tests: `just fast-test` or `just testmon` (pytest-testmon;
  • AGENTS.md: Run MCP smoke test: `just test-smoke`
  • AGENTS.md: Run all consolidated agent package checks: `just package-check`
  • AGENTS.md: Run Claude Code plugin checks: `just package-check-claude-code`
  • AGENTS.md: Run shared skills checks: `just package-check-skills`
  • AGENTS.md: Run Hermes plugin checks: `just package-check-hermes`
  • AGENTS.md: Run OpenClaw plugin checks: `just package-check-openclaw`
  • AGENTS.md: Run host-native agent harness checks: `just agent-harness-check`
  • AGENTS.md: Run benchmarks: `pytest test-int/test_sync_performance_benchmark.py -v -m "benchmark and not slow"`
  • AGENTS.md: Type check: `just typecheck` or `uv run ty check src tests test-int`
  • AGENTS.md: Type check (pyright): `just typecheck-pyright` or `uv run pyright`
  • AGENTS.md: Format: `just format` or `uv run ruff format .`
  • AGENTS.md: Run all static code checks: `just check` (runs lint, format, typecheck)
  • AGENTS.md: Run development MCP Inspector: `just run-inspector`
  • AGENTS.md: **Test:** `just fast-test` for pytest-testmon impacted tests, or a targeted `uv run pytest ...` command.
  • AGENTS.md: Run `just test-smoke` when you specifically need the MCP smoke flow.
  • AGENTS.md: If testmon is “cold,” the first run may be long.
  • AGENTS.md: `just package-check-openclaw` — runs the OpenClaw package install, copies top-level skills into the generated bundle, typechecks, lints, builds `dist/`, runs Bun tests, and performs `npm pack --dry-run`.
  • AGENTS.md: Before opening or updating a PR, run the checks that mirror the common required CI failures:
  • AGENTS.md: Run `just typecheck` in addition to targeted `ruff` and `pytest` commands when tests were added or changed.
  • AGENTS.md: Sign commits with `git commit -s` so DCO passes.
  • AGENTS.md: Add or update meaningful regression tests for bugs and risky behavior, prefer real code paths over mocks, and run the narrowest command that proves the change before widening verification.
  • AGENTS.md: connection.execute("PRAGMA journal_mode=WAL")
  • AGENTS.md: By default, tests run against SQLite (fast, no Docker needed)
  • AGENTS.md: Set `BASIC_MEMORY_TEST_POSTGRES=1` to run against Postgres (uses testcontainers - Docker required)
  • AGENTS.md: The recipes bump version metadata, run pre-flight checks, land the bump on `main` through a release PR, tag, and push the tag.
  • AGENTS.md: PyPI consumers install with `pip install basic-memory --pre`.
  • AGENTS.md: The recipe refuses a beta whenever `pyproject.toml` pins a FastMCP pre-release (`fastmcp==X.Y.ZbN`): installs then need `--prerelease=allow`, which uv also applies to basic-memory itself, so a beta on PyPI would become the default install for stable users.
  • AGENTS.md: **Release dry run:** `just release-dry-run v0.21.4` previews the consolidated version update without writing files.
  • AGENTS.md: **Development builds are not published to PyPI.** Documented installs pass `--prerelease=allow` (published releases through v0.23.2 pin a FastMCP pre-release), and uv applies that flag to basic-memory itself, so a `.devN` build on PyPI would outrank the stable release for every fresh install.
  • AGENTS.md: To try unreleased `main`, install from git: `uv tool install "basic-memory @ git+https://github.com/basicmachines-co/basic-memory" --prerelease=allow`.
  • AGENTS.md: **Post-release tasks** the recipe surfaces but doesn't run:
  • AGENTS.md: MCP Registry — after the version is live on PyPI, dispatch `.github/workflows/mcp-registry-publish.yml` (`gh workflow run mcp-registry-publish.yml`);
  • CLAUDE.md: Install: `just install` or `pip install -e ".[dev]"`
  • CLAUDE.md: Run all tests (SQLite + Postgres): `just test`
  • CLAUDE.md: Run all tests against SQLite: `just test-sqlite`
  • CLAUDE.md: Run all tests against Postgres: `just test-postgres` (uses testcontainers)
  • CLAUDE.md: Run unit tests (SQLite): `just test-unit-sqlite`
  • CLAUDE.md: Run unit tests (Postgres): `just test-unit-postgres`
  • CLAUDE.md: Run integration tests (SQLite): `just test-int-sqlite`
  • CLAUDE.md: Run integration tests (Postgres): `just test-int-postgres`
  • CLAUDE.md: Run impacted tests: `just fast-test` or `just testmon` (pytest-testmon;
  • CLAUDE.md: Run MCP smoke test: `just test-smoke`
  • CLAUDE.md: Run all consolidated agent package checks: `just package-check`
  • CLAUDE.md: Run Claude Code plugin checks: `just package-check-claude-code`
  • CLAUDE.md: Run shared skills checks: `just package-check-skills`
  • CLAUDE.md: Run Hermes plugin checks: `just package-check-hermes`
  • CLAUDE.md: Run OpenClaw plugin checks: `just package-check-openclaw`
  • CLAUDE.md: Run host-native agent harness checks: `just agent-harness-check`
  • CLAUDE.md: Run benchmarks: `pytest test-int/test_sync_performance_benchmark.py -v -m "benchmark and not slow"`
  • CLAUDE.md: Type check: `just typecheck` or `uv run ty check src tests test-int`
  • CLAUDE.md: Type check (pyright): `just typecheck-pyright` or `uv run pyright`
  • CLAUDE.md: Format: `just format` or `uv run ruff format .`
  • CLAUDE.md: Run all static code checks: `just check` (runs lint, format, typecheck)
  • CLAUDE.md: Run development MCP Inspector: `just run-inspector`
  • CLAUDE.md: **Test:** `just fast-test` for pytest-testmon impacted tests, or a targeted `uv run pytest ...` command.
  • CLAUDE.md: Run `just test-smoke` when you specifically need the MCP smoke flow.
  • CLAUDE.md: If testmon is “cold,” the first run may be long.
  • CLAUDE.md: `just package-check-openclaw` — runs the OpenClaw package install, copies top-level skills into the generated bundle, typechecks, lints, builds `dist/`, runs Bun tests, and performs `npm pack --dry-run`.
  • CLAUDE.md: Before opening or updating a PR, run the checks that mirror the common required CI failures:
  • CLAUDE.md: Run `just typecheck` in addition to targeted `ruff` and `pytest` commands when tests were added or changed.
  • CLAUDE.md: Sign commits with `git commit -s` so DCO passes.
  • CLAUDE.md: Add or update meaningful regression tests for bugs and risky behavior, prefer real code paths over mocks, and run the narrowest command that proves the change before widening verification.
  • CLAUDE.md: connection.execute("PRAGMA journal_mode=WAL")
  • CLAUDE.md: By default, tests run against SQLite (fast, no Docker needed)
  • CLAUDE.md: Set `BASIC_MEMORY_TEST_POSTGRES=1` to run against Postgres (uses testcontainers - Docker required)
  • CLAUDE.md: The recipes bump version metadata, run pre-flight checks, land the bump on `main` through a release PR, tag, and push the tag.
  • CLAUDE.md: PyPI consumers install with `pip install basic-memory --pre`.
  • CLAUDE.md: The recipe refuses a beta whenever `pyproject.toml` pins a FastMCP pre-release (`fastmcp==X.Y.ZbN`): installs then need `--prerelease=allow`, which uv also applies to basic-memory itself, so a beta on PyPI would become the default install for stable users.
  • CLAUDE.md: **Release dry run:** `just release-dry-run v0.21.4` previews the consolidated version update without writing files.
  • CLAUDE.md: **Development builds are not published to PyPI.** Documented installs pass `--prerelease=allow` (published releases through v0.23.2 pin a FastMCP pre-release), and uv applies that flag to basic-memory itself, so a `.devN` build on PyPI would outrank the stable release for every fresh install.
  • CLAUDE.md: To try unreleased `main`, install from git: `uv tool install "basic-memory @ git+https://github.com/basicmachines-co/basic-memory" --prerelease=allow`.
  • CLAUDE.md: **Post-release tasks** the recipe surfaces but doesn't run:
  • CLAUDE.md: MCP Registry — after the version is live on PyPI, dispatch `.github/workflows/mcp-registry-publish.yml` (`gh workflow run mcp-registry-publish.yml`);
  • benchmarks/AGENTS.md: Install: `uv sync --group dev`
  • benchmarks/AGENTS.md: Run tests: `uv run pytest -q`
  • benchmarks/AGENTS.md: Lint: `uv run ruff check .`
  • benchmarks/AGENTS.md: Type check: `uv run pyright`
  • benchmarks/AGENTS.md: `uv run pytest -q`
  • benchmarks/AGENTS.md: `uv run ruff check .`
  • benchmarks/AGENTS.md: `uv run pyright`
  • benchmarks/AGENTS.md: CLI entrypoint: `uv run bm-bench ...`
  • benchmarks/AGENTS.md: `uv run bm-bench datasets fetch --dataset locomo`
  • benchmarks/AGENTS.md: `uv run bm-bench convert locomo --dataset-path benchmarks/datasets/locomo/locomo10.json --output-dir benchmarks/generated/locomo`
  • benchmarks/AGENTS.md: `bash benchmarks/datasets/beam/download.sh` (BEAM data is never vendored;
  • benchmarks/AGENTS.md: `uv run bm-bench convert beam --tier 100K --output-dir benchmarks/generated/beam-100k`
  • benchmarks/AGENTS.md: Run retrieval:
  • benchmarks/AGENTS.md: `uv run bm-bench run retrieval --providers bm-local,mem0-local --dataset-id locomo --dataset-path benchmarks/datasets/locomo/locomo10.json --corpus-dir benchmarks/generated/locomo/docs --queries-path benchmarks/generated/locomo/queries.json --output-root benchmarks/runs --allow-provider-skip`
  • benchmarks/AGENTS.md: Run end-to-end QA scoring:
  • benchmarks/AGENTS.md: `uv run bm-bench run qa --run-dir benchmarks/runs/<run-id> --answerer claude:claude-haiku-4-5 --judge claude:claude-sonnet-4-6`
  • benchmarks/AGENTS.md: BEAM nugget scoring (post-hoc, after `run qa` on a BEAM run):
  • benchmarks/AGENTS.md: `uv run bm-bench run beam-score --run-dir benchmarks/runs/<run-id> --judge claude:claude-sonnet-4-6`
  • benchmarks/AGENTS.md: `uv run bm-bench run agent-tasks --surfaces bm --model openai-compat:<model>@<base_url> --bm-local-path <bm-checkout>`
  • benchmarks/AGENTS.md: `uv run bm-bench validate-artifacts --run-dir benchmarks/runs/<run-id>`
  • benchmarks/AGENTS.md: `uv run bm-bench publish --run-dir benchmarks/runs/<run-id> --destination benchmarks/results/public`
  • benchmarks/AGENTS.md: `just bench-run-beam-100k`
  • benchmarks/AGENTS.md: `just bench-beam-score benchmarks/runs/<run-id>`
  • benchmarks/AGENTS.md: `just bench-run-bm-local`
  • benchmarks/AGENTS.md: `just bench-run-mem0-local`
  • benchmarks/AGENTS.md: `just bench-run-full`
  • benchmarks/AGENTS.md: `just bench-qa benchmarks/runs/<run-id>`
  • benchmarks/AGENTS.md: `just bench-publish benchmarks/runs/<run-id>`
  • benchmarks/AGENTS.md: `src/basic_memory_benchmarks/runner.py` - run orchestration
  • benchmarks/AGENTS.md: `benchmarks/runs/` - raw run artifacts
  • benchmarks/AGENTS.md: The benchmark command is typically invoked through `uv run ...` so `.venv/bin/bm` is used.
  • benchmarks/AGENTS.md: Ingest and search use a stable benchmark `user_id` namespace per run.
  • benchmarks/AGENTS.md: Prefer setting only required credentials for run reproducibility.
  • benchmarks/AGENTS.md: Always publish conversion code and run artifacts.
  • benchmarks/AGENTS.md: Sign commits: `git commit -s`.
  • integrations/hermes/skill/SKILL.md: **Search before answering.** If the user asks "what did we decide about X?", run `bm_search` first.
  • integrations/openclaw/AGENTS.md: **Build output** — `bun run build` emits `dist/` for `runtimeExtensions`;
  • integrations/openclaw/AGENTS.md: `scripts/bm-local.sh` runs BM from the monorepo root via `uv run --project ...` when available, then falls back to `bm` on PATH
  • integrations/openclaw/AGENTS.md: **Package CI** (root `.github/workflows/consolidated-packages.yml`): validates skills, typechecks, lints, builds, tests, and runs `npm pack --dry-run`.
  • integrations/openclaw/CLAUDE.md: **Build output** — `bun run build` emits `dist/` for `runtimeExtensions`;
  • integrations/openclaw/CLAUDE.md: `scripts/bm-local.sh` runs BM from the monorepo root via `uv run --project ...` when available, then falls back to `bm` on PATH
  • integrations/openclaw/CLAUDE.md: **Package CI** (root `.github/workflows/consolidated-packages.yml`): validates skills, typechecks, lints, builds, tests, and runs `npm pack --dry-run`.
  • integrations/pi/skills/basic-memory-pi-setup/SKILL.md: If the user wants MCP mode, install the adapter and switch transport:
  • integrations/pi/skills/basic-memory-pi-setup/SKILL.md: pi install npm:pi-mcp-adapter
  • integrations/pi/skills/basic-memory-pi-setup/SKILL.md: Run `/bm-status` and check the effective auto recall/capture state, then `/bm-recall setup` or `/bm-capture Pi setup checkpoint` to verify the path.
  • integrations/pi/skills/basic-memory-pi-setup/SKILL.md: For local Basic Memory development in a trusted workspace, set `BASIC_MEMORY_PI_TRUST_BM_COMMAND=1` and use `bmCommand` as an argv array such as `["uv", "run", "--project", "/path/to/basic-memory", "basic-memory"]`;
  • integrations/tau/skills/basic-memory-setup/SKILL.md: Locate the integration directory: the installed `~/.tau/extensions/basic-memory` from `bm install tau`, or `integrations/tau` in an explicitly identified Basic Memory checkout.
  • integrations/tau/skills/basic-memory-setup/SKILL.md: A packaged install does not require a source checkout.
  • integrations/tau/skills/basic-memory-setup/SKILL.md: If the extension is loaded, ask the user to run `/bm-status`.
  • integrations/tau/skills/basic-memory-setup/SKILL.md: A text reply does not run a slash command or control the current Tau session.
  • integrations/tau/skills/basic-memory-setup/SKILL.md: Consult current Basic Memory install docs rather than guessing package versions or changing the user's global Tau installation.
  • integrations/tau/skills/basic-memory-setup/SKILL.md: For a packaged install, with approval for dependency installation, use:
  • integrations/tau/skills/basic-memory-setup/SKILL.md: bm install tau --sync
  • integrations/tau/skills/basic-memory-setup/SKILL.md: Then give the user this command to run in their terminal:
  • integrations/tau/skills/basic-memory-setup/SKILL.md: uv run --project ~/.tau/extensions/basic-memory tau
  • integrations/tau/skills/basic-memory-setup/SKILL.md: For source development, with approval, run `uv sync --project <integration-directory>` and launch `uv run --project <integration-directory> tau -e <integration-directory>`.
  • integrations/tau/skills/basic-memory-setup/SKILL.md: `bm install tau` installs this setup skill and the prompt templates separately;
  • plugins/claude-code/skills/bm-checkpoint/SKILL.md: `git status --short`
  • plugins/claude-code/skills/bm-checkpoint/SKILL.md: tests or checks actually run
  • plugins/claude-code/skills/bm-checkpoint/SKILL.md: `## Verification`, for checks actually run and their outcomes
  • plugins/claude-code/skills/bm-orient/SKILL.md: If no config is present, continue against the default Basic Memory project and mention that setup has not been run.
  • plugins/claude-code/skills/bm-setup/SKILL.md: Run a short, adaptive interview (~2-3 minutes) and then write the configuration.
  • plugins/claude-code/skills/bm-setup/SKILL.md: Install it: `uv tool install basic-memory --prerelease=allow` (or `pip install basic-memory`), a version exposing the 1.0 `bm_*` tools.
  • plugins/claude-code/skills/bm-setup/SKILL.md: A purely local server (`uvx --prerelease=allow basic-memory mcp`) treats the path as a local directory and fails to create it (e.g. read-only `/`).
  • plugins/claude-code/skills/bm-setup/SKILL.md: Run `bm_project_list()`.
  • plugins/claude-code/skills/bm-setup/SKILL.md: Inspect it: `bm_list(path="/", project="<primaryProject>")` for the top-level folder layout (`bm_find` for recursive discovery), sample a few notes per folder (and, where a folder holds recurring typed notes, you may run `bm_schema_infer()` to see their shape).
  • plugins/claude-code/skills/bm-setup/SKILL.md: (This is the single knob for how proactive the assistant is — the hooks always run regardless.)
  • plugins/claude-code/skills/bm-setup/SKILL.md: I can install them alongside this plugin." These are the canonical, framework-agnostic skills (the same set OpenClaw bundles).
  • plugins/claude-code/skills/bm-setup/SKILL.md: (See "Install the shared skills" below.)
  • plugins/claude-code/skills/bm-setup/SKILL.md: **First, guard against clobbering a source checkout.** If `./skills` already exists, is tracked in git, and holds `memory-*` directories, you're inside the skills' own source repo (e.g. `basic-memory` itself) — the install would overwrite the working copy with published versions.
  • plugins/claude-code/skills/bm-setup/SKILL.md: In that case **skip the install** and tell the user the skills are already present as source;
  • plugins/claude-code/skills/bm-setup/SKILL.md: Otherwise, run:
  • plugins/claude-code/skills/bm-setup/SKILL.md: If `npx` / the `skills` CLI isn't available, point the user at the manual install in the top-level [`skills/README.md`](../../../../skills/README.md).
  • plugins/claude-code/skills/bm-setup/SKILL.md: Writing the `basicMemory` block is also what stops the SessionStart hook's first-run nudge — the config's presence is the signal that setup has run.
  • plugins/claude-code/skills/bm-setup/SKILL.md: Use the CLI the hook uses (`basic-memory` / `bm` / `uvx --prerelease=allow basic-memory`).
  • plugins/claude-code/skills/bm-setup/SKILL.md: **Primary:** run the open-decision query the SessionStart hook runs against `primaryProject`: `… tool search --note-types decision --filters '{"status": "open"}' --page-size 5 --project <primaryProject>`.
  • plugins/claude-code/skills/bm-setup/SKILL.md: **Hook health:** run `basic-memory hook status --harness claude --project-dir <project-root>` with the first available `basic-memory`, `bm`, or `uvx --prerelease=allow basic-memory` launcher.
  • plugins/claude-code/skills/bm-setup/SKILL.md: the hooks already run.
  • plugins/claude-code/skills/bm-setup/SKILL.md: Run `/basic-memory:bm-status` anytime to see what I'm tracking."*
  • plugins/claude-code/skills/bm-status/SKILL.md: **CLI reachable?** Run `basic-memory --version`, then `bm --version`, then `uvx --prerelease=allow basic-memory --version`.
  • plugins/claude-code/skills/bm-status/SKILL.md: **Core hook health.** With the first available launcher, run `basic-memory hook status --harness claude --project-dir <project-root>`.
  • plugins/codex/skills/bm-checkpoint/SKILL.md: `git status --short`
  • plugins/codex/skills/bm-checkpoint/SKILL.md: tests or checks actually run
  • plugins/codex/skills/bm-checkpoint/SKILL.md: `## Verification`, for checks actually run and their outcomes
  • plugins/codex/skills/bm-orient/SKILL.md: Mention that setup has not been run.
  • plugins/codex/skills/bm-orient/SKILL.md: Run the `coding_session` topic search separately and include it only when `sessionProfile=coding` and the configured `repository` is present.
  • plugins/codex/skills/bm-setup/SKILL.md: If MCP tools are not available, run `basic-memory --version` or `bm --version`.
  • plugins/codex/skills/bm-setup/SKILL.md: If neither works, stop and tell the user to install Basic Memory and connect the MCP server.
  • plugins/codex/skills/bm-setup/SKILL.md: The plugin bundles an `.mcp.json` that starts `uvx --prerelease=allow basic-memory mcp`.
  • plugins/codex/skills/bm-setup/SKILL.md: `checkpointOnCompact`: whether post-compaction SessionStart asks Codex to run `bm-checkpoint`.
  • plugins/codex/skills/bm-setup/SKILL.md: Run `basic-memory hook status --harness codex --project-dir <repo-root>` (using `bm` or `uvx --prerelease=allow basic-memory` if needed).
  • plugins/codex/skills/bm-setup/SKILL.md: Tell the user that plugin hooks need to be reviewed and trusted in Codex before they run.
  • plugins/codex/skills/bm-share/SKILL.md: If no team projects are configured, stop and ask the user to run setup or add a target.
  • plugins/codex/skills/bm-status/SKILL.md: fallback `uvx --prerelease=allow basic-memory --version`
  • plugins/codex/skills/bm-status/SKILL.md: with the first available launcher, run `basic-memory hook status --harness codex --project-dir <repo-root>`
  • plugins/codex/skills/bm-status/SKILL.md: check `uv --version` in the current environment independently of CLI reachability;
  • plugins/codex/skills/bm-status/SKILL.md: uv is a required hook prerequisite
  • plugins/codex/skills/bm-status/SKILL.md: remind the user that Codex plugin hooks must be reviewed and trusted before they run
  • skills/AGENTS.md: Skills can be installed via `npx skills add` or copied manually into any agent's skills directory.
  • skills/AGENTS.md: memory-agents/SKILL.md # Create, run, and check Basic Memory Cloud agents
  • skills/AGENTS.md: memory-doctor/SKILL.md # Run bm doctor, explain findings, and apply fixes with consent
  • skills/AGENTS.md: Run `just check` from `skills/` or `just package-check-skills` from the monorepo root to validate the `memory-*/SKILL.md` frontmatter before committing changes.
  • skills/CLAUDE.md: Skills can be installed via `npx skills add` or copied manually into any agent's skills directory.
  • skills/CLAUDE.md: memory-agents/SKILL.md # Create, run, and check Basic Memory Cloud agents
  • skills/CLAUDE.md: memory-doctor/SKILL.md # Run bm doctor, explain findings, and apply fixes with consent
  • skills/CLAUDE.md: Run `just check` from `skills/` or `just package-check-skills` from the monorepo root to validate the `memory-*/SKILL.md` frontmatter before committing changes.
  • skills/memory-agents/SKILL.md: Agents run in Basic Memory Cloud only, on plans that include them.
  • skills/memory-agents/SKILL.md: Asked to create, change, run, or turn off an agent
  • skills/memory-agents/SKILL.md: Asked how an agent run went, what it changed, or why it did not run
  • skills/memory-agents/SKILL.md: with `agent`, whether that agent can run | | `bm_agent_run(agent="<agent>", project="<project>")` | Starts an agent on a note (`identifier`), a folder, or nothing;
  • skills/memory-agents/SKILL.md: returns the run id | | `bm_agent_get(run_id="<run id>")` | One run: status, notes changed, and the agent's last reply;
  • skills/memory-agents/SKILL.md: `whole_workspace=True` lists every run waiting for review | | `bm_agent_mark(decision="kept", run_id="<run id>")` | Mark a run `kept` or `dismissed`;
  • skills/memory-agents/SKILL.md: with no `run_id`, `kept` keeps every waiting run |
  • skills/memory-agents/SKILL.md: Read the meeting note you run on.
  • skills/memory-agents/SKILL.md: An agent changes notes only in its own project, and it runs only if both the person who last edited the agent note and the person the run is for can edit that project.
  • skills/memory-agents/SKILL.md: An agent note last edited by another agent cannot run.
  • skills/memory-agents/SKILL.md: **Ask for a reply.** The last reply is the run's summary: what it created, linked, or left alone, and anything it was unsure about.
  • skills/memory-agents/SKILL.md: **Keep each run small.** A run has about seven minutes, including startup.
  • skills/memory-agents/SKILL.md: | Agent | Run it on | |---|---| | Cleanup | A hub or project index note;
  • skills/memory-agents/SKILL.md: # -> run id. Runs usually take one to a few minutes.
  • skills/memory-agents/SKILL.md: bm_agent_get(run_id="<run id>", project="work")
  • skills/memory-agents/SKILL.md: Ask before running one, unless the user has just asked for that run.
  • skills/memory-agents/SKILL.md: `bm_agent_get(run_id="<run id>", project="<project>")` shows the status, the notes the run created, edited, moved, or deleted, and the agent's last reply.
  • skills/memory-agents/SKILL.md: Every reply is also kept in a run log note, `agents/runs/<agent> run <id>`.
  • skills/memory-agents/SKILL.md: A queued run may be waiting: for the target note to settle, for a free slot (a workspace runs a few agents at once), or for another run on the same note.
  • skills/memory-agents/SKILL.md: When a run is skipped, its reason says why:
  • skills/memory-agents/SKILL.md: the detail names the field | | `agent_disabled` | Set `enabled: true` | | `agent_changed` | The agent note changed after the run was queued;
  • skills/memory-agents/SKILL.md: run it again | | `agent_not_by_a_person` | A person, or an assistant acting for one, saves the agent note again | | `agent_removed`, `trigger_changed` | The agent note or the target note was deleted | | `instruction_author_has_no_access`, `requester_has_no_access` | That person needs a …[+123 chars]
  • skills/memory-agents/SKILL.md: A failed run says why as well: `timeout` (the run ran out of time;
  • skills/memory-agents/SKILL.md: give it a smaller job) or a model error (run it again).
  • skills/memory-capture/SKILL.md: **Always run the same-thread lookup** before deciding to create or update.
  • skills/memory-ci-capture/SKILL.md: Treat it as the immutable source of truth for repository, event type, PR number, workflow run, SHA, source URL, timestamps, and deployment environment.
  • skills/memory-ci-capture/SKILL.md: For production deploys, focus on what reached production, the deployed SHA, environment, workflow run, and verification evidence.
  • skills/memory-comark/SKILL.md: In Basic Memory Cloud, `bm_read(identifier="<note>", view="text", project="<project>")` returns the note as a reader sees it: every component as plain Markdown, with live queries run now.
  • skills/memory-comark/SKILL.md: Elsewhere, only the browser runs the query, so run the equivalent read yourself (for example `bm_search` with metadata filters;
  • skills/memory-doctor/SKILL.md: The fixes it suggests do change things, so run them only after the user agrees.
  • skills/memory-doctor/SKILL.md: Without `--skip-self-test`, doctor also runs a self-test: it writes, indexes and searches a note in a throwaway sandbox, which takes a few seconds and proves the install itself works.
  • skills/memory-doctor/SKILL.md: Run it when the report is clean but something still seems broken.
  • skills/memory-doctor/SKILL.md: Run the commands the user approves.
  • skills/memory-doctor/SKILL.md: Run `bm doctor --skip-self-test --json` again and confirm the findings are gone.
  • skills/memory-ingest/SKILL.md: **A file instead of pasted text.** For a PDF, Word, PowerPoint, or CSV file in the project, and if the `bm` CLI is available, run `bm import document <path>`.
  • skills/memory-literary-analysis/SKILL.md: The two rules that matter across a 100+ chapter run:
  • skills/memory-literary-analysis/SKILL.md: Store the map in the project (a note or a small JSON file) so later batches — and a resumed run after context compaction — do not have to rediscover it.
  • skills/memory-literary-analysis/SKILL.md: fix the spelling or add the alias, then re-run the chapter.
  • skills/memory-literary-analysis/SKILL.md: **Validate periodically.** Run `bm_schema_validate(project="<work-name>")` after each batch, not just at the end.
  • skills/memory-notes/SKILL.md: Day points run "from that date onward", so a due-date window also returns items that are already overdue.
  • skills/memory-okf/SKILL.md: With the `bm` CLI and a local project, you can run the export and check it:
  • skills/memory-okf/SKILL.md: Run `bm okf check` on a bundle, not on the project.
  • skills/memory-onboarding/SKILL.md: **Check the live docs when unsure.** Basic Memory's documentation is agent-readable: fetch `https://docs.basicmemory.com/llms.txt` for an index, and any page as clean markdown via its `raw/....md` URL (e.g. `raw/reference/mcp-tools-reference.md`, `raw/concepts/schema-system.md`). · uses the network
  • skills/memory-onboarding/SKILL.md: **Migrate existing notes** *(restructure path)* → execute the approved old→new mapping from Phase 2 before seeding anything: move each existing note to its new home, set its note type, add the observations its schema requires, and update indexes as notes land.
  • skills/memory-onboarding/SKILL.md: **Validate** → run `bm_schema_validate` on the seed notes AND any migrated notes;
  • skills/memory-onboarding/SKILL.md: Run short exercises:
  • skills/memory-quest/SKILL.md: When you tell the user to run Memory Quest again, use their host's form: `/memory-quest` in Claude Code, `$memory-quest` in Codex, or just asking for it in a chat app.
  • skills/memory-quest/SKILL.md: Tell the user to connect it and run Memory Quest again.
  • skills/memory-quest/SKILL.md: Tell the user to install the Basic Memory plugin for their assistant, or to save the memory routine from the Memory Quest panel in their assistant's instructions, then start a fresh conversation and run Memory Quest again.
  • skills/memory-quest/SKILL.md: Ask the user to open **https://app.basicmemory.com/memory-quest** and paste the code it shows. · uses the network
  • skills/memory-quest/SKILL.md: Say that the mission stays incomplete and they can run Memory Quest again any time.
  • skills/memory-quest/SKILL.md: When this machine has a local project with the same name as a cloud one, which is common because every local install creates `main`, a local Basic Memory server writes the note to the local copy however you address it, by name, workspace-qualified name, or ID.
  • skills/memory-quest/SKILL.md: If no project is listed as `cloud`, stop and tell the user to create one in Basic Memory Cloud (or connect their cloud account), then run Memory Quest again.
  • skills/memory-quest/SKILL.md: If Memory Quest still shows Mission 8 as current after a minute, the usual cause is an expired or replaced code: get a new code and run Memory Quest again.
  • skills/memory-schema/SKILL.md: **Run diff** to see current state: `bm_schema_diff(note_type="Meeting", project="<project>")`
  • skills/memory-tasks/SKILL.md: **Schema validation is your friend** — Run `bm_schema_validate(note_type="Task", project="<project>")` periodically to catch incomplete tasks

MCP servers (4)

  • README.md (basic-memory): uvx --prerelease=allow basic-memory mcp
  • README.md (basic-memory): uvx --prerelease=allow basic-memory mcp
  • plugins/chatgpt/.mcp.json (basic-memory): https://cloud.basicmemory.com/mcp · uses the network
  • plugins/codex/.mcp.json (basic-memory): uvx --prerelease=allow basic-memory mcp

Hooks (4)

  • plugins/claude-code/hooks/hooks.json (SessionStart): uv run --quiet --script "${CLAUDE_PLUGIN_ROOT}/hooks/session_start.py"
  • plugins/claude-code/hooks/hooks.json (PreCompact): uv run --quiet --script "${CLAUDE_PLUGIN_ROOT}/hooks/pre_compact.py"
  • plugins/codex/hooks/hooks.json (SessionStart): uv run --quiet --script "${PLUGIN_ROOT}/hooks/session_start.py"
  • plugins/codex/hooks/hooks.json (PreCompact): uv run --quiet --script "${PLUGIN_ROOT}/hooks/pre_compact.py"

Install scripts (1)

  • src/basic_memory/cli/commands/install.py: python src/basic_memory/cli/commands/install.py
  • Medium risk: runs-instruction-instruction-network (.claude/commands/release/release.md:106)
  • Medium risk: runs-instruction-instruction-network (.claude/commands/release/release.md:119)
  • Medium risk: runs-instruction-instruction-network (.claude/commands/release/release.md:135)
  • Medium risk: runs-mcp-server-unpinned-runner (README.md:284)
  • Medium risk: runs-mcp-server-unpinned-runner (README.md:340)
  • Medium risk: runs-mcp-server-unpinned-runner (plugins/codex/.mcp.json)
  • Medium risk: runs-instruction-instruction-network (skills/memory-onboarding/SKILL.md:66)
  • Low risk: network-instructions (AGENTS.md:17)
  • Low risk: network-instructions (CLAUDE.md:17)
  • Low risk: scripts-present (plugins/claude-code/hooks/pre_compact.py)
  • Low risk: scripts-present (plugins/claude-code/hooks/session_start.py)
  • Low risk: network-instructions (plugins/claude-code/skills/bm-setup/SKILL.md:24)
  • Low risk: scripts-present (plugins/codex/hooks/pre_compact.py)
  • Low risk: scripts-present (plugins/codex/hooks/session_start.py)
  • Low risk: scripts-present (src/basic_memory/cli/commands/install.py)

Attribution and licence

Created by
Basic Machines
Declared authors
  • Basic Machines (declared in pyproject.toml)
  • Paul Hernandez (declared in CITATION.cff)
Publisher
Basic Machines (Official Basic Machines project)
Source
basicmachines-co/basic-memory · commit 370ae9d
Licence
GNU Affero General Public License v3.0 only (files served here)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Basic Machines.

Install from source

461 of its files are not served here, so there is no ZIP. basicmachines-co/basic-memory at 370ae9d