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/1.0.md

Basic Memory 1.0 working migration guide

This is the working change list and migration guide for 1.0. It covers the new tool contracts and the corresponding changes to agents, integrations, tests, and documentation. Add migration decisions and verified instructions as release work lands. Each section distinguishes implemented development work from planned release work; neither implies that the current published release includes the change.

Cloud transfers: replace sync and bisync with push/pull

Status: implemented on the development branch for 1.0 (#1845). This completes the deprecation introduced through #1596.

What was removed

  • bm cloud sync: destructive one-way mirroring from local files to Cloud.

  • bm cloud bisync: bidirectional mirroring.

  • bm cloud bisync-reset: initialization/reset of bisync state.

The command names remain as migration-only stubs, hidden from bm cloud --help. Each one prints replacement instructions and exits with status 1. It reads no credentials, calls no Cloud API, and transfers or deletes nothing. The stubs do not invoke push or pull.

bm project remove no longer deletes a project's old bisync state directory.

Why

Cloud notes can be created and edited by people and managed agents independently of your local folder. The old sync command makes Cloud match that folder, deleting cloud-only files and files excluded by the local .bmignore. A local copy should not silently erase knowledge created in Cloud.

Push/pull provide explicit directional transfers on both Personal and Team workspaces. They preserve files found only on the destination and surface differing content for an explicit choice.

Replacement commands

Download Cloud files into the configured local folder:

bm cloud pull --name research --dry-run
bm cloud pull --name research

Upload local files to Cloud:

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

Use --workspace <workspace-slug> when the project name is ambiguous. Existing local path configuration remains useful. bm cloud sync-setup is not removed by this change: it configures that path, rather than running the legacy mirror. Personal transfers still use shared rclone setup; Team transfers use WebDAV with project-level authorization and do not require rclone setup.

Resolve differing files explicitly

By default, a transfer aborts before copying anything if it finds conflicting files or cannot compare files. It lists conflicts so you can inspect them and choose:

OptionOn pushOn pull
--on-conflict fail (default)Abort on differing filesAbort on differing files
--on-conflict keep-localReplace differing Cloud files with local contentLeave differing local files untouched
--on-conflict keep-cloudLeave differing Cloud files untouchedReplace differing local files with Cloud content
--on-conflict keep-bothSave incoming local content as a conflict copy in CloudSave incoming Cloud content as a conflict copy locally

These choices apply to differing files; new source files are still transferred. Conflict copies use a .conflict-<date> suffix before the file extension.

For an intentional local-authoritative upload, preview first:

bm cloud push --name research --on-conflict keep-local --dry-run
bm cloud push --name research --on-conflict keep-local

This preserves cloud-only files. It is not an exact-mirror replacement for cloud sync.

To download and preserve both versions of differing files:

bm cloud pull --name research --on-conflict keep-both --dry-run
bm cloud pull --name research --on-conflict keep-both
Important differences from mirroring

  • Deletions do not propagate. Deleting a local file does not delete its Cloud copy; deleting a Cloud file does not delete its local copy. A later transfer in the reverse direction can copy that file back.

  • Renames are not tracked as moves. The new path may transfer while the old destination path remains. Review and remove obsolete copies explicitly.

  • There is no shared sync baseline. Any differing content is a conflict, even when only one side was edited. These commands do not perform Git-style three-way merges or automatically choose the newest version.

  • Pull followed by push is not bidirectional mirroring. It does not propagate deletions or resolve divergent content automatically.

  • Ignore rules do not clean up previous uploads. For Personal workspaces, bm cloud prune --name research --dry-run previews Cloud files matching local .bmignore rules. Running it without --dry-run requests confirmation before deletion. This is targeted cleanup, not general mirror deletion.

Updating scripts and scheduled jobs

  1. Find calls to cloud sync, cloud bisync, and cloud bisync-reset in scripts, scheduled tasks, and personal instructions.

  2. Choose the intended direction: push for uploads, pull for downloads. If both are needed, account explicitly for conflicts and the lack of deletion tracking.

  3. Preview with --dry-run. With conflicts, select a strategy before previewing the resolved transfer; dry-run does not bypass conflict checks.

  4. Use the default conflict failure unless the workflow deliberately chooses a winning side. Monitor nonzero exits rather than silently discarding them.

  5. Handle intentional deletion or rename cleanup separately, after reviewing the affected files. Do not assume a missing local file authorizes Cloud deletion.

The removal does not delete local files, Cloud files, credentials, or old bisync state directories (~/.basic-memory/bisync-state/, or bisync-state/ under BASIC_MEMORY_CONFIG_DIR). Delete that directory yourself once you no longer need it. Existing backups and snapshots remain independent of transfer commands. Removing cloud check is outside this migration's scope.

Release checklist

  • [ ] Land #1845. The migration-only command errors are covered by tests/cli/cloud/test_removed_mirror_commands.py.

  • [ ] Verify examples against the 1.0 CLI on Personal and Team workspaces.

  • [x] Update CLI help, manuals, setup output, and repository Cloud transfer guides (docs/cloud-cli.md, bm(1), AGENTS.md).

  • [ ] Update the public Cloud transfer guides on docs.basicmemory.com.

  • [ ] Include the removal and behavioral differences in release/upgrade notes.

  • [ ] Confirm no active documentation recommends sync or bisync as a transfer workflow.

MCP tools: migrate to the bm_* surface

Status: implemented on the development branch for 1.0 (SPEC-35.2). Upgrade your server and its agent packages together, then restart clients to refresh cached tool schemas and permission lists. Legacy MCP registrations are removed immediately, with no compatibility aliases or transition window.

bm tool mirrors the 1.0 tools: one subcommand per bm_* tool, flags named after the tool's parameters in kebab case, and the same Pydantic validation an MCP client gets. Output is the tool's text result, or its JSON result with --json. bm tool no longer switches to JSON when piped, and --plain and the Rich renderers are gone; scripts pass --json. Without --project, commands use the configured default project.

Previous CLI1.0 CLI
write-note, write --title T --folder F --type Xwrite --title T --directory F --note-type X (or --identifier path.md)
read-note, read --frontmatterread (frontmatter is now included by default)
read (body only, the old default)read --no-include-frontmatter
edit-note, edit --operation OPedit --command OP
delete-note, delete ID --is-directorydelete --identifier ID, or delete --path DIR --recursive
search-notes, search --vector/--hybrid/--title/--permalinksearch --mode semantic/hybrid/title/permalink
search --meta k=v, --filter JSON, --tag, --statussearch --filters JSON
search --type T, --entity-type K, --after_date Dsearch --note-types T, --items K, --since D
search --category Csearch --categories C
build-context, context URL --timeframe Dcontext IDENTIFIER --since D
recent-activity, recentrecent
recent --timeframe D --type K --depth Nrecent --since D --items K; depth is fixed at 1
list-projects, projectsproject-list
list-workspaces, workspacesproject-list (omits workspaces with no projects), or bm cloud workspace list for every workspace
schema-validate, schema-infer, schema-diff, validate, infer, diffschema-validate, schema-infer, schema-diff; a positional TYPE becomes --note-type TYPE
validate path/note.mdschema-validate --identifier path/note.md
--project-id UUID--project UUID
--plainremoved; the default output is the tool's text result
(new)move, list, find

The shell read verbs now run the same tools the same way: bm cat and bm head call bm_read, bm grep calls bm_search in text mode, bm ls calls bm_list, and bm find and bm tree call bm_find. Their output is the tool's text result, or its JSON result with --json.

Previous shell verb1.0 shell verb
bm tailremoved; use bm tool recent
--plain, Rich tables, JSON when pipedremoved; text result by default, --json for JSON
--project-id UUID--project UUID
no --project with several projects: refusedthe configured default project
<project>/path routes to that project by itselfpass --project <project>; a prefix naming another project is refused
bm ls / lists the projectslists the default project's root; bm project list lists projects
bm cat --lines with --no-frontmatter counts body lines--lines always counts the whole file, frontmatter included; --frontmatter applies to whole-note reads
bm head --frontmatter/--no-frontmatterremoved; head reads lines 1-N of the file
bm grep -C/--context-lines Nbm grep -C/--lines N
bm grep "" refused; -C with --semantic refusedfollow bm_search
(new) bm grep --path DIRsearch one folder
(new) bm ls --glob, --sortbm_list's file-name glob and order
ls/find/tree --page-size up to 2001-100; tree defaults to 100
bm find --fields hit rows rendered as a tablebm_find's text result

The bundled manual page tools-migration(7) (bm man tools-migration) carries these tables.

Previous MCP tool1.0 replacement
read_note, read_content, view_note, catbm_read with explicit line bounds where needed
write_notebm_write
edit_notebm_edit
search_notes, grepbm_search
build_contextbm_context
list_directory, lsbm_list for one level; bm_find for recursive inventory
findbm_find
recent_activitybm_recent
tailbm_recent; map timeframe to since and lines to page_size. Recent JSON includes created_at, not updated_at. The bm tail shell command is removed; use bm tool recent.
list_memory_projectsbm_project_list
list_workspacesbm_project_list groups projects by workspace, so it omits a workspace with no projects; bm cloud workspace list in a shell lists every workspace
create_memory_projectbm_project_create(name=..., path=...)
delete_projectbm_project_delete (opt-in)
schema_validate, schema_infer, schema_diffbm_schema_validate, bm_schema_infer, bm_schema_diff
move_notebm_move
delete_notebm_delete
manbm_man
Tool-by-tool change list

The primary surface has twelve tools, plus the separately enabled destructive bm_project_delete operation. The registry in src/basic_memory/mcp/tools/__init__.py and installed manuals are authoritative.

ToolCapabilities and migration details
bm_readExact note/file reads, with line, section, and token-budget bounds. Missing targets are refusals; callers must search separately instead of relying on fuzzy read fallback. JSON includes revision metadata.
bm_writeCreate notes or explicitly overwrite an existing target. Guard overwrites with expected_checksum; consume the compact change receipt.
bm_editIncremental edits and frontmatter changes selected by command. A missing note is refused, not created.
bm_deleteDelete a note through identifier, or a directory through path with recursive=True. Remove the old is_directory argument; locked-note protection still applies.
bm_moveMove a note or directory to destination. A trailing slash means move into that directory under the source's existing name; without it, the destination is the new path.
bm_searchRanked text, title, permalink, semantic, or hybrid search; metadata filters; project scopes; and matching-line searches. Replaces both note search and the MCP grep workflow.
bm_contextBuild graph context from an exact identifier, with bounded depth and time window. Whitespace-only identifiers are refused.
bm_listList one directory level in the required project. / is that project's root; discover projects with bm_project_list.
bm_findRecursive file discovery with path and frontmatter filters. Use this for inventory rather than expecting recursive bm_list results.
bm_project_listList projects (1.0 shipped this as bm_project(command="list"); 1.1 splits it). Project rows carry workspace metadata.
bm_project_createCreate a project (1.0: bm_project(command="create")).
bm_recentRecent changes in the required project (1.0: bm_project(command="recent")).
bm_project_deleteSeparate, opt-in destructive project deletion. Keep it separate in tool permissions and agent allowlists.
bm_schema_validate, bm_schema_infer, bm_schema_diffSchema validation, inference and drift (1.0 shipped these as bm_schema(command=...); 1.1 splits them).
bm_manDiscover, read, or search installed manuals. Supply a page or a query, not both; no project selection is required.
Change arguments and response handling too

  • Pass names, workspace-qualified names, or external UUIDs through required project. Remove project_id; calls do not retain a selected project between requests.

  • Search uses mode, filters, items, since, and all_projects instead of search_type, metadata_filters, entity_types, after_date, and search_all_projects. Use items=["note"] for whole notes. Put tags and status inside filters; note_types still filters frontmatter types.

  • Edit uses command instead of operation. set_metadata edits frontmatter; edits never create missing notes.

  • Context uses identifier instead of url and since instead of timeframe. It defaults to JSON and a seven-day window. Depth is bounded to 1–5.

  • Recent activity uses command="recent" and since. JSON returns an object with results and paging fields, rather than a bare array.

  • Project discovery returns project rows with workspace fields. It does not return the old standalone workspace role/subscription response.

  • Reads use start_line, end_line, section, or max_tokens; page and page_size do not slice note content. JSON reads include frontmatter by default; pass include_frontmatter=False when a consumer needs the body alone.

  • Move uses destination. End a folder destination with / to preserve the file name. JSON move/delete receipts identify success through action (moved or deleted), rather than boolean moved/deleted fields.

  • Refusals set MCP isError. JSON error text contains error, message, and sometimes try_instead. Handle NOT_FOUND, ALREADY_EXISTS, and REVISION_CONFLICT; do not treat them as successful empty results or expect legacy NOTE_* payload fields. Read again to obtain the current checksum.

For an overwrite, prefer the exact returned file_path as identifier and pass expected_checksum from a fresh read. Do not reconstruct a filename from a title.

note = await bm_read(identifier="notes/Plan.md", project="research", output_format="json")
await bm_write(
    identifier=note["file_path"],
    content="Updated plan.",
    overwrite=True,
    expected_checksum=note["checksum"],
    project="research",
)
await bm_search(filters={"status": "active", "tags": ["planning"]}, project="research")
await bm_recent(since="7d", project="research", output_format="json")
Update callers and installed instructions

Update custom agents, hooks, MCP allowlists, tool routers, recorded request fixtures, and test fakes as well as prompts and skills. Native Hermes and OpenClaw wrappers may retain their host-facing arguments while translating to the new MCP contract. Tau preserves the core bm_ prefix; there is no bm_bm_write tool.

Use bm_man(page="bm-search(3)") or bm man bm-search for the installed reference. Re-run benchmark baselines after upgrading; historical results describe the tool surface they were measured against and should not be relabeled as 1.0 results.

Project routing and refusal handling

  • Core note, folder, context and schema calls require a nonempty project, including single-project sessions, constrained servers and qualified targets. Discovery (bm_project_list) and bundled manuals need no project. bm_recent requires project too.

  • Search requires explicit scope: project for one project, projects for selected projects, or all_projects=True for all accessible projects. A project-qualified path or memory URL does not replace explicit search scope.

  • A relative path such as notes/topic.md does not select a project merely because it contains a slash. Pass scope with every call; qualified identifiers must agree with that scope. Restart MCP clients to refresh required parameters.

  • Search resolves project-qualified memory:// URLs without rewriting stored project-qualified permalinks into workspace-qualified identities.

  • Native ChatGPT search/fetch and saved search/continue prompts resolve their selected/default project before calling the stricter core tools. Qualified fetch targets still select the project they name.

  • Mutation receipts replace prose/footer parsing. Use action, file_path, permalink, and checksum where returned; moves include previous_file_path.

  • Handle LOCKED, INVALID_ARGUMENTS, OUTSIDE_PROJECT, and other typed refusals as errors. An absent checksum does not prove a note was deleted. For OUTCOME_UNKNOWN, read back the target before retrying a mutation.

Agent instructions, prompts, and packages

Status: migrated in the development branch as part of Core PR #1849.

  • Updated canonical skills/memory-*, onboarding references, skill indexes, and the shared skill-bundle source to the new names, arguments, and receipts.

  • Updated Claude Code and Codex harness skills, Claude output style, setup examples, and shared schema examples, including the synchronized Tau copies.

  • Refreshed Pi's generated skill references and their generation input; updated Hermes's bundled skill and Tau's setup skill.

  • Updated MCP server instructions, the assistant-guide resource, and the extended assistant guide so agents are taught the same contracts the server exposes.

  • Migrated the search, recent-activity, continue-conversation, and getting-started prompts. Search and continue propagate project scope and MCP context to tools.

  • Updated package validators and assertions to check the migrated instructions.

Runtime integrations and compatibility

Status: adapters migrated and review fixes included in Core PR #1849.

  • Hermes: outbound MCP calls and response handling use the new tools while preserving the host-native memory-provider interface.

  • OpenClaw: the client translates native wrapper arguments to the new MCP contracts and preserves structured refusal messages. Workspace discovery deduplicates workspace metadata from project rows; it does not invent the old workspace role/subscription fields. Overwrite guidance documents checksum guards.

  • Tau: preserves existing bm_ names instead of adding a second prefix. When legacy aliases and native tools collide, native registrations win regardless of discovery order; noncolliding extras remain available.

  • ChatGPT (Cloud only): hosted search and fetch delegate to the new core tools, preserving default-project behavior and qualified target routing. Core does not register these adapters.

  • Legacy view wrapper: the view_note MCP registration is removed; use bm_read.

  • Removed the unused, disabled MCP UI SDK implementation and its obsolete tests. This does not remove the separately supported hosted MCP App interface.

The legacy core registry is removed as part of #1833. Old manual pages for retired tools are removed; tools-migration(7) (bm man tools-migration) maps each retired tool to its replacement. Run local diagnostics with bm doctor. Native host wrapper interfaces and separately advertised hosted Cloud review/App APIs retain their own contracts.

Tests and benchmark migration

Status: callers and assertions migrated; fresh model-driven benchmark results remain a release follow-up.

  • Migrated integration-test MCP calls, dynamic helpers, and fixtures to bm_*. Assertions check actual new receipts and refusals rather than a legacy adapter.

  • Preserved coverage for checksum conflicts, concurrent writes, locked notes, path safety, directory operations, metadata identity, search, and workspace routing.

  • Added real MCP regressions for saved-prompt default/explicit project routing and ChatGPT relative/qualified fetch identifiers with multiple projects.

  • Added Tau registration tests for both legacy/native discovery orders, checking native schemas, actual dispatch, and preservation of noncolliding extras.

  • Updated OpenClaw's real filesystem tests to wait for bounded asynchronous file materialization rather than treating an immediately stale projection as failure.

  • Replaced benchmark rich/POSIX surface comparisons with one canonical bm surface. Read-only scenarios filter mutation tools from that surface.

  • Migrated benchmark providers, load/concurrent-write runners, task graders, scripted smoke inputs, and the bundled read/edit/search manual corpus.

  • Retained clean-checkout benchmark provenance checks and historical result artifacts. Old results require their matching runner revision for reproduction.

Migration verification included core SQLite and PostgreSQL CI, static checks, package checks, adapter regressions, the benchmark unit suite, and a successful scripted agent-task smoke run. Paid/model-driven benchmark baselines have not been rerun; a scripted smoke result is not a performance comparison.

Documentation and historical cleanup

Status: current repository docs migrated in Core PR #1849; public-site changes are in Docs PR #52.

  • Updated README, architecture, search, manual, plugin, and live-test guidance, including hidden Claude commands that generate or exercise tool calls.

  • Aligned bundled tool manuals with explicit project routing and labeled legacy manual pages as retirement notices.

  • Updated the docs site's MCP reference, migration guide, current user/setup guides, navigation examples, saved prompts, and error/retry guidance.

  • Labeled upcoming 1.0 guidance without rewriting the published 0.24 release history or implying that the site changes deploy the server.

  • Moved post-v0.18.0-test-plan.md and mcp-ui-bakeoff-instructions.md into docs/archive/ with historical banners. Kept release notes, changelogs, and benchmark results as records of the versions they actually describe.

Runtime dependency updates

Status: FastAPI upgrade implemented on the development branch; Python 3.15 support deferred pending upstream packages.

  • Upgrade FastAPI from 0.139.0 to 0.162.0 and resolve its OpenTelemetry dependencies with a compatible Logfire version. FastMCP remains at 4.1.3, the latest stable release checked on 2026-10-24.

  • Replace the removed FastAPI get_flat_dependant helper with direct traversal of route dependencies. Cache keys still include nested query parameters and use validated request bodies; regression tests cover aliases and default values.

Python 3.15: blocked by ONNX Runtime

Python 3.15 is released, but Basic Memory's default installation depends on fastembed, which depends on onnxruntime for local model inference. On 2026-10-24, installing the locked dependencies with Python 3.15.1 failed because ONNX Runtime 1.27.0 has no compatible wheel or source distribution. The latest ONNX Runtime 1.31.0 also has no Python 3.15 wheels; updating FastEmbed from 0.8.0 to 0.9.0 does not remove that dependency. The separate onnx model-format package is not a replacement for ONNX Runtime.

Track upstream Python 3.15 wheels. Keep Python 3.12–3.14 in the supported test matrix and use Python 3.14 for local development. Local embeddings remain part of the default installation; do not silently disable them to claim Python 3.15 support.

Before enabling 3.15:

  • [ ] Verify published ONNX Runtime wheels for the supported operating systems.

  • [ ] Refresh the lockfile and verify a complete runtime/dev installation on 3.15.

  • [ ] Run real local-embedding, SQLite, PostgreSQL, MCP, and package checks.

  • [ ] Add Python 3.15 to CI and update the documented support range.

Remaining 1.0 release work

  • [ ] Land the core and docs-site migration PRs and publish the updated packages/docs.

  • [ ] Land the legacy tool retirement in #1833, including the final advertised tool inventory and manual retirement notices.

  • [ ] Rerun model-driven benchmarks against the new tool surface and record fresh baselines with exact code/model provenance.

  • [ ] Complete the cloud-transfer removal and verification checklist above (#1845).

  • [ ] Verify released server/package combinations, client schema refresh, and permission/allowlist migration; include the breaking changes in release notes.

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