Monomind is an open-source CLI and MCP server that plugs into Claude Code, OpenCode, Antigravity, Kimi Code, and Codex via the standard Model Context Protocol. It adds capabilities these assistants don't ship with out of the box:
CLI engine for Monomind — an open-source MCP server for Claude Code, OpenCode, Antigravity, Kimi Code, and Codex, with a codebase knowledge graph (tree-sitter + SQLite), persistent memory, multi-agent task coordination, and session hooks. Apache 2.0 licen
2026-11-14
星數
—
工具
—
可用率
—
Codebase knowledge graph — tree-sitter parses your code into a SQLite-backed graph of files, functions, classes, and their relationships. Query imports, callers, and blast radius before making changes.
Persistent memory — a JSON pattern store with episodic recall that survives across sessions. Agents and orgs share context without re-prompting.
Multi-agent coordination — in-session, spawn ad-hoc agent teams via Claude Code's Task tool; for persistent background work, monomind org run starts a real SDK-backed daemon with policy-gated role agents and a live dashboard. Roles can run on Claude or on other installed coding agents (see Agent runtimes).
Agents, skills and picking — ships 83 pickable agents, 82 skills and 560 Org skills, and you add your own as Markdown files. One index of all of them ranks the best fit for each task, by keyword or, when you configure one, with a Jev decision model (MONOMIND_JEV_URL for a self-hosted OpenJev server). The prompt hook puts the result in Claude's context as a [PICK] line, and monomind pick or the pick MCP tool return it on request. See Agents & Skills and Routing.
Reusable slash commands — 40 workflows (plan, execute, review, debug, release, research, worktree) available as /mastermind:* commands inside Claude Code.
npm install -g monomind # Apache 2.0 licensed; runs locally and keeps its state locally
cd your-project && monomind init
claude mcp add monomind -- npx -y monomind@latest mcp start
monomind init installs the core pack: the everyday /mastermind:* workflows (plan, execute, review, debug, do, …), 20 core agents and the memory, GitHub and browser toolkits, small enough that Claude Code shows every description. Everything else ships as opt-in packs (orgs, org-admin, swarm, github, testing, specialists, business, extras): pick them with monomind init --packs orgs,github or --all-packs, or add one later with monomind packs add <pack>. monomind packs list shows each pack and how much of the listing it uses.
Org skills come from the bundled library, from your own Markdown files, and from imports: monomind org skills import pulls MIT or Apache-2.0 skills from another repo and records the licence, source and commit on each one (the library includes a bundle from anthropics/knowledge-work-plugins). For skills you want reviewed before roles can use them, monomind catalog stages, approves and activates them under a policy (Catalog).
monomind init sets up only the coding systems installed on your machine: Claude Code, Antigravity, OpenCode, Kimi Code and Codex each count when their CLI is on your PATH or their config directory is in your home, and Claude Code is the default when none is found. A re-run also keeps every system the project already has. It prints what it detected; --platforms claude,codex names the systems yourself and --all-platforms writes all five. It never runs npm install or edits your package.json: the code graph uses the @monoes/monograph copy bundled with the CLI.
Two things init leaves off unless you ask: Claude Code's experimental Agent Teams (--agent-teams writes CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1; nothing in Monomind reads it) and dashboard auto-start at every session (--dashboard). monomind doctor reports a leftover Agent Teams flag from an older init, and monomind init upgrade --settings removes it (a backup stays in settings.json.bak-agent-teams).
init writes .mcp.json (and the other systems' configs) pinned to the installed version; --pin latest keeps the floating monomind@latest, and monomind init --force re-pins after an upgrade.
Nothing extra to do when Antigravity is installed (agy/gemini on PATH or ~/.gemini): monomind init then writes GEMINI.md, .gemini/rules/, and a live status bar wired through .gemini/settings.json. The MCP server config is shared with Claude Code (.mcp.json). See Antigravity guide →.
monomind init --target opencode # initialize only OpenCode
monomind init sets up the coding systems it detects on your machine (CLI on PATH or config directory in your home), OpenCode included when it is installed. --target opencode initializes only OpenCode; the legacy --opencode flag remains an alias. You get the same MCP tools, agent roster, commands, skills, and security gates, plus a /monomind-status command. See OpenCode guide →.
monomind init --target kimicode # initialize only Kimi Code
monomind init includes Kimi Code when it is installed (kimi on PATH or ~/.kimi). --target kimicode initializes only Kimi Code; the legacy --kimicode flag remains an alias. You get the same MCP tools, agent roster, skills, and commands (as project-level flow skills). Install the generated plugin once for /monomind:* slash commands and security gates: /plugins install ./.kimi-code/plugin. See Kimi Code guide →.
codex login
monomind init --codex
This emits a project-scoped .codex/config.toml that registers Monomind's MCP
server, plus AGENTS.md with Codex-specific guidance. Codex must trust the
project before it loads project-scoped configuration. To run persistent
Monomind organizations through Codex, set "runtime": "codex" in the org
definition.
Use monomind init --target codex (or --codex) to initialize only Codex. See Codex guide →.
Monomind runs locally and stores its state locally: memory, code graph, document index and org state, embedded by a local model. The AI tools it drives (Claude Code, Codex, OpenCode, Kimi Code, Antigravity, and org roles, whose model calls monomind makes itself when a role uses an AI-SDK provider) send your prompts and code to their model providers, including the memory and Second Brain excerpts injected into those prompts. Monomind itself also makes a few outbound calls: the one-time embedding model download, the first-use installs of the Claude SDK and (without an installed browser) Chrome, the npm update check, the Jev decision model if you configure one, and opt-in features; launching it through npx monomind@latest adds an npm registry lookup on every start, and opening the dashboard loads its scripts and fonts from public CDNs. See doc/privacy.md for the complete list of what's sent, when, and how to opt out of each.
Dependencies
Standard npm packages. A fresh npm install monomind (Linux x64) adds 263 packages and 938 MB of node_modules, most of it onnxruntime-node (548 MB, local embeddings) and onnxruntime-web (141 MB). Four packages run install scripts, and two of them download binaries: onnxruntime-node (CUDA libraries from NuGet on Linux x64; ONNXRUNTIME_NODE_INSTALL=skip skips them) and better-sqlite3 (a prebuilt addon from GitHub). Two heavy pieces are installed on first use instead, once, into ~/.monomind/deps and never into your project: the Claude Agent SDK with its Claude binary (about 300 MB, announced by a download notice before it starts, on the first Claude org role or agent exec --runtime claude), and Chrome for monomind browse (about 400 MB, only when no Chrome, Chromium or Edge is installed). MONOMIND_NO_AUTO_INSTALL=1 turns that off and prints the install command instead. Native addons: better-sqlite3 and onnxruntime-node; tree-sitter (web-tree-sitter) and sql.js are WASM. Full breakdown: doc/privacy.md.
Permissions
Registers as an MCP server — Claude Code controls what tools are available and prompts you before executing anything sensitive.
This is the headline feature.monomind org run starts a persistent, SDK-backed daemon that runs an autonomous agent organization — roles, hierarchy, policy-gated tool access, a live dashboard — until you stop it.
The idea
Every business function needs a team. Define the org once as a JSON file — goal, roles, who reports to whom, per-role tool/file/budget policy — then run it as a real background daemon backed by the Claude Agent SDK. It persists across sessions, streams live into the dashboard (monomind org run starts it unless MONOMIND_DASHBOARD_AUTOSTART=0), and can discover and message other Monomind orgs running on the same machine. The operator signs each definition before it runs, so editing an org file never grants a role new authority on its own.
flowchart TD
U(["You"])
DEF["org.json\nGoal + roles + policy"]
RUN["monomind org run\nStart SDK daemon"]
BOSS["Boss Agent\nAgent SDK session"]
W["Writer"]
S["SEO Specialist"]
R["Reviewer"]
DASH[("Dashboard\n:4242")]
XORG[("Other orgs\ncross-process")]
U --> DEF --> RUN --> BOSS
BOSS -->|spawns| W
BOSS -->|spawns| S
BOSS -->|spawns| R
RUN -->|forwards events| DASH
RUN <-.->|--cross-process| XORG
style BOSS fill:#00D2AA22,stroke:#00D2AA
style DASH fill:#F59E0B22,stroke:#F59E0B
style XORG fill:#8B5CF622,stroke:#8B5CF6
Run one
# .monomind/orgs/<name>.json defines the org: goal, roles, policy.
# See .monomind/orgs/sample-team.json in a fresh `monomind init` for a working example.
# Review and sign a definition once, as the operator (a run without a TTY refuses an unsigned org):
monomind org sign content-team
monomind org run content-team --task "Build and publish 3 blog posts per week"
# ✓ Boss agent (Claude Agent SDK session) spawns, reads the org goal,
# assigns work to role agents, coordinates until the task completes
# or you stop it. Every event streams into the dashboard above
# (log in with `monomind dashboard open`).
monomind org status content-team # runtime state (detects crashed daemons)
monomind org stop content-team # request a graceful stop
monomind org list # every org + roles, schedule, status
Observe, steer, and carry context between runs
monomind org logs content-team --follow # live event stream in the terminal
monomind org report content-team # outcome, per-role tokens vs budget, assets
monomind org questions content-team # what agents asked via ask_human
monomind org answer content-team q-123 "yes" # answer live or queued — no dashboard needed
monomind org create blog --template content-team --goal "3 posts/week" # scaffold from a template
monomind org validate blog # schema + structural checks before running
monomind org run blog --dry-run # preview each role's exact briefing
monomind org run blog -y --auto-approve org_complete # unattended: skip the cost prompt, let roles end the run
An org can also be split into sections: isolated sub-orgs, each with its own roles, budget and lifecycle, that share work only through documents. Sections are generally available and can run on a schedule. For long runs, the opt-in run_config.context surface adds typed task briefs, role notes, session caps with rotation digests and per-call context logging (context.jsonl). See Org Runtime Architecture.
Orgs carry context between runs: the coordinator records every run's outcome (org_complete), the next run is briefed on it, and all agents can query accumulated cross-run memory with org_recall — a scheduled org starts each cycle with what earlier cycles recorded instead of starting cold. Crashed agent sessions restart automatically with backoff.
What runs under the hood
What
How
OrgDaemon
Hosts one or more orgs in a single process; real Claude Agent SDK sessions per role, not simulated
PolicyEngine
Per-role gates on tool access, file read/write scope, web access, token budget — enforced, with a full audit trail. Opt-in sandbox settings add denyRead, denyExec and homeWriteAllow for a role's whole process tree
Dashboard
org run forwards every event to the control server on :4242 (found via .monomind/control.json). Start it by hand with monomind ui; the session-start hook starts it only if you ran monomind init --dashboard or set MONOMIND_DASHBOARD_AUTOSTART=1. The dashboard needs a login: monomind dashboard open prints a one-time link. There's no separate per-org dashboard process
Cross-process comms
--cross-process (default on) lets orgs on different monomind processes/projects discover and message each other
Scheduling
monomind org serve hosts orgs whose definition has a schedule field, running them on interval
The repo ships one worked example beyond the sample: config/orgs/release.json, an autonomous release org that verifies, versions, publishes and confirms a Monomind release, with a preflight that asks a human once for any missing access and runs unattended after that.
Note:/mastermind:runorg delegates directly to the Org Runtime daemon (the same path as monomind org run) — there is no boss agent, no monotask board, and no manual curl calls in this path. /mastermind:runorg converts legacy-format org config files with monomind org migrate before starting the daemon. New orgs should use monomind org run (or /mastermind:runorg) against a hand-authored .monomind/orgs/<name>.json.
🔌 Agent Runtimes
Org roles and monomind agent exec run on whichever coding agent you have installed, through the Agent Exec Protocol: one turn in, NDJSON events out, the same shape for every runtime.
monomind agent scan # which runtimes are installed (19 known: claude, codex, opencode, kimicode, kilo, qwen, grok, copilot, hermes, aider, …)
monomind agent models --runtime codex --json # a runtime's own model list
monomind agent test claude --json # smoke-test a runtime with one tiny turn
monomind agent exec --runtime codex --prompt "summarize ./README" --effort high
Flag
Purpose
--access scoped|read|full
Allow-list only (default), read-only, or unrestricted native tools. full is coder mode: it needs --cwd, refuses root, kills the whole process tree on stop or timeout, and writes an audit record per run. In an org, set policy.access: "full" on a role.
--sandbox <mode> / --sandbox-fallback
Use the vendor CLI's own sandbox; choose what happens when a runtime lacks the mode.
--effort off|low|medium|high|xhigh|max
Reasoning effort, mapped per runtime.
--settings none|user,project,local
Let Claude load your CLAUDE.md, skills, hooks and MCP servers.
--attach <file>
Send a file with the prompt (repeatable, up to 10, 20 MB each): Claude sees images and PDFs directly, Codex sees images, other runtimes get the file paths.
--claude-path <file|bundled>
Choose the Claude Code binary (also MONOMIND_CLAUDE_PATH or monomind config set claude.path).
In coder mode the model and effort you select win over CLAUDE_CODE_EFFORT_LEVEL in your settings, and a subagent launch that names a different model is refused. MONOMIND_CODER_MAX_AGENTS (default 40) and MONOMIND_CODER_MAX_REVIEW_AGENTS (default 12) cap how many subagents a turn may launch; 0 turns a cap off. Threat model: Coder mode security.
⚡ Looping Workflows
For code, the /mastermind:* workflows can loop instead of running once. Add --tillend to /mastermind:review, /mastermind:improve, /mastermind:debug and most other workflows (/mastermind:help lists them) to repeat until a round finds nothing left to do.
/mastermind:review --tillend # review → fix → verify until a round finds nothing
/mastermind:improve --repeat 3 the auth flow # exactly 3 improvement passes
/mastermind:plan add rate limiting # then /mastermind:execute the plan
Loop flags
Flag
Purpose
--tillend
Repeat until an empty round (zero findings, zero actions)
--repeat <N>
Repeat exactly N times
--maxruns <N>
Safety cap for --tillend (default 50)
--wait <seconds>
Pause between runs
🚀 Quickstart
# 1. Install
npm install -g monomind
# 2. Initialize in your project
cd your-project
monomind init
# 3. Wire into Claude Code as an MCP server
claude mcp add monomind -- npx -y monomind@latest mcp start
# 4. Health check
monomind doctor --fix
monomind doctor also reports Token Cost Settings (an effort env var overriding effortLevel, a huge compaction window, tool search off, duplicate hooks). doctor --json prints every check for programs to read, and --read-only / --offline keep it from changing files or using the network.
Semantic routing (opt-in download): embedding-based task routing needs a local model (~88 MB, Snowflake/snowflake-arctic-embed-xs via transformers.js). monomind init asks interactively whether to download it — the default is No, and non-interactive/CI installs never download it silently. Declining is fine: agent picking (monomind pick, the [PICK] hook line, hooks route) never needs the model; only route semantic, hooks_route_semantic and agent spawn --task use it, after the picker, and fall back to keyword and hash matching without it. Fetch it any time with monomind download-embeddings (or node scripts/download-embedding-model.mjs on a source checkout).
Native module install blocked? If doctor reports a missing better-sqlite3 binding (Could not locate the bindings file, or npm logs an install script that was "blocked because it is not covered by allowScripts"), your npm's allowScripts policy blocked its native build — this isn't a Monomind bug. Run npm install-scripts approve better-sqlite3 && npm rebuild better-sqlite3, then re-run monomind doctor --fix.
Open Claude Code. The core /mastermind:* workflows are available (all 40 come with monomind packs add or init --all-packs):
/mastermind:review --tillend # review and fix until nothing is left
monomind org run sample-team # run your first AI org (init writes sample-team.json; the first run offers to review and sign it)
/mastermind:help # show all commands
📚 Second Brain — Your Documents, Retrieved by Meaning
Drop documents (Markdown, TXT, PDF, DOCX) anywhere in your project and run monomind init — the Second Brain activates itself. No flags, no configuration, no accounts. Indexing and search run on your machine: a local embedding model (Alibaba-NLP/gte-modernbert-base, 768-dim, via transformers.js) and a local SQLite vector store. Your notes are indexed and stored locally — but the excerpts search returns are injected into your AI tool's prompts, and go to its model provider with the rest of the prompt.
From then on, every substantive prompt you type in Claude Code is automatically answered with your own knowledge in context — a hook retrieves the most relevant excerpts semantically (the always-on dashboard keeps the model warm, ~60ms per lookup) and injects them before Claude starts thinking. Ask "when do new parents get time off" and the parental-leave section of your handbook is already on the table, even though you never used the word "leave".
monomind doc ingest ./notes # index documents (init + session-start do this automatically)
monomind doc search -q "pricing psychology in checkout" # semantic search, by meaning not keywords
monomind doc list # what's indexed
monomind doc export # portable OKF bundle — move your brain between machines
Optional spreadsheet support:monomind init never downloads SheetJS. To extract .xlsx, .xls, or .ods files, install it only when you need it: run pnpm add xlsx in a project using a local/npx Monomind install, or npm install -g xlsx when Monomind is installed globally. Until then, spreadsheet files are skipped while the rest of document ingestion continues.
And it follows you across projects. Ingest a path from outside the current project (monomind doc ingest ~/notes, or add --global) and it lands in your personal global brain at ~/.monomind/global-brain (override with MONOMIND_GLOBAL_BRAIN_DIR) — kept as a sibling of ~/.monomind/projects specifically so monomind cleanup --data can never prune it — searchable from every project on the machine. All retrieval (CLI search, per-prompt injection, the dashboard) merges both stores automatically, with project knowledge winning ties and global hits labeled [global]. doc export --global moves your whole brain between machines as an OKF bundle — a file you move yourself, with no cloud service involved.
Retrieval quality is a tested invariant, not a hope: a golden-set eval (paraphrase queries against notes written in different vocabulary) runs in CI with an 80% recall bar.
Privacy note: the embedding model (~90MB) is fetched once from HuggingFace's CDN when your first document is indexed, then cached locally forever. That download is the only outbound request the Second Brain's indexing and search make — your documents and queries are processed locally. Excerpts injected into a prompt are a different matter: they go to your AI tool's model provider with that prompt. Offline at first index? Search degrades gracefully to keyword matching and monomind doctor tells you how to warm up later.
Which model where? Monomind uses two local embedding models. Snowflake/snowflake-arctic-embed-xs (~88MB) serves semantic task routing only. Everything the memory bridge embeds — both the Second Brain document index and the persistent memory store, which share that one bridge — uses Alibaba-NLP/gte-modernbert-base (768-dim, ~90MB); there is no separate document model. See Embeddings for the per-subsystem detail.
🧠 Memory That Persists
Every session, every agent, every org writes to a persistent memory store that survives across sessions — text plus embedding vectors in local SQLite (better-sqlite3, pure-WASM fallback), embedded by a local model. No cloud vector database and no API keys; the store itself uploads nothing. Entries recalled into a prompt go to your AI tool's model provider with that prompt. The next time you run anything, the store holds what earlier sessions recorded about what was built, what failed, and which patterns worked.
Before touching any file, Monomind queries Monograph — a SQLite-backed knowledge graph of your entire codebase. Nodes are files, classes, and functions. Edges are imports, calls, and dependencies.
/mastermind:understand # build the graph
/mastermind:graph-status # nodes · edges · freshness
# Inside Claude Code, Monograph runs automatically:
# → "what files does auth.ts import?"
# → "what breaks if I change UserService?"
# → "find all callers of validateToken()"
21 default MCP tools (+27 advanced via MONOGRAPH_MCP_ADVANCED=1). Impact analysis. Community detection. Zero grep.
The MCP server advertises a lean core of 21 tools by default to keep Claude's context small. Every other tool stays callable by name, and monomind_tool_search finds it. MONOMIND_MCP_FULL=1 advertises all 204 (MCP server).
🎣 Hooks & Workers
Monomind wires 28 hook subcommands into Claude Code across edit, task, command, and session lifecycle events — logging edits and outcomes to local pattern files and picking agents.
flowchart LR
CE["Claude Code\nEvent"] --> H["Hook Router"]
H --> P["pre-edit\npre-task\npre-command"]
H --> SS["session-start\nsession-end\nnotify"]
H --> I["route\nlog outcomes"]
H --> T["teammate-idle\ntask-completed"]
I --> DB[("patterns.json\nmemory store")]
DB -->|next session| CE
9 on-demand workers run at session start (staleness-gated, refreshed when older than 6 hours): health · ddd · security · cache · progress · map · audit · consolidate · reflexion.
🌐 Browser Automation
monomind browse drives Chrome over the DevTools Protocol with a native TypeScript client, so there is no external binary to install. It takes accessibility snapshots with ref handles (@e1), then clicks, fills, uploads, takes screenshots and handles tabs, cookies and storage.
The CDP port defaults to 9422 and falls back across bridge endpoints; --session <name> selects an isolated named session. Without an installed Chrome, Chromium or Edge, the first run installs Chrome (see Trust & Security). Details: Browse reference.
🛡️ MonoFence AI — Security Layer
Every agent boundary is defended by monofence-ai — real-time detection of prompt injection, jailbreaks, homoglyphs, base64 evasion, multi-turn escalation, and PII leakage.
From the shell, monomind security defend runs the same detection on text you pass it. security scan, cve, secrets, audit and redteam cover code, dependency and prompt-library checks (Security reference).
In Claude Code, the live pre-bash/pre-write gate is wired up via its own lazy-loaded integration in .claude/helpers/handlers/gates-handler.cjs (MONOMIND_MONOFENCE_GATE=off to disable) — not via monofence-ai's registerSecurityHooks() API, which is a separate integration point consumed only by @monoes/hooks' in-process HookExecutor.
📋 40 Mastermind Commands
Everything runs from inside Claude Code via slash commands. Here's the highlight reel:
Development
Command
What it does
/mastermind:plan
Comprehensive implementation plan
/mastermind:execute
Execute a written plan step by step, then hand off to review
graph TD
CC["Claude Code"]
MCP["MCP Server\nmonomind mcp start"]
D["Background Workers\n(@monoes/hooks, in-process)"]
ORG["OrgDaemon\nmonomind org run\nreal SDK sessions"]
CC <-->|"MCP tools: monograph, memory"| MCP
MCP <--> D
D --> ADB[("Memory store\npatterns + episodes")]
D --> MG[("Monograph\ncode graph")]
D --> HK["Hooks\n28 subcommands"]
CC -->|"Task tool - spawns agents"| AG["In-session agents\narchitect, coder\ntester, reviewer\nsecurity, perf"]
AG <-->|reads and writes| ADB
ORG -->|"spawns, policy-gated"| RA["Role agents"]
ORG <-->|reads and writes| ADB
style CC fill:#00D2AA22,stroke:#00D2AA
style AG fill:#8B5CF622,stroke:#8B5CF6
style ADB fill:#F59E0B22,stroke:#F59E0B
style ORG fill:#F59E0B22,stroke:#F59E0B
The earlier monoswarm and autopilot commands are gone (removed in 2.22.0); use the Task tool or monomind org run instead.
Claude Code's Task tool drives in-session multi-agent work; monomind org run drives persistent background orgs. Monomind keeps its own state on your machine; the AI tools it drives send prompts and code to their model providers — see Trust & Security.
CLI engine for Monomind — an open-source MCP server for Claude Code, OpenCode, Antigravity, Kimi Code, and Codex, with a codebase knowledge graph (tree-sitter + SQLite), persistent memory, multi-agent
CLI engine for Monomind — an open-source MCP server for Claude Code, OpenCode, Antigravity, Kimi Code, and Codex, with a codebase knowledge graph (tree-sitter + SQLite), persistent memory, multi-agent task coordination, and session hooks. Apache 2.0 licen
上次檢查時間：2026-11-14。 CLI engine for Monomind — an open-source MCP server for Claude Code, OpenCode, Antigravity, Kimi Code, and Codex, with a codebase knowledge graph (tree-sitter + SQLite), persistent memory, multi-agent task coordination, and session hooks. Apache 2.0 licen
