open-memex
Persistent memory for your AI coding agents — on your machine, in plain Markdown, shared by every tool you code with.
Усильте агента
Собственная команда издателя. Не эндпоинт PlugMCP.
Host a copy with our keys and logs.
npx -y [email protected]У Claude Code нет ссылки для установки локальной команды. Скопируйте команду ниже и выполните её в терминале.
claude mcp add io.github.stoneskin-open-memex -- npx -y open-memex@0.10.0Выполните в терминале.
{ "mcpServers": { "io.github.stoneskin-open-memex": { "command": "npx", "args": [ "-y", "[email protected]" ] } }}claude_desktop_config.json
Удалённый URL или команда на вашем компьютере? Чем различаются два способа установки
Запустить на PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
ЗапускEvery AI coding session starts from zero: you re-explain the project, the agent rediscovers the same gotchas, and yesterday's decisions vanish when the chat ends. open-memex gives your agents a memory that survives the session. Say "remember: we deploy on Fridays" once, and next week Copilot, Cursor, opencode, or Claude Code already knows — because they all read and write the same local memory on your machine.
ship finds deploy, 单点登录 finds SSO —
a curated multilingual map of equivalents is indexed with every memory at
write time, so no related wording misses the right answer. Deterministic
and auditable, no embedding model required.
New here? This README takes you from install to a working memory in about a minute. The concept guide explains the mental model in depth once you're up and running.
init changes on your machineYou need Node.js ≥ 22.14 (check with node -v). Then:
npm install -g open-memex
open-memex init
init detects the editors you have installed (VS Code, Cursor, opencode, and
Visual Studio when your project has a solution file) and connects each one to
open-memex. Restart your editor afterwards.
See it work (30 seconds):
open-memex add "This project deploys on Fridays"
Now open a new chat in your editor and ask your agent: "When does this project deploy?" It already knows — no re-explaining. That round trip, capture once and recall forever, is the whole product. Everything below is detail.
Optional but recommended — check everything is wired up:
open-memex doctor
Four ideas explain almost everything open-memex does.
1. Two scopes: project and personal.
Every memory belongs to one of two places:
Facts about you ("I prefer concise diffs") go to personal; everything else
defaults to the current project.
2. Capture → recall. Memories are saved as small Markdown files, one fact each. On the first turn of every new session, open-memex hands your agent the most relevant ones automatically, so it starts the session already knowing them. The agent can also search the full memory on demand. You never have to "load" anything yourself.
3. Your files, your rules.
The Markdown files are the source of truth — open them, edit them, delete them,
grep them. The SQLite index next to them is just a search accelerator and
rebuilds from the files at any time (open-memex reindex). Team sharing, when
you want it, goes through the same review flow as code: nothing is shared
automatically (see Team workflow).
4. Knowledge stays current.
Facts change: decisions get reversed, tools get replaced, yesterday's gotcha
gets fixed. open-memex doesn't let the old version quietly linger —
memory_supersede replaces a memory with its newer version and keeps the
chain, so retrieval serves the current fact while the history stays auditable.
Merely stale memories can be deprecated, and open-memex audit reports
duplicates, stale entries, and broken chains. Pruning is a feature, not
housekeeping: shared memory rots without it.
open-memex talks to editors two ways: a native opencode plugin, and a
standard MCP server that any MCP-capable editor can use. (MCP — Model
Context Protocol — is the open standard editors use to give agents extra tools;
open-memex appears in your editor as a set of memory_* tools.) What you get
depends on which path an editor uses:
* MCP has no hard session-start hook, so open-memex sends the agent guidance in
the MCP handshake (including how many drafts are waiting) and init writes the
fuller version into the editor's instruction files. In practice agents follow
it; the opencode plugin is the only path with true built-in first-turn
injection. The Tools section lists the 5 core tools
and the 6 extra workflow tools, so the "5 vs 11" split is explicit.
All editors on the same machine read and write the same memory — a constraint captured in VS Code is respected in opencode; a lesson learned in Cursor shows up in Claude Code. (Different machines do not sync automatically; see the FAQ.)
init also installs an Agent Skill (a short instruction file that teaches
skill-aware agents to use the CLI) for VS Code and Cursor, and for opencode in
per-project MCP mode. With the opencode native plugin wired, no skill is
installed there — the plugin already provides the memory tools, and a second
instruction set only made agents chatty.
Instruction files are great for a handful of standing rules — keep using them
(open-memex can even draft one from your memories; see distill-agents below).
open-memex covers the growing pile of decisions, lessons, and preferences that
no one remembers to write down.
open-memex doctor verifies this for you). The floor is
the SQLite driver's: better-sqlite3 13 is built against Node-API 10, which
Node gained in 22.14.0 — older Node segfaults on the first database open.npm install -g open-memex
That's the stable release. Installing the package may print a reminder to run
open-memex init — the editor wiring is a separate step (see
Setting up your editor), so don't worry if you
don't see the reminder; just run init next.
Two alternatives:
npx -y open-memex <command> runs any command
without installing (e.g. npx -y open-memex init --client vscode). Slower to
start, nothing to uninstall.npm install -g open-memex@alpha. Check what's published with
npm view open-memex version (stable) and npm view open-memex@alpha version
(alpha).If open-memex isn't found after installing, your PATH needs attention — see
Troubleshooting.
git clone -b main https://github.com/stoneskin/open-memex.git
cd open-memex
npm install
node --experimental-strip-types src/cli.ts <command>
Run init from your project root (the top folder of the repo you're working
in) so the project scope resolves to that repo:
open-memex init --yes
# …or without installing the package first:
npx -y open-memex init --yes
--yes accepts the recommended defaults for everything init asks about
(editors to wire, auto-capture, first-turn recall). Leave it off if you want to
answer each question. With no --client, init detects your installed editors
and wires them all — one init covers every project. Prefer a single editor?
Pass --client:
VS Code (Copilot):
open-memex init --client vscode
Writes the MCP server entry; reload the window afterwards and confirm the
open-memex server is started in Copilot Chat's MCP panel. By default this
writes a project-level .vscode/mcp.json (an interactive run asks which
level you want); add --global for VS Code's user-level config instead —
one setup that works in every project.
Cursor:
open-memex init --client cursor
Same shape as VS Code: project-level .cursor/mcp.json by default,
user-level MCP config with --global, plus Copilot-style instructions.
opencode (native plugin — recommended):
open-memex init --client opencode --global --yes
Merges the native plugin into your user-level ~/.config/opencode/opencode.json
(or opencode.jsonc if that's the file you already have) — one-time, every
project picks it up, no per-project init. You get the 5 core tools, keyword
auto-capture, and first-turn context injection. (A config file with comments is
left untouched — init prints the line to add by hand.)
Both opencode generations are supported from the same install: init writes
the opencode 1 spelling ("plugin") and the opencode 2 spelling ("plugins")
— each host reads its own key. Opencode 1 needs version 1.18.29 or newer
for this. open-memex doctor tells you if the wiring and the installed host
version don't match.
opencode (as a plain MCP consumer):
open-memex init --client opencode
Writes a project-level opencode.jsonc with the MCP server. Only needed if you
prefer plain MCP over the native plugin — you give up keyword capture and
built-in injection.
Claude Code (from your project root):
claude mcp add open-memex -- open-memex mcp
# …or print the config snippet: open-memex mcp --print-config claude
Visual Studio (from your solution directory):
open-memex init --client visualstudio
Writes solution-level .mcp.json. Requires Visual Studio 2022 17.14+ or Visual
Studio 2026 (Windows-only). Visual Studio also auto-discovers .vscode/mcp.json
and .cursor/mcp.json, so the VS Code setup above works too.
Codex: no init client yet — add the server manually via
open-memex mcp --print-config as a starting point ([mcp_servers] in
config.toml, or codex mcp add).
open-memex init --client vscode --global --yes
Two different "globals" — don't mix them up.
npm install -g open-memexinstalls the package globally: it puts theopen-memexcommand on your PATH.init --globalwrites the editor config at user level instead of the project: init once, the wiring works in every project. It works the same whether the package was installed globally or run via npx.
The --global form writes the server entry to the editor's user-level MCP
config (%APPDATA%\Code\User\mcp.json on Windows,
~/Library/Application Support/Code/User/mcp.json on macOS,
~/.config/Code/User/mcp.json on Linux; ~/.cursor/mcp.json for Cursor)
instead of the project — init once, the server starts in every project.
A per-project .vscode/mcp.json still wins if a project defines its own.
If the user-level file has comments in it (editors accept JSONC), init leaves
the file untouched and prints the exact snippet to paste in by hand.
init behavior notesinit
is safe. --force rewrites our entries.open-memex on PATH (e.g. one-shot npx), init writes an
npx -y open-memex mcp server command into the config so the setup keeps
working. npm i -g open-memex + open-memex init --force switches to the
faster direct command later.init shows the detected editors and asks you to
confirm; scripts and CI never prompt and wire every detected editor.open-memex on a machine where init never completed, it
offers to run it for you (interactive terminals only).open-memex uninstall --yes
Reverses init — removes the MCP server entry, the opencode plugin line, the
Agent Skill, and the open-memex section of the editor instructions. With no
--client it cleans up every detected editor; --global limits the cleanup to
user-level wiring. Your memories are never touched.
init changes on your machineEverything init writes, in one place:
init itself):
%APPDATA%\open-memex\ on Windows, ~/.local/share/open-memex/ on
macOS/Linux — your memory files and the search index. Nothing here is ever
modified by uninstall.open-memex uninstall):
"plugin" entry (opencode 1) and a "plugins" entry
(opencode 2) merged into
~/.config/opencode/opencode.json (or .jsonc). Stale my-o-memory
entries from before the rename are removed at the same time.open-memex server entry in the user-level or
project-level MCP config, plus an open-memex section in the Copilot
instructions (user-level ~/.copilot/copilot-instructions.md by default;
--instructions project writes .github/copilot-instructions.md in the
repo instead, for teams where everyone uses open-memex)..mcp.json next to your solution.skills/open-memex/ folder for VS Code
(~/.copilot/skills/), Cursor (~/.cursor/skills/), or opencode in
per-project MCP mode (~/.config/opencode/skills/).submit (see Team workflow) — a local commit, never an automatic push.Files with comments (JSONC) are never rewritten: init prints the exact
snippet to paste instead.
Three ways memories get in:
remember …,
note that …, don't forget: …, TIL …, save this … — or in Chinese
记住… / 记一下… / 记录一下… / 别忘了：… — and the sentence is captured
without any tool call. Captures land in the current project by default;
phrases that signal "this is about me" — remember for me …, help me remember: …,
记住我…, 替我记…, 帮我记…, 我觉得…, 我喜欢… — go to personal instead, and
team-context phrases (我们决定…, 帮我们记住…) stay in project.
Two rules keep the noise down (D67): a trigger must be a statement to the
store, so the narration forms 记得… / remind me to… / 别忘了带伞 /
don't forget the wifi password never fire (add a separator — 别忘了：…,
don't forget: … — or that to make it an instruction); and a captured body
under 3 characters is rejected as a fragment rather than saved — capture --dry-run says so instead of dropping it silently. A trigger also owns its
own sentence: the plugin tells the agent what it just stored, and a
memory_add that re-saves the same words within the next few minutes is
refused with the stored id (D73) — one thing you said is one memory, not
three copies of it.memory_add. The routing above is a heuristic; you can always say "save this
to my personal memory" or use the CLI with --scope to be explicit.open-memex add "…" with optional --scope / --tag / --type
/ --aliases.Aliases. Each saved memory can carry up to 4 alternate phrasings
(synonyms, another language's equivalent) that are indexed with it, so a
question worded differently still finds the memory — "vacation days" finds the
holiday policy. Always on — the agent may attach up to 4 per memory, and you
can pass your own via open-memex add --aliases.
Three ways to add them: open-memex add "text" --aliases "phrase one; phrase two" (semicolon-separated, up to 4); ask the agent ("remember: Fluffy is my
AI agent, alias it as Momo"); or edit the memory's aliases: frontmatter
directly — Markdown is the source of truth and sync picks it up.
Separately, a curated synonym/translation map is expanded into the index
automatically at write time (D80) — ship finds deploy even with no
aliases on the memory. Personal nicknames belong in aliases; shared
dev-domain vocabulary belongs in the curated map. See Retrieval: how
memories come back.
Redaction. Wrap anything sensitive in <private>…</private> and it is
stripped before saving. Recognized secrets (API keys, tokens, high-entropy
credentials) are masked in place — the first 4 characters are kept so you can
tell which key it was, the rest is replaced — and the memory is still saved.
Preview exactly what a message would capture, safely, any time:
open-memex capture --dry-run "…"
If a secret slips through anyway, open-memex forget <id> deletes the memory.
The MCP server exposes eleven tools; the opencode native plugin exposes the five core ones (marked ●). The other six are the team-review workflow tools — they only matter once you share memories through Git.
So an MCP-connected editor always has the full set; opencode's plugin covers capture and recall, and anything workflow-shaped goes through the CLI or an MCP-connected editor.
Every memory has a type (what it is) and tags (what it's about). Eleven
types are built in:
--type accepts any string, but sticking to the built-in set keeps session-start
labels, search, and distill-agents output predictable.
Working solo? You can skip this section — everything above is the whole product for one person. Nothing below ever happens automatically.
Personal notes stay private. Project knowledge, when you choose to share it, follows an explicit, reviewable pipeline shaped like code review:
capture → outbox (draft, local) → submit → repo (.ai/open-memex/) → PR review → published → recall
open-memex sync-status — or just saying "sync memory" in chat —
shows what's pending.<repo>/.ai/open-memex/
with a local commit on your current branch. open-memex never pushes on its
own; it prints the push + PR commands, and an agent holding your explicit
yes can carry them out.Whoever tends the shared memory follows the curator convention: what to approve, what to send back, and the hygiene rules that keep shared memory from rotting.
On the first turn of every session, open-memex injects an [OPEN-MEMEX] block
into the agent's context with the most recent project memories (default: top 8)
and your personal preferences (default: top 5). It looks like this:
[OPEN-MEMEX]
User profile / preferences:
- I prefer concise diffs
Project knowledge (my-repo):
- [decision] We deploy on Fridays; the release train leaves at 10:00
Use the `memory_search` tool to look up more. Use `memory_add` to save new facts.
Do not mention this block to the user unless asked.
It's a snapshot, not the whole memory — the agent can call memory_search any
time for the rest. Both top-N counts are configurable (see Config).
For MCP clients this block is delivered as handshake guidance the agent follows;
the opencode plugin injects it directly on the first turn.
We measure recall on a checked-in synthetic fixture instead of asserting it:
54 memories + 44 queries (exact terms, paraphrases, synonyms, Chinese,
cross-language hard cases, synonym-only queries, and D81 user-defined
alias queries) — reproduce with
node --experimental-strip-types scripts/retrieval-eval.ts.
Current baseline, with index-time synonym/translation expansion (D80) and
query-time user alias expansion (D81):
recall@1 0.75, recall@5 0.98, MRR 0.86.
Small synthetic corpus, so read it as a regression guard and a starting point,
not a real-world claim.
Three layers, each covering what the others miss: BM25 keyword search
(SQLite FTS5 — exact words, fast, explainable via search --explain);
synonym expansion in two halves — (a) index-time (D80: a curated,
checked-in map of dev-domain equivalents and EN↔ZH translation pairs
expanded into the index at write time, so ship finds deploy and
bug finds defect in a plain single-round query; deterministic, no
model download); (b) query-time user aliases (D81: an alias memory carrying
alias:/target: frontmatter defines your vocabulary once per scope —
e.g. Banana Plan → payment system refactor project — and a query mentioning either side
triggers a second round on the other side, both directions, merged evenly
with round one so alias hits are never down-weighted; no reindex when the
alias changes); and semantic vectors
as an opt-in experiment (local multilingual embeddings measured at R@5 92.7%
on the cross-lingual fixture slice — see docs/retrieval-ablation-study.md
§4.7; no embedding model is ever downloaded without your explicit opt-in).
External check on public data: the same pipeline scores recall@5 97.0% /
MRR 0.909 on LongMemEval-S (470 questions, retrieval stage only — no answer
generation, no judge model; this is not the official LongMemEval score). For
reference, agentmemory's published numbers on the same protocol are 86.2% /
0.715 (BM25-only) and 95.2% / 0.882 (BM25+vector). A 22k-memory pooled stress
run drops recall@5 to 40.6% — the lexical ceiling, measured rather than
asserted. Reproduce with
node --experimental-strip-types scripts/bench-longmemeval.ts --data <path>
(dataset: xiaowu0162/longmemeval-cleaned, MIT).
%APPDATA%\open-memex on
Windows, ~/.local/share/open-memex on macOS/Linux) plus the repos you
choose. Zero cloud calls, zero accounts, zero third-party APIs, zero
telemetry.<private>…</private> spans are stripped; detected API
keys/tokens are masked in place before saving. Preview with
open-memex capture --dry-run "…".personal scope is this machine only —
excluded from export by default and can never enter a repo.submit, travel
through branch/PR review, and every promote transition is appended to the
memory's review_history (who / when / why).Honest edges, so nothing surprises you:
ship finds
deploy, bug finds defect). Paraphrases outside the curated map
don't match — that's what the opt-in semantic layer is for. (Plain
questions are fine — "how do we…" / "请问…" wording is filtered out before
matching, so asking naturally doesn't dilute the results.) No embedding
model is ever downloaded without your explicit opt-in. (Synonym expansions
live in their own index column, separate from your own aliases — but a
query matching only via an expansion can still rank below direct matches;
that's inherent BM25 length-norm behaviour, not a bug.)export / import bundles (below) move memory between
machines manually.memory_search
away, but they are not all in context at once.remember for me …, 我喜欢…) go to personal; everything else defaults to the current
project. When it guesses wrong, say the scope out loud or use --scope in
the CLI.npm install -g open-memex@latest # or @alpha
Your editor configs point at the installed open-memex command, so upgrades
need no re-wiring. After a major upgrade, run open-memex init --force once to
refresh the installed Agent Skill and instruction files with the latest wording.
If you installed from source or moved the package, --force also re-points the
opencode plugin path.
What changed in each version: see the CHANGELOG.
%APPDATA%\open-memex\ (Windows)
~/.local/share/open-memex/ (macOS/Linux; $XDG_DATA_HOME if set)
├── index.db # SQLite FTS5 index (rebuildable)
└── memories/
├── personal/
│ └── <id>.md
└── project__<name>__<hash12>/
└── <id>.md
Each .md file is one memory: YAML frontmatter (id, scope, type, tags, created_at, schema_version, …) followed by the content. You can edit them by
hand — the index re-syncs from the files, and Markdown is always the source of
truth (open-memex reindex rebuilds the index from scratch).
Once you submit, project memories also live as Markdown files under
<repo>/.ai/open-memex/ (configurable via memoryDir), where they travel with
branches and PRs like any other file.
Settings live in ~/.config/opencode/open-memex.jsonc — the opencode in the
path is historical; this one file is shared by every client. Override the config
path with OPEN_MEMEX_CONFIG and the storage root with OPEN_MEMEX_HOME
(the pre-rename MY_O_MEMORY_CONFIG / MY_O_MEMORY_HOME names are still
honored as fallbacks).
Defaults:
{
"maxProjectMemories": 8, // top-N project memories injected on first turn
"maxProfileItems": 5, // top-N personal items injected on first turn
"injectOnFirstTurn": true, // [OPEN-MEMEX] system-prompt block
"keywordCaptureEnabled": true,
"logLevel": "info", // info | debug
"memoryDir": ".ai/open-memex" // in-repo project-memory dir, relative to repo root
}
open-memex config prints the effective config (defaults + file). Change a
setting after install:
open-memex config set keywordCaptureEnabled false
open-memex config set maxProjectMemories 12
open-memex config set sync.autoPull true # best-effort pull at MCP session start
Settable keys: maxProjectMemories, maxProfileItems, injectOnFirstTurn,
keywordCaptureEnabled, captureAliases, logLevel, memoryDir, and sync.autoPull (a dotted
key that writes into the nested sync object). Full design:
docs/V2-DESIGN.md.
Setup & health:
open-memex init [--client vscode|cursor|opencode|visualstudio]
[--instructions personal|project] [--global] [--force] [--yes]
open-memex uninstall [--client vscode|cursor|opencode|visualstudio] [--global] [--yes]
open-memex config # print effective config
open-memex config set <key> <value> # change a setting
open-memex doctor # environment health check (incl. plugin entry)
open-memex audit # memory health check (duplicates, stale, broken chains)
open-memex capture --dry-run "remember that I like concise answers" # preview keyword capture
open-memex mcp --print-config vscode|cursor|claude|opencode|visualstudio
open-memex --help # this reference
open-memex <command> --help # help for one command
open-memex --version # installed version
Memory operations:
open-memex add "This repo uses better-sqlite3" --type fact
open-memex search "auth flow"
open-memex search "auth flow" --explain # show FTS expression, scores, lifecycle-hidden counts
open-memex list --scope project
open-memex list --scope both # each scope's newest under its own header
open-memex list --include all # audit view: superseded versions, retracted, archived
open-memex supersede <id> "Updated content"
open-memex status <id> deprecated
open-memex forget <id>
open-memex forget <id> --soft # hide instead of delete (retracted; one-way)
open-memex inventory # everything remembered, as readable text
open-memex inventory --format json # the same data, for agents
open-memex inventory --format html # the same data as a local page (writes <data dir>/inventory.html)
# Personal + current project, outbox drafts in their own section, hidden
# history counted. Refuses to write a personal-bearing report inside a
# git working tree unless you pass --allow-personal.
# `list` numbers every entry in one listing and says how many it left out.
Team review workflow (two homes, one per stage):
Project drafts live in the appdata outbox (git-invisible, branch-independent);
only drafts you approve move into <repo>/.ai/open-memex/, where they follow
branches and PRs. Nothing moves without you naming it. In an AI chat with the
MCP server connected, just say "sync memory" (or "同步记忆") — the agent
runs the status check, summarizes the outbox drafts, and asks which ones to
sync. The server also tells the agent on its own: at session start the
handshake reports how many drafts are waiting, and every memory-changing tool
result carries the current count when it is non-zero.
open-memex sync-status
# show when the index was last synced (and what triggered it), the outbox
# (pending sync), the repo review states
# (draft / proposed / approved / published / rejected),
# and any uncommitted repo memory files.
open-memex submit <id...> [--branch <name>] [--base <branch>]
# move your named drafts into .ai/open-memex/ as "proposed":
# copies, flips review_state, local git commit ON THE CURRENT BRANCH.
# Never creates a branch on its own — branch creation is your call
# (or the agent's, only with your explicit approval for the full chain).
# All-or-nothing; conflicts (same id, different content) abort cleanly.
# Prints the push + gh pr commands; an agent holding your Yes carries
# through push/PR itself. --branch <name> creates the branch first
# (agent full-chain path). Default PR base is the current branch (memory
# PRs stack onto your working branch); --base redirects it to main or
# wherever you review.
open-memex pr-status [--apply]
# read the branch's GitHub PR and map its state onto each in-repo memory:
# merged PR → published, PR approval → approved (approved_by = reviewer),
# changes-requested → suggestion only. Report by default; --apply performs
# the mapped transitions locally (no push).
open-memex pull
# pull shared memories from the git remote: fetch + fast-forward ONLY.
# A diverged branch fails with a clear message — open-memex never
# force-merges; resolve it by hand, then pull again. On success the
# local index re-syncs. Pulls are explicit by default; set
# `open-memex config set sync.autoPull true` for a best-effort pull
# at MCP session start (a failed pull never blocks the session).
open-memex push
# push the current branch (with its submitted memories) to the git remote.
# Explicit only — open-memex never pushes on its own.
open-memex export [--scope project|personal|both] [--type T] [--tag t] [--all] [-o <file>]
# bundle memories into a portable .tar.gz (markdown + manifest.json) for
# moving to another machine or another app. Excludes visibility:private
# memories by default; --all / -a includes everything (full migration).
open-memex import <bundle.tar.gz> [--dry-run]
# restore a bundle: personal memories go to the personal dir; project
# memories are re-keyed to the current project and land in the outbox as
# drafts. Identical ids are skipped; conflicting ids are reported,
# never overwritten.
open-memex distill-agents [--scope project|personal] [--type t1,t2] [--limit N] [-o <file>]
# propose an AGENTS.md snippet distilled from project memories
# (decisions, constraints, lessons, gotchas, howtos). Prints markdown;
# -o writes it to a file. You review and merge by hand — open-memex
# never rewrites your AGENTS.md on its own. The snippet ends with a
# "memory hygiene" section so agents reading AGENTS.md learn to propose
# distilled captures when a task ends.
open-memex propose <id...> --to project [--local-approve]
# propose one or several personal memories at once (one branch, one PR);
# each is copied with its own new id. All-or-nothing: a bad id aborts the
# whole batch, never a half-proposed one.
# copy a personal memory into the project scope as a review candidate
# (never moves — the personal original stays). Result lands in the outbox;
# run sync-status / submit when you're ready to put it in the repo.
open-memex promote <id> [--reject] [--resubmit] [--note "..."] [--by NAME]
# advance one step: proposed → approved → published (or reject with a note).
# Every transition is appended to the memory's review_history (who/when/why).
# A rejection never deletes the file — your call: accept it (close the PR,
# delete the branch), revise + --resubmit for another round, or keep it as
# a [rejected] record.
open-memex resolve [id-or-path]
# list conflicted memory files, or field-level 3-way merge one of them.
# Semantic conflicts are reported, never auto-resolved.
Whoever tends the shared memory follows the curator convention —
docs/CURATOR.md: what to approve, what to send back, and the hygiene
rules that keep shared memory from rotting.
Maintenance:
open-memex where # show storage + config paths
open-memex scopes # list project scopes with memory counts
open-memex reindex # rebuild the SQLite index from markdown
open-memex audit # memory health: duplicate pairs, stale memories, broken chains
open-memex migrate --to-v2 [--dry-run] # v1 data → v2 (renames user scope to personal)
The CLI runs under Node 22. From a source checkout it uses the built-in
experimental TypeScript loader (no build step); the published npm package ships
pre-compiled JS (npm run build at publish time). From a source checkout,
prefix every command with node --experimental-strip-types src/cli.ts (or
npm run cli -- <command> for simple cases — npm swallows unknown --flag
args, so prefer direct node).
The same memory tools over the Model Context Protocol, via a stdio server — no host-specific plugin needed. Any MCP client can use open-memex.
open-memex mcp # after a global install
npx -y open-memex mcp # no install needed
The project scope is resolved from the process working directory, so configure
the server with cwd set to your project root (init handles this for you).
Note: MCP is request/response — it gives the agent tools, not the opencode plugin's automatic keyword capture or first-turn injection. Proactive memory use depends on the agent's instructions: the server sends session-start guidance in the MCP handshake
instructions(including the live outbox draft count at session start, plus the pending count appended to memory-changing tool results when non-zero), andinitwrites the fuller version into the editor's instruction files. Both are advisory — no MCP consumer offers a hard session-start hook.
user;
migrate --to-v2 renames it.)See docs/SCOPES.md for the full scope model: key derivation, migration, visibility, reserved names. The concept guide walks through the mental model end to end.
Every command dies with no output, or the process crashes (exit 139,
0xC0000005, "Segmentation fault").
Your Node is older than 22.14 and the bundled SQLite driver cannot load on
it. better-sqlite3 13 is compiled against Node-API 10, which Node only gained
in 22.14.0; on anything older require() succeeds and then the first database
open segfaults the process with no diagnostic. open-memex now refuses to load
the driver and says so, but anything already crashing was almost certainly this.
Check with node -v, then either upgrade Node (nvm install 22.14 && nvm use 22.14, or any current 22.x/24.x) or pin the driver down with npm install better-sqlite3@^12.11.1. open-memex doctor reports both the Node floor and a
live driver probe. Known upstream: WiseLibs/better-sqlite3#1514.
open-memex is not recognized / command not found.
A global npm install -g puts the open-memex launcher in npm's global bin
folder. If your terminal can't find it, that folder isn't on your PATH:
npm config get prefix
open-memex.cmd) sits directly in that folder,
e.g. C:\Users\<you>\AppData\Roaming\npm<prefix>/bin, e.g. /usr/local/bin or
~/.nvm/versions/node/v22.x.x/binPATH:
Path → restart
the terminal. Verify with where open-memex.export PATH="$(npm prefix -g)/bin:$PATH" to
~/.zshrc (or ~/.bashrc), restart the shell, verify with
command -v open-memex.PATH? Use the npx form —
npx -y open-memex <command> resolves the package itself and needs no
PATH changes.EBUSY / EPERM on better_sqlite3.node (Windows).
On Windows a loaded DLL is locked: if the open-memex MCP server is running
(VS Code MCP panel, Cursor, etc.), npm install -g open-memex cannot replace
better_sqlite3.node and fails with EBUSY / EPERM. Stop the MCP server
first (or quit the editor), then re-run the install. If it still fails, delete
node_modules/open-memex and any node_modules/.open-memex-* temp folders
under your global npm root and install again.
init says it left a config file untouched.
Your editor config has comments (JSONC) or invalid JSON, and open-memex never
rewrites files it can't parse safely. init printed the exact snippet to add
by hand — paste it in, and you're done. The same applies to the opencode
config: if it has comments, add the "plugin" line manually.
Something's off — run open-memex doctor.
Checks the Node version, config source, scope resolution for the current
directory, and storage writability; verifies VS Code hasn't disabled MCP;
then boots a real MCP server and runs initialize + tools/list against
it — all eleven tools must show up. It also reports pre-rename my-o-memory
leftovers if any editor config still references the old package name.
Do I need git?
No. Capture and recall work in any folder — without a git repo the project
scope simply keys off the folder path. Git is only needed for the team
workflow (submit / PR review), which is optional.
I use several editors. Do they really share one memory? Yes — on the same machine. Every wired editor reads and writes the same local memory; see the capability matrix for what each editor gets. A decision captured in VS Code is respected in opencode.
I work on two computers (office + home). Does memory sync?
Not automatically — memory is per-machine by design, and your personal scope
never leaves the machine it was created on. To move memory manually, use
open-memex export on one machine and open-memex import on the other.
Project memories shared through Git (Team workflow) travel with the repo, so
cloning the repo on the second machine brings the published project memories
along — your personal ones stay behind, on purpose.
Is it really free? Do I need an account? Free and open source (Apache-2.0). No account, no sign-up, no telemetry, no cloud calls. If it can't phone home, there's nothing to phone home to: the only network open-memex ever touches is your own git remote, when you explicitly push.
I accidentally pasted a secret into a memory. What now?
open-memex search "<part of it>" to find the memory, then
open-memex forget <id> to delete it. To prevent it next time, wrap sensitive
text in <private>…</private> (stripped before saving) — recognized API keys
and tokens are also masked automatically. Preview any message safely with
open-memex capture --dry-run "…".
Do I need to run init for every project?
No. The data layer needs nothing — the project scope is derived automatically
from your cwd's git remote or path, so memories are namespaced per project
with zero setup. The editor wiring is one open-memex init per machine
(user-level wherever the editor supports it). Run it again only after
upgrading (--force) or if you switch editors.
Does opencode need init?
Two paths. Recommended: open-memex init --client opencode --global — it
merges the native open-memex plugin into ~/.config/opencode/opencode.json
for you. One-time setup, applies to all projects, and additionally enables
keyword auto-capture and first-turn memory injection. Prefer to do it by hand?
Add "plugin": ["file:///absolute/path/to/open-memex/src/index.ts"] (the
installed package's path) to that file instead. As a plain MCP consumer:
open-memex init --client opencode writes a project-level opencode.jsonc
(no hooks). If your user-level config has comments, init leaves it
untouched and prints the manual step.
VS Code — run init once, or per project?
Once. Plain open-memex init auto-detects VS Code and writes the MCP server
entry to VS Code's user-level mcp.json (%APPDATA%/Code/User/mcp.json on
Windows, ~/Library/Application Support/Code/User/mcp.json on macOS,
~/.config/Code/User/mcp.json on Linux), so the server starts in every
project. A per-project .vscode/mcp.json still wins when present, and the
entry keeps cwd=${workspaceFolder} so project-scope resolution keeps
working per window. If your user-level mcp.json has comments (VS Code
accepts JSONC), init leaves it alone and prints the exact snippet to add by
hand. An empty file is treated as blank and written to directly.
How do I remove the editor wiring?
open-memex uninstall reverses init: it removes the MCP server entry, the
opencode plugin line, the Agent Skill directory, and the open-memex section of
the Copilot instructions. With no --client it cleans up every detected
editor; --global limits the cleanup to user-level wiring. Your memories are
never touched.
I upgraded Node, or switched versions with nvm. Do I need to reinstall?
The package itself doesn't care: its SQLite driver is a Node-API prebuild, so
it loads on any supported Node (≥ 22.14) with no recompiling, and your
memories live outside the install. But version managers (nvm and friends)
keep a separate global package folder per Node version, so after a switch
open-memex may simply be "not found". Run npm install -g open-memex once
under the new Node, then open-memex doctor to confirm the driver loads.
open-memex is stable and in daily use; the current stable line is published on
npm as latest, with alpha builds for testers. Release history lives in
GitHub Releases; design
decisions are recorded in the append-only log at
docs/V2-DESIGN.md.
On the horizon (no version promises): native agent plugins for more editors as enhancements over the same MCP tools; local embeddings as an opt-in experiment (no model is ever downloaded without asking); an org layer only if real multi-repo sharing, ACL, or compliance needs demand it.
Local-first memory for AI coding agents — Markdown + SQLite FTS5, shared across editors via MCP.
{ "mcpServers": { "io.github.stoneskin-open-memex": { "command": "npx", "args": [ "-y", "[email protected]" ] } }}Инструменты
Списка инструментов пока нет. У удалённых серверов он появляется после первой проверки состояния.
FAQ
Скопируйте на этой странице конфигурацию stdio для Cursor, Claude Desktop, Claude Code или VS Code. Она использует установку издателя, а не прокси PlugMCP.
В этой записи не указано обязательных переменных окружения.
Open Memex работает локально через stdio.
Последняя проверка: 2026-11-15. Local-first memory for AI coding agents — Markdown + SQLite FTS5, shared across editors via MCP.