setup guide
Set up WhiteMagic.
Install once, then ask your AI to wire it — or follow the first-run path and the per-client configs yourself. Memory and sessions stay on your machine; the server speaks local MCP over stdio.
fastest path
Ask your AI to set it up.
Paste one prompt into any coding agent that can run shell commands: it installs WhiteMagic, wires your MCP clients, and reports the readiness check back to you.
Find the WhiteMagic MCP server (whitemagic.dev; official MCP registry id io.github.lbailey94/whitemagic-mcp).
Install it with the one-line installer:
curl -fsSL "https://www.whitemagic.dev/install.sh?ref=ask-ai" | sh
Then run `wm connect --write` to wire my clients and `wm grimoire` to verify.
Report the readiness output and a test memory.Who can do this
- ·Works in most clients that can run shell commands — Claude Code, Codex CLI, opencode, and similar terminal-capable agents can carry the prompt out end to end.
- ·Clients that can browse the official MCP registry can search for io.github.lbailey94/whitemagic-mcp and add it directly, with no shell step.
- ·Terminal-native path, one client at a time: wm setup <client> (claude · cursor · windsurf · codex · opencode) shows the change first; add --write to apply it with a timestamped backup.
- ·No terminal at all? Paste the matching config by hand from the client tabs below — the generic mcpServers entry works in most clients.
- ·Prefer not to install a binary? The npm launcher npx whitemagic-mcp serve runs the same server.
The per-client tabs below remain the manual fallback; where a client ships its own add command, that one-liner also works (Claude Code: claude mcp add whitemagic -- wm serve).
install
Install WhiteMagic.
One line on Linux x86-64; macOS and Windows binaries are published but not yet install-gated. No account, no admin rights, and the store stays on your machine.
curl -fsSL "https://www.whitemagic.dev/install.sh?ref=guide-a" | sh
No sudo required · Runs in user space (~25 MB) · glibc & musl
v9.2.1 · released September 20, 2026 · 15 crates · npm · Docker · MCP registry · MIT
No account · Memory and sessions stay on your machine · No usage telemetry off-device by default
first run
First run, step by step.
Install → verify readiness → wire your clients → load data → first session. Add --write only when you want changes applied.
- 01
Install
curl -fsSL "https://www.whitemagic.dev/install.sh?ref=guide-step" | shLinux x86-64 is install-gated; macOS and Windows binaries are published, not yet install-gated. No account, no admin rights — the binary lands in ~/.local/bin.
- 02
Verify readiness
wm grimoireChecks the host, verifies the substrate and the release, configures detected agents (add --write to apply), calibrates memory, and demonstrates restart continuity. It reports five separate readiness facts instead of one green badge; --json for machines.
- 03
Wire your clients
wm connect --writewm connect alone is a dry run that lists every detected client and the exact change; --write applies them (timestamped backups first) and finishes with an end-to-end connection test — initialize + tools/list against a real server.
- 04
Load your data
wm ingest --source <folder> --dry-runWalk a folder of notes or transcripts into a local galaxy. Redaction, skip policy, and the resume ledger are in Load your data below.
- 05
Start a session, then resume
wm session start --title "first run"Record decisions as you work and recall them in the next session — over MCP (session.start · session.record · session.continuity) or from the terminal (wm session start · record · continuity). wm quickstart demonstrates a full stop/start on an isolated store; wm selftest runs the end-to-end invariant check on a throwaway one.
keep it healthy
wm status— Human-facing health summary: store, counts, index, backup, and update state.wm stats— Resource usage and brain-wave state; --week shows the last seven daily rollups.wm report— Writes a sanitized local support bundle (report.json + README.txt). Read-only; nothing is transmitted.wm backup— Copies the full store (LMDB + indexes + all JSON state) into a timestamped directory with a SHA256SUMS manifest. Stop the server first; restore with wm restore --backup <dir>.wm update check— Checks for a newer signed release — notify-only, no installation.
The store lives at ~/.local/share/whitemagic by default; --store <path> or a per-project client config points a server at another one. One store per project, and WM_PROJECT=<name> names the project in the MCP handshake, so an agent can confirm its scope before acting.
Uninstall: remove the wm binary and the store directory. That removes only those locations — backups, exports, replicas, and other project stores remain, and deletion is not secure erasure. Inventory the copies first.
load your data
Bring your notes, docs, and transcripts.
wm ingest walks a folder into a galaxy on your disk — chunked, ledgered, and resumable. Nothing is uploaded; files stay on your machine.
wm ingest reads files from your disk, chunks them, and writes them into a store with provenance tags. It is idempotent: a per-file SHA-256 ledger at <store>/ingest_ledger.jsonl means re-runs are no-ops for unchanged files, and an interrupted ingest resumes by running the same command again.
Dry run first
wm ingest --source ~/Notes --galaxy research --redact --dry-runReports what would be ingested and skipped (with reasons), without writing anything or creating the store.
Then ingest for real
wm ingest --source ~/Notes --galaxy research --redactChunks land in the research galaxy with provenance tags; credential-shaped spans are replaced before storage.
ingest flags
- --source <dir>
- Folder to walk (required). The walk is recursive and skips build/VCS directories (.git, node_modules, target, .next, …).
- --galaxy <name>
- Target galaxy. Default: research for documents, sessions for transcripts.
- --redact
- Scrub credential-shaped spans (PEM keys, prefixed tokens, assignment values) and ingest the file instead of skipping it.
- --dry-run
- Report without writing or creating the store.
- --limit <n>
- Only the first N files in walk order.
- --include-credential-files
- Ingest files whose name looks credential-bearing (secrets.txt); requires --redact, so content is scrubbed before storage.
- --store <path> · --wait <n>
- Point at a specific store; wait up to N seconds for a busy (live-server) store before failing.
What is skipped, by default
Credential-named files are never ingested: .env*, .pem, .key, .p12/.pfx/.crt, id_rsa, id_ed25519, id_ecdsa, credentials, secrets, password, passwd, token. Only md, markdown, txt, jsonl, ndjson, and llms files are read; binaries, media, archives, PDF/Office documents, lock/log files, and build artifacts are skipped, and files over 64 MB are reported and skipped. --include-credential-files is the explicit override, and it is bound to --redact — never a raw-secret door.
Ledgered and resumable
Every ingested file's SHA-256 is recorded at <store>/ingest_ledger.jsonl. Unchanged files are no-ops on re-runs; changed files replace their chunks. Long ingests can be stopped and resumed, and dry runs show the whole plan first.
Scan ~/Notes recursively into a research galaxy with `wm ingest --source ~/Notes --galaxy research --redact`, redacting credential-shaped spans. Dry-run first, then run it for real, and report the files ingested and skipped. Everything stays on this machine.Beyond folders
- ·Direct memories — memory.create for one memory, memory.batch_create for a batch, session.record for conversation turns, all via the wm meta-tool. Tag cross-store imports with project:<name> so their origin stays attributable.
- ·Move galaxies — galaxy.export writes a galaxy as JSON; galaxy.import loads it into another store or machine.
- ·Per-project stores — one store per project. Point the project's client config at its own directory and set WM_PROJECT=<name> so the handshake names the scope.
per-client setup
Pick your client.
Every config below was verified against the client's own documentation. If your client is not listed, the generic MCP entry usually works as-is.
Register WhiteMagic as a local MCP server. Sessions can then resume where the last one stopped — file checkpoints, decisions, and next steps survive restarts.
claude mcp add whitemagic -- wm serveRun this once in your terminal; Claude Code stores the server entry for you. Claude Code MCP docs ↗
Or let WhiteMagic patch it: run wm setup claude to see the exact change first; add --write to apply it (timestamped backup). JSONC/TOML configs are print-only.
WhiteMagic runs as a local stdio MCP server. Cursor can then recall earlier sessions, decisions, and project state without pasting context back in.
{
"mcpServers": {
"whitemagic": {
"command": "wm",
"args": ["serve"]
}
}
}Project config at .cursor/mcp.json, or global ~/.cursor/mcp.json (Cursor Settings → Features → MCP also edits this file). Cursor MCP docs ↗
Or let WhiteMagic patch it: run wm setup cursor to see the exact change first; add --write to apply it (timestamped backup). JSONC/TOML configs are print-only.
Codex stores MCP servers in ~/.codex/config.toml. Add WhiteMagic as a stdio server and sessions can resume with prior state.
[mcp_servers.whitemagic]
command = "wm"
args = ["serve"]~/.codex/config.toml (project scope: .codex/config.toml in a trusted project). Codex CLI MCP docs ↗
Or let WhiteMagic patch it: run wm setup codex to see the exact change first; add --write to apply it (timestamped backup). JSONC/TOML configs are print-only.
Devin Desktop is the renamed Windsurf editor. It reads MCP servers from mcp_config.json — add WhiteMagic once and the agent can recall earlier sessions locally.
{
"mcpServers": {
"whitemagic": {
"command": "wm",
"args": ["serve"]
}
}
}~/.codeium/mcp_config.json (legacy Cascade configs at ~/.codeium/windsurf/mcp_config.json are still read), or Settings → Cascade → MCP Servers. Devin Desktop MCP docs ↗
Or let WhiteMagic patch it: run wm setup windsurf to see the exact change first; add --write to apply it (timestamped backup). JSONC/TOML configs are print-only.
Antigravity reads MCP servers from a global mcp_config.json. Add WhiteMagic once and the agent can recall earlier work across sessions — all on your machine.
{
"mcpServers": {
"whitemagic": {
"command": "wm",
"args": ["serve"]
}
}
}~/.gemini/config/mcp_config.json (global; applicable to all sessions). Antigravity MCP docs ↗
VS Code configures MCP servers in mcp.json. Add WhiteMagic as a stdio server and the agent can recall earlier sessions.
{
"servers": {
"whitemagic": {
"type": "stdio",
"command": "wm",
"args": ["serve"]
}
}
}.vscode/mcp.json in the workspace, or your user-profile MCP config (Command Palette → MCP: Open User Configuration). VS Code MCP docs ↗
opencode takes MCP servers in opencode.json. WhiteMagic runs locally over stdio and keeps session continuity between opencode runs.
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"whitemagic": {
"type": "local",
"command": ["wm", "serve"],
"enabled": true
}
}
}opencode.json (project) or ~/.config/opencode/opencode.json (global), under the mcp key. opencode MCP docs ↗
Or let WhiteMagic patch it: run wm setup opencode to see the exact change first; add --write to apply it (timestamped backup). JSONC/TOML configs are print-only.
Add WhiteMagic to the desktop app's MCP servers. Conversations can then pick up earlier threads and remembered context.
{
"mcpServers": {
"whitemagic": {
"command": "wm",
"args": ["serve"]
}
}
}claude_desktop_config.json — macOS: ~/Library/Application Support/Claude/, Linux: ~/.config/Claude/, Windows: %APPDATA%\Claude\. Claude Desktop MCP docs ↗
WhiteMagic is fully client-agnostic: if it speaks MCP, it works. The client runs wm serve and gets memory tools; your memory lives on your disk, so switching editors or models never loses history. Most clients accept the mcpServers entry below; the tabs above cover the exact file each listed client reads.
{
"mcpServers": {
"whitemagic": {
"command": "wm",
"args": ["serve"]
}
}
}Wherever your client stores MCP server entries — if it accepts the mcpServers shape, this entry works as-is. Any MCP client MCP docs ↗
Run once, then ask your client what it remembers.