Setup Guide

GitHub Copilot with
long-term project
memory

GitHub Copilot has the largest installed base of any AI coding tool. But it has no memory between sessions — every conversation starts cold, with no knowledge of your architecture decisions, past migrations, or team conventions.

Without MnemeBrain, Copilot forgets everything when the session ends. With it, architectural decisions persist across weeks of development — and contradictions are surfaced before they cause bugs.

March 2026 ~5 min setup Copilot Chat + MCP + MnemeBrain
copilotmcpsetup guidemnemebrain-lite
Copilot Chat — memory across sessions
# Sprint 1 You: we chose event-sourcing for the order service Copilot: Stored. "order service uses event-sourcing" · confidence 0.95
# Sprint 6 — new session, no shared context You: what should I know about the order service architecture? Copilot: Order service uses event-sourcing (confidence: 0.95). Stored in Sprint 1 · evidence: chat_003
TL;DR
1pip install mnemebrain-lite then mnemebrain-lite serve
2Clone MCP bridge: git clone https://github.com/mnemebrain/mnemebrain-mcp
3Open VS Code settings and add the MCP server under github.copilot.chat.mcp.servers
4Reload VS Code — Copilot Chat now has 13 persistent memory tools
5Chat naturally. Decisions, migrations, and conventions persist across every session.
Steps in this guide
Architecture decisions that survive across sprints
Sprint 1
You: We're using CQRS + event-sourcing for the order service. Read models are materialized views in Postgres.

↳ believe() × 2 beliefs stored
confidence: 0.95 each
evidence: [sprint1_chat_003]
Sprint 6 (new session, cold start)
You: How should I structure the new reporting endpoint?

↳ search() called
query: "order service architecture"

Copilot: Order service uses CQRS + event-sourcing (0.95). Read models are Postgres materialized views. The reporting endpoint should query the read model, not the event stream.

Sprint 6 Copilot had zero context from Sprint 1. MnemeBrain bridged six weeks of project history.

01

How it works

MCP + MnemeBrain inside VS Code

GitHub Copilot Chat in VS Code supports MCP — the Model Context Protocol. Once configured, Copilot can call external tools mid-conversation. MnemeBrain registers as an MCP server and gives Copilot 13 memory tools: believe, search, explain, retract, revise, and more.

The backend is a local FastAPI process storing your belief graph in a Kuzu database on your machine. The MCP bridge is a lightweight stdio process VS Code spawns on startup. Nothing leaves your machine.

02

Install the backend

Local only, no cloud dependencies
terminal
pip install mnemebrain-lite
mnemebrain-lite serve
# → MnemeBrain running at http://localhost:8000

Keep this terminal open. The backend must be running whenever you want Copilot to use memory.

03

Clone the MCP bridge

The process VS Code spawns to connect Copilot to MnemeBrain
terminal
git clone https://github.com/mnemebrain/mnemebrain-mcp
cd mnemebrain-mcp
uv sync
pwd   # note this path
04

Register with Copilot

VS Code settings.json — one block to add

Open VS Code Settings (JSON) and add the MCP server configuration:

VS Code settings.json
"github.copilot.chat.mcp.servers": {
  "mnemebrain": {
    "command": "uv",
    "args": [
      "--directory",
      "/path/to/mnemebrain-mcp",
      "run",
      "mnemebrain-mcp"
    ],
    "env": {
      "MNEMEBRAIN_URL": "http://localhost:8000"
    }
  }
}

Replace /path/to/mnemebrain-mcp with the path from the pwd command above. Save and reload VS Code.

Workspace-scoped config: Add the same block to your .vscode/settings.json and commit it. Every team member who clones the repo gets shared Copilot memory pointing at their own local MnemeBrain instance.
05

Verify and use persistent memory

What it looks like in Copilot Chat

Open Copilot Chat and try storing your first belief:

Copilot Chat
Remember: this project targets Node.js 20 LTS.
We do not use CommonJS — ESM only across the entire codebase.

Copilot calls believe twice and stores both facts with evidence. Next session, they're available via search. To verify what's stored:

Copilot Chat
What do you know about this project's JavaScript setup?

Contradiction detection when architecture changes:

ATTACKS edge detected — runtime decision revised
Sprint 1: "project uses Node.js 20 LTS"
Sprint 9: "we migrated to Bun for the build pipeline"

truth_state: BOTH ← conflict flagged, not silently overwritten
belief_1: "Node.js 20 LTS" confidence: 0.95 → 0.31
belief_2: "Bun (build pipeline)" confidence: 0.90

Copilot: ⚡ Runtime conflict detected. Node.js stored in Sprint 1, Bun now mentioned. Confirm scope before I update project beliefs.
06

Enterprise patterns

Team-shared memory across your GitHub org
🏢
For enterprise teams: Each developer runs their own local MnemeBrain instance. Project-level beliefs — architecture decisions, ADRs, conventions — can be seeded from a shared export at onboarding. Beliefs are private by default; sharing is explicit.

Seed project beliefs from a shared ADR file at team onboarding:

Copilot Chat
Read ARCHITECTURE.md and store all architectural decisions as beliefs.

Copilot reads the file, extracts each ADR, and calls believe for each decision. New team members get instant project memory without trawling through months of commit history.

What you've built

GitHub Copilot now has a persistent belief graph that survives across every session, sprint, and team member. Architecture decisions, runtime choices, and migration history are stored, tracked for contradictions, and retrieved semantically — exactly when Copilot needs them.

Typical belief lookup is <5ms on a local Kuzu store with ~100k beliefs. Everything runs on your machine — no cloud, no external APIs beyond what you already use.

GitHub: mnemebrain-lite →   PyPI →   BMB Leaderboard →