Adding memory to Copilot CLI

its MCP schema is its own, and the wiring follows it

Copilot CLI records each session and starts the next one empty. The events are still on disk, next to whatever you did that week in the other agents on the machine.

What Copilot already has

Sessions live under ~/.copilot/session-state/<sessionId>/events.jsonl as a stream of {type, data, timestamp} records. Complete, and read by nothing. How Copilot's store is read has the event shapes and the quirks behind them.

Adding recall

deja install copilot

Copilot keeps its MCP servers in ~/.copilot/mcp-config.json, and its schema is not the common mcpServers one — entries carry a type and a list of enabled tools, so the entry is written in Copilot's own shape rather than copied from another harness.

It needs the binary, which that entry calls by name:

brew install deja-vu
# or
curl -fsSL https://raw.githubusercontent.com/vshulcz/deja-vu/main/install.sh | sh

What you can ask it

Once the server is wired, the useful questions are the ones a fresh session cannot answer on its own: what this error meant the last time it appeared, how this project's build is actually invoked here, what was decided about a file and why. Agents & MCP lists the tools and what each is for.

The part that is not about this harness

The index covers every agent's transcripts on the machine — twenty of them today, each in its own format — so a fix found in one tool answers a question asked in another, including sessions from before any of this was installed. That is the reason to index rather than to capture.

Nothing here writes memories, so there is nothing to hallucinate into your history; indexing and search are local, and credentials are stripped as the index is built (privacy). An injection is capped at 1,536 bytes per prompt and about 4 KB per tool call — what memory costs has the measured comparison.

Getting started · How Copilot's store is read · Agents & MCP