Monomem

Shared memory for your AI coding agents that records who wrote each note and holds suspicious writes for your review.

npx monomem setup

Needs Node 22.16 or newer (check with node -v). On an older Node, use Docker.

*Recorded from a real run against a throwaway store (transcript): a write containing an injected instruction is held and never reaches the other agent's search, then rejected from the real dashboard. The two terminal panes are drawn from the real REST responses; the dashboard is a screen recording. Nothing sped up.*

• One memory for all your assistants. Tell Claude Code something once, and Cursor, Codex and Gemini CLI can read it too. It's one SQLite file on your own machine: no cloud, no API keys, no hidden model calls. Already use another memory tool? See how it compares.
• Knows who wrote it. Every note records its writer. For callers that use a token, the server stamps the name; for local apps it is a label from that app's config file, so it tells your apps apart but is not proof.
• Holds suspicious writes. A write that looks like an instruction planted to steer your other assistants is held until you approve it, and monomem approve-first --all on makes every agent write wait for your OK. The check is pattern matching, so it doesn't catch everything. An agent that can run shell commands, like Claude Code, can run the monomem command itself and its writes are not held, so this protects you from tools that only have the memory connection (see SECURITY.md).

Quickstart

Requires Node.js 22.16 or newer (22.16+ or 24 LTS). Check with node -v. Can't

upgrade? Use Docker instead.

Install in 60 seconds

npx monomem setup

npx monomem drill # replays 20 known poisoning attacks on a copy of your store

setup finds Claude Code, Claude Desktop, Cursor, Codex, Gemini CLI, Muse, VS Code and Zed on this computer, shows you in plain words what it will do and the exact lines it will change, saves a backup of each file, and writes only after you type y. Then it writes a first test note, reads it back, runs monomem doctor and tells you how to check it inside Claude Code (type /mcp). To look first: npx monomem setup --dry-run. To go back: monomem setup --undo. It changes only the Monomem entry; your other servers and settings stay as they are. Step by step, with troubleshooting: docs/live-claude-code.md.

Already have notes in Claude Code? monomem import --claude --dry-run shows what could be brought in from your CLAUDE.md files and Claude Code's auto memory (secrets are skipped, nothing leaves your computer). Coming from claude-mem, mem0, basic-memory or the official MCP memory server? monomem import --from claude-mem --dry-run (or mem0 --path export.json, basic-memory, mcp-memory); see docs/switching.md for the import and a clean uninstall of the old tool.

In Claude Code you can also install Monomem as a plugin instead of running setup (what the plugin does and does not do):

/plugin marketplace add calasdan-sketch/monomem

/plugin install monomem@monomem

Anything else that speaks MCP or HTTP can connect too, including a browser on your phone if you expose the HTTP endpoint yourself (INFRA.md covers tunnels and phone or web access).

The manual way, if you prefer:

npm i -g monomem                           # 1. install

claude mcp add monomem -- monomem mcp # 2. wire it into Claude Code (stdio) monomem doctor # 3. verify Node, database, token

Then, in Claude, say "remember that my staging server is on port 8443", and in a fresh chat ask "what port is my staging server on?". Step 4, only if you want the dashboard, REST API and MCP-over-HTTP (the curl examples below need it): monomem start.

No global install: claude mcp add monomem -- npx -y monomem mcp. monomem init prints the config for Claude Desktop / Cursor / Copilot; INSTALL.md has every client.

monomem start serves the dashboard and REST API on :8790 and MCP-over-HTTP on :8791 (bound to 127.0.0.1). To reach it from your phone or claude.ai, put an authenticated tunnel (Cloudflare Tunnel + Access, Tailscale, or your own TLS proxy) in front of :8791 — see INFRA.md.

Plain REST works too once monomem start is running (the token is in ~/.monomem/.token):

TOKEN=$(cat ~/.monomem/.token)

curl -X POST localhost:8790/notes -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{"title":"Deploy day","body":"Shipped v1.1"}' curl -H "Authorization: Bearer $TOKEN" "localhost:8790/search?q=deploy"

Where your data lives

Everything (database, token, scoped tokens, spaces config) lives in ~/.monomem (Windows: %USERPROFILE%\.monomem), outside the installed package, so npm update and npx cache cleanups never touch it. Set MONOMEM_HOME to put it elsewhere, or MONOMEM_DB_PATH for just the database. On macOS/Linux the folder is owner-only (0700, files 0600). A from-source git checkout that already has ./data/state.db keeps using it. monomem doctor shows which directory is in use. Upgrading or moving from another tool: docs/upgrading.md, docs/switching.md.

Docker

cp .env.example .env     # set MONOMEM_TOKEN (openssl rand -hex 32)

docker compose up -d # dashboard at http://localhost:8790

Backups & restore

monomem backup --out ~/om-backup     # consistent hot copy; safe while the server runs

(The attestation signing key .attest-key is not copied; see docs/trust.md.)

monomem backup writes state.db (via SQLite VACUUM INTO) plus, if at-rest encryption is on, a copy of the .key file. Keep the key apart from the backup: a backup without its key is unreadable, and one stored next to it is not encrypted. See INFRA.md. The JSON route (admin token) also works:

TOKEN=$(cat ~/.monomem/.token)

curl -H "Authorization: Bearer $TOKEN" localhost:8790/export > backup.json # or: monomem export --format json --out backup.json curl -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ --data-binary @backup.json localhost:8790/import # admin scope only

• Restore into an empty store. POST /import does not de-duplicate: importing a backup into a store that already holds those notes creates duplicates.
• Exports carry edit history. Each note exports with its latest body *plus* the earlier versions an edit replaced (history), so export size tracks how often you rewrote a note, not just your note count. ?history=0 / --no-history leaves them out. An export with history can hold text someone removed on purpose — treat it like the database (see SECURITY.md). The change feed's per-edit log is separate: metadata only (titles, no bodies), pruned after 90 days, and never part of a JSON backup.
• Exports stream. GET /export and monomem export --format json page through the store and write as they go, so peak memory is one page (500 notes) regardless of store size — a multi-month store dumps in one pass.
• Restores keep the history that exists. created_at, updated_at, source and the rev counter all survive the round trip (a note at rev 26 stays at rev 26, so if_rev guards and the change feed stay accurate). Imports over 200 notes land in seconds and defer the O(n²) similarity-graph rebuild — the response says so and search works immediately; run monomem rebuild-edges when you want neighbor ranking back. Restored notes are re-embedded automatically when semantic search is enabled.
• Markdown (one file per note, git-friendly) is a separate path: monomem export --format md --dir ~/memory — see docs/file-sync.md.

Check and explain your memory

Notes keep their earlier versions (up to 20 per note by default), so replacing or editing a note can be undone; deleting one is permanent, by design. Local apps are marked stdio: (stdio:cursor, stdio:claude-code, ...), a name the app's config file declares, not a login; give each app its own token when the writer must be authenticated. Benchmarks back these claims.

Agents that record decisions as facts (deploy_target, package_manager ...) get an exact match: a different value from another writer is flagged on write and, at session start, shown as a short "writers disagree" line. health opens your store (an older database file is upgraded once) and writes one small row noting how long the audit log was, so the next run can see lines removed. These are local commands: drill and health run the drill with embeddings forced off, so they make no embedding call (and no call to any other machine; the drill talks only to a temporary server on 127.0.0.1) even when MONOMEM_EMBEDDINGS and a remote MONOMEM_EMBED_URL are set (health only reports that such a URL is configured).

Automatic memory

Monomem can also remember what your coding agent *does*, without anyone writing a note. Setup can wire this for Claude Code, Codex, Gemini CLI and Muse (whichever it finds on this computer). The Codex and Gemini CLI hooks follow those tools' published hook documentation (Codex asks you to approve them once with /hooks); Muse does not publish its hook fields, so capture there is t