cd /news/developer-tools/i-gave-github-copilot-cli-a-memory-i… · home topics developer-tools article
[ARTICLE · art-114776] src=dev.to ↗ pub= topic=developer-tools verified=true sentiment=· neutral

I Gave GitHub Copilot CLI a Memory I Own

A developer built Copilot CLI Local Memory, an extension that lets GitHub Copilot CLI save and recall project-specific rules across sessions using plain Markdown files. The tool avoids databases and background services, storing each memory as a modular instruction file under ~/.copilot/instructions/local-memory/, with commands like /remember, /memories, and /forget for explicit control. It supports file-scoped rules and deduplication, though it relies on Copilot's tool invocation for natural-language requests.

read3 min views1 publishedAug 29, 2026

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.

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.

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.

There is no vector database, embedding service, server, telemetry, background process, or runtime dependency. Explicit search uses local term ranking.

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.

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.

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.

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.

── more in #developer-tools 4 stories · sorted by recency
── more on @github copilot cli 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/i-gave-github-copilo…] indexed:0 read:3min 2026-08-29 ·