Loading this screen…
What Brain is, answers to common problems, and the words this dashboard uses. Each entry links to the screen or guide that goes deeper.
Project Brain reads the committed source of your repositories and gives your coding agents context through MCP: the relevant code, the decisions and rules you recorded, and what a change may affect. It runs on your own server, for one operator or a small team whose members each see only the projects they have a role on. It is early software; run it for people you trust.
Problems people run into first, and where to fix them.
Connecting Brain makes its tools available; it doesn’t make an agent call them. Check that the agent is connected in Setup, then ask it in its instructions to call prepare_task_context before planning a change and review_diff before finishing.
MCP calls appear under Activity, and prepared task context appears under Context packs. Agent tasks only lists work explicitly started through the harness. See the suggested agent workflow.
Brain answers from the last commit it read. Press Ctrl K and choose “Re-index the repository” (on a team this needs a Contributor or Reviewer role on the project), or use the index step in Setup (team admins). Later runs only re-read what changed.
Brain reads committed source only. If a re-index refuses the repository, commit your source edits first; ignored build output such as node_modules doesn’t count. Past runs are under Index runs.
Jobs run in a background worker, not in the API. For a source checkout, ./scripts/start.sh starts the API, worker and dashboard. For a Docker server, use ./deploy/server_up.sh and follow the deployment runbook rather than starting a second local stack.
Activity shows each job and where it stopped.
The dashboard isn’t connected to a Brain server, so it shows demo data. Start Brain with ./scripts/start.sh; it gives the dashboard the server address and key. A web app started on its own stays a demo.
The code index and memory stay in the databases you run. Text still leaves the machine if you use cloud models: an embedding provider receives the pieces it turns into embeddings, and a language-model provider receives prompts that can include source, decisions and rules. Connected agents receive tool results under their own service’s policy.
For local-only operation, point both model roles and their endpoints at local models in Settings, disable external notifications, webhooks and remote integrations, and use a local agent connection. Details are in the FAQ.
Treat it as a starting point. A context pack selects files, rules and decisions for one task; it can miss evidence or lag behind the latest edits, so the agent should still read current source and run tests. Quality shows how well search finds the right code on a fixed test set, which isn’t a measure of coding results.
Back up .env and your data first. On a local checkout, fetch tags and check out the new release tag, run ./scripts/bootstrap.sh, refresh web packages with cd apps/web && npm ci, and restart with ./scripts/start.sh. On a server, follow the runbook and the backup guide.
The same explanations appear when you hover a dotted-underlined word.
The latest documentation on GitHub.