I Gave GitHub Copilot CLI a Memory I Own

Shankar B — Sat, 29 Aug 2026 00:01:52 +0000

Honestly, I was not trying to build a memory system.

I just wanted to talk to Copilot CLI the way I would talk to another developer:

“Save this debugging finding to local memory: the Redis integration tests must run serially because the workers share DB 0.”

“Remember locally that changing the auth timeout requires updating both gateway.yml and worker.yml.”

“Save this migration decision to local memory: use expand–migrate–contract because the API and workers deploy independently.”

Then I wanted to close the terminal, come back tomorrow, and not explain them again.

These are the kinds of details engineers learn while doing the work: a flaky-test cause, a coupling between two configuration files, and the reasoning behind a migration strategy. Copilot could help uncover them, yet the lesson could still disappear with the session.

I wanted those rules to survive across sessions. But I also wanted to know exactly where they lived, what they said, and how to remove them.

That became Copilot CLI Local Memory.

Memory should feel like yours

I did not want to build another database, background service, or dashboard. For a handful of important project rules, that felt heavier than the problem.

I wanted memory to be boring in the best possible way: a file you can open.

The extension therefore has three explicit commands:

/remember Production deployments must always use --dry-run.
/memories deployment
/forget 51e81a1f6f

Save a rule. Start a new session. Copilot remembers.

What actually gets stored

Each memory becomes one modular Copilot instruction file under:

~/.copilot/instructions/local-memory/

A generated file looks like this:

---
applyTo: "**"
---

Production deployments must always use --dry-run.

It is ordinary Markdown. You can inspect it, edit it, back it up, or delete it yourself.

File-scoped rules are possible too:

/remember --scope "src/**/*.ts" Use Zod rather than Joi for validation.

Deliberately small

Why should Copilot need a database just to remember one deployment caveat?

I didn’t want Postgres, SQLite, a vector database, embeddings, or another service to maintain. So I kept the installed runtime deliberately small: two JavaScript files using only Node.js built-ins. There are no runtime dependencies, no database, and no server.

Each memory is one plain .instructions.md file on your machine. You can open it, diff it, edit it, back it up, or delete it.

Explicit search uses deterministic local term ranking instead of embeddings.

The extension deduplicates equivalent entries and refuses deletion by text when several memories match. It also blocks several common credential formats, although no detector is perfect and secrets should never be stored in agent instructions.

You can ask in natural language:

Save this caveat to local memory: run deploy-tool with --dry-run first.
Check local memory for caveats about deploy-tool.

There is an honest limitation: Copilot decides whether to invoke a tool for natural-language requests. Use /remember, /memories, and /forget when predictable behavior matters.

Newly saved instructions are automatically applied in a new session. And although the extension itself makes no network calls, Copilot may include applicable instruction text in the prompt sent to the model. Local storage does not make secrets safe to place in prompts.

Why not put everything in `copilot-instructions.md`?

For stable, team-wide rules, you should. Language versions, formatting standards, and permanent repository conventions belong in documentation or checked-in instructions.

This extension is for the moment when useful knowledge emerges during a task and you want to capture it without stopping to curate a large instruction file. Each memory is stored separately, can be searched or removed by command, and can be scoped to matching files. If a memory becomes a permanent team rule, promote it into the repository’s documentation or instructions.

GitHub’s Memory documentation describes this learned context as including architectural decisions, build commands, database-connection patterns, and settings that must remain synchronized across files. That is the territory these examples are meant to represent.

Why not just use GitHub’s managed Memory?

GitHub’s managed Memory is the right option when it is available and fits the workflow. This project serves a narrower preference: explicit saves, plain local files, and direct user control. It may also help developers whose organizations disable managed Memory while still permitting extensions and custom instructions.

It does not imitate GitHub’s service or bypass organization policy.

One rule you never want to explain again

The repository includes Windows, macOS, and Linux installers, uninstallers that preserve saved memories by default, tests, and recordings from the real Copilot CLI.

Try it here:

https://github.com/shankarnarayanb/copilot-cli-local-memory

If you have ever grown tired of teaching your coding assistant the same lesson twice, save one rule and start a new session.

Then tell me what worked, what surprised you, and what Copilot should never forget again.

DEV Community: Shankar B