Persistent Memory for
GitHub Copilot — MCP Setup Guide
GitHub Copilot added MCP server support in VS Code, turning Copilot Chat from a question-answering tool into a full-capability agent. Add the Kronvex MCP server and Copilot Chat will remember your workspace architecture, coding conventions, and project decisions across every session — not just while a file is open.
Copilot's MCP support — what changed and why it matters
For years, GitHub Copilot was primarily an autocomplete tool. It read your open files and suggested the next line of code. In 2025, GitHub added Copilot Chat — a conversational interface embedded in VS Code. Then, in a significant update, they added MCP server support to Copilot Chat, enabling it to connect to external tools and data sources at inference time.
This changes the nature of Copilot Chat fundamentally. Instead of a conversational window that forgets everything when you close it, Copilot Chat can now:
- Call external APIs during a conversation
- Store and retrieve information from persistent stores
- Execute tools and integrate results back into the conversation
- Maintain state across sessions via external services like Kronvex
The catch is that MCP support in Copilot is workspace-scoped and requires explicit configuration in a .vscode/mcp.json file. Once configured, Copilot Chat automatically discovers and can invoke the tools exposed by connected MCP servers — including Kronvex's memory tools.
Get your Kronvex API key
Before configuring VS Code, obtain your Kronvex credentials from the dashboard.
team-myapp-copilot). Copy the Agent UUID from the agent detail page.kv-.node --version.Configure .vscode/mcp.json for your workspace
Copilot MCP configuration is defined in a file called mcp.json inside your workspace's .vscode/ folder. This is a workspace-scoped configuration — it applies to everyone who opens this workspace, and you can commit it to your repository to share the setup with your team (with secrets managed separately).
Create or edit .vscode/mcp.json in your project root:
{ "servers": { "kronvex-memory": { "type": "stdio", "command": "npx", "args": ["-y", "@kronvex/mcp-server"], "env": { "KRONVEX_API_KEY": "kv-your-api-key", "KRONVEX_AGENT_ID": "your-agent-uuid" } } } }
Note the slightly different schema compared to other MCP clients: Copilot uses a servers key (not mcpServers) and requires a "type": "stdio" field. This is specific to VS Code's Copilot MCP implementation.
.vscode/mcp.json file is safe to commit — but you should not hardcode API keys in version-controlled files. Instead, use VS Code's ${env:VARIABLE_NAME} syntax to reference environment variables:"KRONVEX_API_KEY": "${env:KRONVEX_API_KEY}"Then set the actual values in a
.env file (in .gitignore) or in your system environment. Team members set their own keys; the committed config stays clean.
After saving the file, reload VS Code (Ctrl+Shift+P → "Developer: Reload Window"). Open Copilot Chat (Ctrl+Shift+I) and look for the tools icon — click it to see connected MCP servers. The kronvex-memory server should appear with a green status.
Verify the memory loop in Copilot Chat
With the server connected, test the full memory cycle directly in Copilot Chat:
@workspace Use the kronvex-memory MCP server to store this:
"This project follows domain-driven design. All business logic
lives in src/domain/. Controllers in src/api/ only handle HTTP
concerns — validation, auth, response formatting. Never put
business logic in controllers."
Copilot will call the remember tool. You will see "Using tool: remember" appear in the chat panel, followed by a confirmation. Then test retrieval in a new chat session:
Before I write a new feature, what are the architectural
conventions in this project? Check my memories.
Copilot will call recall or inject_context and surface the domain-driven design memory. Any code it generates for the new feature will place business logic in src/domain/ automatically.
Chat vs autocomplete — where memory helps
Understanding the difference between Copilot's modes helps you use memory effectively:
Copilot Chat (with MCP memory)
This is where Kronvex memory shines. Use Chat when you need Copilot to reason about your project, answer architectural questions, write larger code blocks with full awareness of your conventions, or plan a multi-step implementation. Memory is injected at the start of the conversation and stays active throughout.
Copilot Agent mode
VS Code's Copilot also has an Agent mode (accessible via the chat input dropdown) where it can execute terminal commands and make file edits autonomously. In Agent mode, Copilot can use MCP tools throughout its execution loop — not just at the start. This is where Kronvex memory is most valuable for large autonomous tasks.
Inline autocomplete (no MCP access)
When you type code and see grey ghost text suggestions, that's inline autocomplete. It reads your open files and recently edited code, but it cannot call MCP servers. Memory does not apply here — it is purely context-window based.
.github/copilot-instructions.md file that is automatically injected into every Copilot Chat conversation. Use this file for static conventions (language, framework, style guide). Use Kronvex for dynamic context — things that evolve as the project grows (bug history, architectural decisions, sprint progress, discovered gotchas). The two complement each other perfectly.
Memory use cases for Copilot teams
Shared team knowledge base
The most powerful use case for Copilot + Kronvex is team-wide knowledge sharing. Commit a single .vscode/mcp.json pointing to a shared Kronvex agent. Every developer on the team contributes to and benefits from the same memory pool.
Practical examples of team-shared memories:
- Senior developer documents a critical performance pitfall in the database layer → every Copilot Chat session across the team will surface this when working on database code
- DevOps engineer stores the deployment runbook as a procedural memory → any developer asking "how do I deploy?" gets the current procedure automatically
- Tech lead records an ADR (Architecture Decision Record) → future Copilot sessions context-aware of the decision reasoning
- QA engineer logs known flaky tests and their root causes → developers working on those areas get the context before touching the code
Onboarding acceleration
New developers joining a team can be fully productive with Copilot in days rather than weeks. Configure Kronvex with your team's accumulated knowledge, point their VS Code at the shared agent, and their Copilot Chat sessions will immediately have access to everything the team knows — without requiring weeks of pairing sessions or documentation hunting.
Convention enforcement without rules files
Most teams rely on linters, formatters, and sometimes copilot-instructions.md to enforce conventions. But these only catch what was anticipated. Kronvex lets you add conventions dynamically as they emerge:
Store in kronvex-memory:
"Discovered 2026-05-04: The useEffect cleanup function must
always cancel pending promises using AbortController, not just
set a boolean flag. Three bugs in production traced to the
boolean approach. See PR #341 for the correct pattern."
This convention is now available to every developer's Copilot Chat sessions immediately — no PR required to update a rules file, no wait for the next team standup.
Cross-session debugging context
When investigating a complex bug that spans multiple sessions, store the investigation progress in memory:
Store this bug investigation progress:
Bug: Auth tokens occasionally expire prematurely (1-2% of sessions)
Investigation status: IN PROGRESS
Findings so far:
- Not related to clock skew (checked server/client time sync)
- Correlated with deployments on EU-WEST region only
- Token expiry set to 3600s but seeing some expire at ~3400s
- Hypothesis: Railway container restart truncates token lifetime
Next steps: add timing logs to token refresh middleware
Relevant files: app/auth.py, middleware/token_refresh.py
The next developer (or you in the next session) immediately has the full investigation context — no ramp-up, no re-reading through PR comments and Slack threads.
Tips, enterprise considerations, and troubleshooting
MCP server not appearing in Copilot tools
If the kronvex-memory server does not appear in Copilot Chat's tools panel after reloading VS Code:
- Verify VS Code version: Help → About — must be 1.90 or higher
- Check Copilot Chat extension version in Extensions panel — update if below 0.20
- Confirm the
.vscode/mcp.jsonfile uses theserverskey (notmcpServers) and includes"type": "stdio" - Run
npx -y @kronvex/mcp-serverdirectly in VS Code's terminal to check for startup errors - Open VS Code Output panel → select "Copilot Chat MCP" from the dropdown to see MCP server logs
GitHub Copilot Enterprise and data privacy
If your organisation uses GitHub Copilot Enterprise with content exclusions or data governance policies, MCP server calls from Copilot Chat go through VS Code directly to the MCP server process — they do not pass through GitHub's servers. Memory data stored in Kronvex never touches GitHub's infrastructure. For enterprise compliance, confirm that outbound connections to api.kronvex.io (EU, HTTPS) are permitted by your network policy.
Memory scoping for large teams
For teams with 20+ developers working across multiple domains, consider a multi-agent memory architecture:
- Global agent — company-wide conventions, deployment procedures, architectural decisions (shared Agent ID in committed
.vscode/mcp.json) - Per-team agent — team-specific patterns (developers override
KRONVEX_AGENT_IDlocally) - Per-developer agent — personal preferences, individual project notes (developer sets their own agent)
All three tiers can be active simultaneously by configuring multiple Kronvex server entries in .vscode/mcp.json with different environment variables for each.
GDPR and enterprise data residency
All data stored in Kronvex lives in the EU (Frankfurt, Germany). For organisations with GDPR obligations or European data residency requirements, this matters significantly: code snippets, architectural decisions, and project context stored in memory never leave EU infrastructure. Kronvex provides data processing agreements (DPA) for enterprise customers — contact via the contact page for enterprise agreements.
Combining Copilot + Kronvex with GitHub Actions
An advanced pattern: use GitHub Actions to automatically store deployment and CI/CD events as memories. When a deployment fails, a GitHub Action can call the Kronvex API to store the failure context — so the next time a developer asks Copilot "what failed in the last deployment?", the memory is already there.
- name: Store deployment failure in Kronvex if: failure() run: | curl -X POST https://api.kronvex.io/api/v1/agents/$AGENT_ID/remember \ -H "X-API-Key: $KRONVEX_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "content": "Deployment ${{ github.run_id }} failed at step ${{ github.job }}. Branch: ${{ github.ref }}. Error: see Actions run.", "memory_type": "episodic" }' env: KRONVEX_API_KEY: ${{ secrets.KRONVEX_API_KEY }} AGENT_ID: ${{ secrets.KRONVEX_AGENT_ID }}
Give your entire team a shared memory
Free plan — 500 memories, 3 agents. Copilot + Kronvex is configured in under 5 minutes. Your team's knowledge survives beyond any single session.
Get your free API key →