Skip to main content
Glama
README.md
<p align="center">
  <img src="https://raw.githubusercontent.com/brainOS-HQ/brain-os/main/assets/hero.png" alt="Brain OS - AI remembers conversations but forgets project state" width="100%" />
</p>

<p align="center">
  <a href="https://www.npmjs.com/package/brain-os"><img src="https://img.shields.io/npm/v/brain-os.svg?color=blue" alt="npm version" /></a>
  <a href="https://github.com/brainOS-HQ/brain-os/blob/main/LICENSE"><img src="https://img.shields.io/badge/license-MIT-green.svg" alt="MIT License" /></a>
  <a href="https://modelcontextprotocol.io"><img src="https://img.shields.io/badge/MCP-compatible-purple.svg" alt="MCP Compatible" /></a>
  <a href="https://brainos-hq.com"><img src="https://img.shields.io/badge/site-brainos--hq.com-black.svg" alt="brainos-hq.com" /></a>
  <a href="https://glama.ai/mcp/servers/brainOS-HQ/brain-os"><img src="https://glama.ai/mcp/servers/brainOS-HQ/brain-os/badges/score.svg" alt="brainOS-HQ/brain-os MCP server" /></a>
</p>

<p align="center">
  <strong>Local-first MCP memory server for operational project state: decisions, blockers, plans, patterns, and next moves.</strong>
</p>

# Brain OS

**[brainos-hq.com](https://brainos-hq.com)**

Your AI remembers conversations. It still forgets project state.

Brain OS gives agents operational state: decisions, plans, blockers, and priorities that survive across sessions.

## What is this?

AI agents are powerful inside a session, but long-running work has more state than any one chat: what you decided, what's blocked, what's active, and what should not be reopened. Brain OS gives agents operational state, not conversation logs:

- **Entities** — track projects, deals, initiatives with status, momentum, blockers, and next moves
- **Decisions** — log what was decided, why, what alternatives were rejected, and when to revisit
- **Patterns** — detect recurring blockers, stale work, avoidance signals, and theme convergence
- **Focus** — prioritize what to work on based on urgency, momentum, leverage, and staleness
- **Semantic recall** — search memory by meaning, not just ID

Brain OS is an [MCP server](https://modelcontextprotocol.io) that works with any MCP-compatible client: Claude Code, Cursor, Zed, GitHub Copilot, OpenAI Codex, Windsurf, or any agent that speaks the protocol.

## What it looks like in use

Before the agent acts, it can check whether a proposed move conflicts with an existing decision:

```
> decision_check({ proposal: "switch to Postgres for the new service" })

{
  "verdict": "conflict",
  "conflicting_decision": {
    "id": "dec_2026_03_14_db_choice",
    "decision": "Use SQLite for all local-first projects",
    "reason": "Lower ops burden, no infra to run, fits single-user scope",
    "rejected_alternatives": ["Postgres", "DuckDB"],
    "logged_at": "2026-03-14"
  },
  "guidance": "Re-litigating a settled choice. Surface the prior reasoning to the user before proceeding."
}
```

That's the wedge: structured state with enforcement, so agents stop re-opening questions you already answered.

## Quick start

Requires Node.js 20 or newer.

```bash
# In your project
npx brain-os init
```

This does three things:

1. **Creates a `.brain/` directory** with your entity, decision, and pattern stores.
2. **Installs slash commands** into `.claude/commands/` so you can run `/brain`, `/brain:focus`, `/brain:decide`, etc. directly in Claude Code. Bare aliases (`/focus`, `/decide`, etc.) install alongside for brevity.
3. **Drops agent-instructions pointer files** so any MCP-compatible client behaves consistently: `AGENTS.md` (canonical, cross-tool) plus thin pointer files for Claude Code (`CLAUDE.md`), GitHub Copilot (`.github/copilot-instructions.md`), Cursor (`.cursor/rules/brain-os.mdc`), Zed (`.zed/rules.md`), and Windsurf (`.windsurfrules`).

Flags:

- `npx brain-os init --minimal` — install only `AGENTS.md` + `CLAUDE.md`, skip the other client pointers (clean-repo mode)
- `npx brain-os init --no-commands` — skip slash commands (MCP server only)
- `npx brain-os init --no-agent-instructions` — skip all agent-instructions pointer files

### Connect to Claude Code

```bash
claude mcp add brain-os -- npx brain-os serve
```

### Connect to Cursor / other MCP clients

Add to your MCP config:

```json
{
  "brain-os": {
    "command": "npx",
    "args": ["-y", "brain-os", "serve"]
  }
}
```

### Configure semantic search (optional)

The `semantic_recall` tool needs an embeddings provider. Everything else (`entity_update`, `decision_log`, `plan_*`, etc.) works without one.

Brain OS does **not** install an embeddings SDK by default. This keeps the core install small and avoids pulling native ONNX/Sharp dependencies into users who do not need semantic search. Install the optional OpenAI provider beside `brain-os`, then add `BRAIN_EMBEDDINGS` to your MCP server env:

```bash
npm install brain-os openai
```

Then configure the provider in your MCP server environment:

```json
{
  "brain-os": {
    "command": "npx",
    "args": ["-y", "brain-os", "serve"],
    "env": {
      "BRAIN_EMBEDDINGS": "openai",
      "OPENAI_API_KEY": "${OPENAI_API_KEY}"
    }
  }
}
```

| Mode | What it does | Setup |
|------|--------------|-------|
| `local` | Temporarily unavailable while the former provider carries unresolved High-severity transitive advisories. | Use keyword recall or the OpenAI provider until an audited local backend ships. |
| `openai` | Uses `text-embedding-3-small` via the OpenAI API. Faster than local. Costs ~$0.02 per million tokens. | Install `openai`, set `BRAIN_EMBEDDINGS=openai`, then reference `OPENAI_API_KEY` from your shell environment. |

If `BRAIN_EMBEDDINGS` is unset, the OpenAI provider is missing, or local mode is requested, `semantic_recall` returns a clear setup error. No silent provider install, model download, or API call occurs. Core tools continue working normally.

> **Never paste a raw `sk-...` key into your MCP config.** `~/.claude.json` and similar MCP config files are plaintext and easy to expose on screen or in backups. Instead, export the key once in your shell and reference it from the MCP process environment.

## Tools

| Tool | Description |
|------|-------------|
| `entity_read` | Read operational state of one or all tracked entities |
| `entity_update` | Update entity state — status, momentum, blockers, next moves |
| `decision_log` | Log a strategic decision with reasoning and alternatives |
| `decision_check` | Check a proposed action against active decisions — returns clear/caution/conflict |
| `decision_refresh` | Refresh an existing decision: bump review_date, append evidence, change status. Metadata only — does not mutate decision content. |
| `decision_review` | Review-debt inbox: buckets overdue decisions (still-true / changed / archive / needs-evidence) and recommends an action for each. Read-only — proposes, you confirm. Auto-detects duplicate-stub decisions. |
| `context_resolve` | Resolve which entity the current work belongs to, from explicit mention / alias / files / lexical signals. Deterministic and confidence-scored — routes known context, never guesses intent. |
| `focus_get` | Get prioritized recommendations on what to work on |
| `project_evidence_scan` | Read-only scan of a repo's native operating state (STATE.md, FLAGS, HANDOFF, ROADMAP/PLAN/TODO, git activity, dirty files) for human gates, next moves, and do-not-touch — grounds focus in repo reality. |
| `pattern_detect` | Analyze patterns across all entities |
| `memory_check` | Audit memory quality — flags stale data, contradictions, noise |
| `memory_commit` | End-of-session commit — save all state changes |
| `semantic_recall` | Search memory by meaning using natural language |
| `audit_log` | Read the full mutation history — what changed, when, by whom |
| `wrap_check` | Detect whether meaningful state changes have accumulated since the last wrap |
| `wrap_auto` | Non-interactive safety-net wrap: applies low-risk fields and stages high-risk changes for review |
| `plan_set` | Set an ordered plan for an entity — step 1 becomes active next_move |
| `plan_advance` | Complete or skip a step (requires evidence/reason) — auto-promotes next |
| `plan_add` | Add steps to an existing plan |
| `plan_read` | View plan progress and current step |
| `risk_assess` | Classify risky actions before execution, including public-release and destructive-operation risks |
| `action_guard` | Apply built-in guard templates to common high-risk actions before proceeding |

## Slash commands

`brain-os init` installs slash commands into `.claude/commands/` so the agent has a clear vocabulary for working with operational state. Each command installs in two forms: `/brain:*` (canonical, documented form) and a bare alias (`/decide`, `/focus`, etc.) for power-user brevity. `/brain` is the namespace root and installs once.

It also installs:

- **`BRAIN_OS_PROTOCOL.md`** at `.claude/brain-os/PROTOCOL.md` (project) and `~/.claude/brain-os/PROTOCOL.md` (user). The protocol governs tool routing: when an agent runs a Brain OS slash command, it reads the protocol first, then calls `entity_read`/`plan_read`/`focus_get`/etc. as primary. Pulse files become fallback only.
- **`brain-os-mode` subagent** at `.claude/agents/brain-os-mode.md`. When the main agent delegates Brain OS work to a subagent (e.g. Claude Code's Task tool), it picks up under the same protocol — no risk of subagents falling back to generic file search.
- **Optional routing-guard hook** at `templates/hooks/brain-os-routing-guard.py`. Opt-in PreToolUse hook that warns if pulse files are read while a `.brain/` workspace exists. Install instructions are printed by `brain-os init`.

| Command | Alias | What it does |
|---------|-------|-------------|
| `/brain` | — | Project scanner: overview of all entities, freshness, decisions, alerts |
| `/brain:focus` | `/focus` | "What should I work on today, and why?" with evidence |
| `/brain:decide` | `/decide` | Capture a strategic decision (with conflict check before logging) |
| `/brain:strategy` | `/strategy` | Strategic thinking partner: think a decision through before building |
| `/brain:wrap` | `/wrap` | Session wrap: update entity state, capture decisions, detect momentum shifts |
| `/brain:patterns` | `/patterns` | Detect patterns across entities: recurring blockers, avoidance, themes |
| `/brain:retro` | `/retro` | Weekly or monthly retrospective: what shipped, what stalled, what's hidden |
| `/brain:graph` | `/graph` | Show how entities connect, leverage opportunities, shared decisions |

### Idempotent install

Re-running `init` is safe and repair-aware: existing Brain OS commands are preserved, and any missing form is installed. If a command path is taken by another tool, that path is skipped and reported — your file is never overwritten. You can install Brain OS into a project with existing `/decide` or `/focus` commands and the namespaced `/brain:*` forms will still land.

## How it works

Brain OS stores everything as local JSON files in a `.brain/` directory:

```
.brain/
  entities/     — one file per tracked entity
  decisions/    — decision log
  patterns/     — detected patterns
  config.json   — workspace settings
```

No cloud. No database. No account. Your data stays on your machine.

## Why no UI?

The interface is the agent. Brain OS is read and written through MCP tool calls — `/brain`, `/focus`, `/decide`, `decision_check`, etc. — surfaced inline by whichever client you use (Claude Code, Cursor, etc.). There's no separate dashboard to keep open, no second tab to context-switch into, no UI state that can drift from the underlying files.

This is a design choice, not a missing feature. Brain OS state lives at the same level as your code; the agent is already there, already in the conversation, already the right surface to ask "what's the priority right now?" Adding a human dashboard would split attention between two interfaces for the same data.

If you want a visual at-a-glance view, `.brain/` is plain JSON — render it however you want. The public MCP server stays agent-native by design.

## Teams & sync

Brain OS is single-user by design today. But because `.brain/` is just local JSON files, teams can share a brain through any synced filesystem — no product changes needed:

| Approach | Pros | Cons |
|----------|------|------|
| **Git** — commit `.brain/` to the repo | Diff/merge tools, version history, intentional sync points | Manual `git pull`; merge conflicts on simultaneous edits |
| **Dropbox / Drive shared folder** | Real-time-ish, no manual steps | Concurrent writes can create conflict files; `embeddings.json` rewrites often |
| **NFS / SMB / S3 mount** | Truly real-time | Requires infrastructure setup |

This works without any built-in sync because **every Brain OS tool call reads fresh from disk** — there's no in-memory cache to invalidate. Whatever your filesystem syncs, the next tool call sees. Same applies cross-tool: log a decision from Claude Code on Monday, open Cursor on Tuesday — same brain, both agents.

Native encrypted team sync with proper merge semantics is on the roadmap. The local-first foundation today is what makes that federation additive, not a retrofit.

## Auto-loaded status

When an MCP client connects, Brain OS exposes a `brain://status` resource with an operational overview — active entities, alerts, top priority, and recent decisions. The agent starts every session with context, not amnesia.

## Testing

Brain OS ships a smoke test suite at [`tests/smoke.mjs`](./tests/smoke.mjs), wired to `npm test` and run on every push by [`.github/workflows/audit.yml`](./.github/workflows/audit.yml). Run locally:

```bash
npm test
```

Current coverage (regression + happy-path):

- `decision_log` — type-collision no-supersede, explicit `supersedes` works, cross-entity supersession rejected
- `decision_check` — keyword-only flag stays caution without embeddings (no false STOPs), asymmetric semantic comparison (rejected vs chosen facet)
- `decision_refresh` — clears dangling `superseded_by` when status transitions away from `superseded`
- `plan_advance` — no over-promotion when an active step already exists
- `entity_update` — apply diff and record changes, create missing entity, `mode_reason` required when parking, status-only updates apply, guarded ranking skips are visible
- `semantic_recall` — throws `EmbeddingsNotConfiguredError` (not generic Error) when `BRAIN_EMBEDDINGS` is unset
- Store resolution — fails closed in a storeless cwd instead of silently creating an empty `.brain/`

Known gaps (no direct coverage yet): `focus_get` scoring, `pattern_detect` heuristics, `memory_*`, `plan_set/add/read`, and the `brain://status` resource. Expanding the suite is on the roadmap.

If you hit a bug, please open an issue with the tool, input, and output — that's the fastest path to a fix.

## Community

- **Discord:** [discord.gg/9VBUGstjY](https://discord.gg/9VBUGstjY) — questions, feedback, what broke for you, what you're shipping with Brain OS
- **Site:** [brainos-hq.com](https://brainos-hq.com)
- **Issues:** [github.com/brainOS-HQ/brain-os/issues](https://github.com/brainOS-HQ/brain-os/issues)

## License

MIT

TDQS

A4.2/5.0

Scored across 22 tools

Disambiguation5/5

Every tool targets a distinct resource-action combination (e.g., entity_read vs entity_update, decision_log vs decision_check, plan_set vs plan_add). Overlapping areas such as semantic_recall vs audit_log and wrap_check vs wrap_auto are clearly differentiated by their descriptions.

Naming Consistency4/5

The majority of tools follow a consistent noun_verb pattern (plan_add, decision_check, entity_read). A few names like wrap_auto, semantic_recall, and audit_log deviate slightly from this pattern, but the overall convention remains predictable and readable.

Tool Count3/5

With 22 tools, the set is on the heavy side, falling within the 16-25 borderline range. While each tool serves a meaningful purpose, the number exceeds the ideal 3-15 range for a well-scoped server.

Completeness4/5

The surface covers the core domain well: entity CRUD (via entity_read/update), decision lifecycle (log, check, review, refresh), plan management (set, add, advance, read), risk assessment, and memory operations. Minor gaps like explicit entity deletion or plan step editing are workable through entity_update and plan_set, so there are no critical dead ends.

Maintenance

ActivitySlowing
ResponsivenessUnresponsive