How to Give GitHub Copilot Long-Term Memory (MCP Setup, 2026)

GitHub Copilot understands your IDE. It does not remember your architecture.

Last sprint you and the team spent an afternoon arguing background jobs versus inline retries for billing. You wrote down why, picked retries, moved on. Three weeks later Copilot Chat confidently scaffolds a new endpoint with a Sidekiq-style worker. It cannot read your Linear comment, your Notion ADR, or the post-mortem in someone else's Apple Notes.

There is a fix, and it is not "paste the decision into the prompt every time."

In this guide, "long-term memory" means project knowledge Copilot can retrieve across sessions: architecture decisions, conventions, runbooks, incidents, and team notes.

What Copilot is good at, and what it forgets

Copilot is excellent inside the file. It autocompletes the function you are writing. It reads the open buffer, the imports, and a useful slice of the surrounding repo. Agent mode in VS Code goes further, planning and editing across files in one go.

The weakness shows up between files and between sessions. Copilot has no built-in memory of what your team decided last week, which library you swore off after the migration, or what the on-caller learned at 3am last Tuesday. The longer the project, the wider that gap gets, because the volume of decisions grows faster than any single context window.

What MCP fixes here

Model Context Protocol (MCP) is an open standard that lets a model call tools. One of those tools can be your knowledge base. Copilot Chat can search it, read entries from it, and write back to it during a coding session, without leaving VS Code. If you want the long version, What is MCP? covers it.

Wire up a knowledge base over MCP and Copilot Chat starts each conversation with your team's real context, not a blank slate. Hjarni for GitHub Copilot is the integration page; the walkthrough below is the five-minute version.

Step 1: Write a few notes worth reading

Sign up at hjarni.com and write the things you are tired of re-explaining. Decisions and their reasons, project conventions, the runbook for the queue that wedges every other Friday.

Title: Billing Conventions

Use inline retries with exponential backoff for billing.
Background jobs were rejected in ADR-0042: too many silent failures
when the worker pool was saturated during sales events.
Idempotency keys live on the Charge model, not the Customer.

Ten notes is enough to feel the difference.

Step 2: Add the MCP server to VS Code

VS Code reads two locations for MCP config. Per-project, drop a file at .vscode/mcp.json inside the repo. User-wide, open the command palette and run MCP: Open User Configuration, and VS Code opens the user-level mcp.json for you.

Either way, paste this:

{
  "servers": {
    "hjarni": {
      "type": "http",
      "url": "https://hjarni.com/mcp"
    }
  }
}

One gotcha worth knowing before you debug it the hard way: the root key is "servers", not "mcpServers" like Cursor and Claude Desktop use. VS Code expects this shape, so using "mcpServers" here can prevent the server from loading.

Step 3: Open Copilot Chat in agent mode

Open Copilot Chat and switch to agent mode. VS Code opens a browser tab for the Hjarni OAuth flow. Sign in once. Back in the chat, the Hjarni tools show up in the tool list (search, read, create, update, link, tag).

Ask Copilot something only your notes would know:

Search Hjarni for the billing conventions and tell me whether retries should be inline or in a background job.

Copilot calls the search tool, reads the note, answers from your actual reasoning instead of inventing one.

A real workflow

Three patterns worth running once you have Hjarni connected:

Ask the question Copilot cannot answer from code. "Why did we ditch the background job approach for billing?" Copilot pulls the ADR from Hjarni and quotes the constraint you agreed on, instead of guessing from the call sites.

Load conventions before agent mode writes. Before agent mode rewrites a service, ask it to read your Project Conventions and Service Object Patterns notes first. The diff lands closer to mergeable on the first try because Copilot is generating against your team's patterns, not generic ones.

Write the runbook while the incident is fresh. End an incident by asking Copilot Chat to draft a Hjarni note: what failed, what you tried, the actual fix, and what to check next time. The next on-caller's Copilot reads it back when the symptom returns in three months.

None of this changes how you use Copilot. You ask the agent things. The agent calls tools. The tools happen to include your project's accumulated context.

One knowledge base, every editor

Hjarni is account-scoped, not editor-scoped.

The notes Copilot writes during a coding session are the same notes Claude, ChatGPT, and Cursor can read later.

Different clients. Same memory.

Folder-level instructions in Hjarni let you steer Copilot per project: "in the Payments folder, never propose schema changes without an ADR." The instructions live with the notes, not in the editor, so they survive every Copilot update.

Closing

Your repo knows the code. Your issue tracker knows the tasks. Your team knows the history. Copilot only sees part of it.

Set up Hjarni for GitHub Copilot, add one project note, and ask Copilot a question your repo cannot answer.

The free tier gives you 25 notes with full MCP access. No credit card.