Skip to content

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.

the prompt
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.

Download Linux binary

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

product overview →

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.

  1. 01

    Install

    curl -fsSL "https://www.whitemagic.dev/install.sh?ref=guide-step" | sh

    Linux 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.

    install details and downloads

  2. 02

    Verify readiness

    wm grimoire

    Checks 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.

  3. 03

    Wire your clients

    wm connect --write

    wm 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.

  4. 04

    Load your data

    wm ingest --source <folder> --dry-run

    Walk a folder of notes or transcripts into a local galaxy. Redaction, skip policy, and the resume ledger are in Load your data below.

    load your data

  5. 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 statusHuman-facing health summary: store, counts, index, backup, and update state.
  • wm statsResource usage and brain-wave state; --week shows the last seven daily rollups.
  • wm reportWrites a sanitized local support bundle (report.json + README.txt). Read-only; nothing is transmitted.
  • wm backupCopies 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 checkChecks 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-run

Reports 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 --redact

Chunks 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.

ask your AI to ingest
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.

2 · Connect it to this clientbash
claude mcp add whitemagic -- wm serve

Run 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.

Run once, then ask your client what it remembers.