GitHub Copilot CLI memory: how to make context survive between sessions

GitHub Copilot CLI has no long-term memory. Every session starts blank, and when you close it, whatever the agent worked out is gone. What does persist is a set of instruction files that Copilot folds into your prompts: your personal ~/.copilot/copilot-instructions.md, a repository’s .github/copilot-instructions.md, and an AGENTS.md in the repository. Copilot combines them rather than picking one, so a personal file and a repo file both apply.

That gives you the reading half of memory for free. The writing half you build yourself, because nothing in Copilot CLI writes to those files when you make a decision. So you need a durable file the agent reads before it starts, and a reliable way for it to write back as it goes.

What Copilot CLI reads on its own

Copilot CLI finds repository files at the repo root, the current working directory, the directories between them, and directories in the path of a file it is editing. These files are not read once at launch. Copilot folds them into each prompt you send, so a bloated instruction file costs context budget on every turn.

File	Scope	Who maintains it
~/.copilot/copilot-instructions.md	Every session on this machine	You
.github/copilot-instructions.md	One repository	The repo, usually committed
AGENTS.md	The directory it sits in and everything below it	The repo, shared with other agents
.github/instructions/*.instructions.md	Files matching the applyTo pattern in its frontmatter	The repo

Path-scoped instruction files matter more than they look. They attach context to one service in a monorepo without growing the file that every prompt carries. Setting COPILOT_HOME moves the personal lookup to another directory.

Instruction files are policy, not persistent context

An instruction file holds standing rules: use pnpm, never push to main, run the type checker before claiming done. Those are stable and they belong there. An instruction file does not hold history. It will not tell Copilot why you dropped Redis for the job queue, what caused the flaky test, or that staging runs a different schema.

Policy and history have opposite shapes. You edit policy in place and it stays small. History only grows, and you want to search it rather than read it top to bottom. Pour history into copilot-instructions.md and your standing rules get buried while Copilot spends context on last quarter’s decisions.

Copilot has one built-in escape hatch. Inside an instruction file you can write @ followed by a relative path, and Copilot pulls that file in, so a small policy file can point at a separate memory file. It arrives whole, though, which separates the two concerns without solving growth.

The simplest setup: one markdown file the agent appends to

The cheapest thing that works is a single file outside any repo, say ~/notes/agent-memory.md, plus a few lines in your personal instructions.

## Project memory

Read ~/notes/agent-memory.md before proposing an approach.
When you make a decision or find a bug's root cause, append a dated
entry to that file under the right project heading. Never rewrite
existing entries.

This costs nothing and it is genuinely useful. Copilot CLI has shell access, so the agent appends with >> and searches with grep, which keeps both operations cheap.

The limits show up later. Two agents appending at once can interleave mid-line, because nothing takes a lock. There is no schema, so recall quality depends on whatever the agent chose to write that day. Nothing marks a superseded decision either, so a reversed call sits next to a live one looking identical.

Durable options worth comparing

Three approaches go further, and they trade off differently.

An MCP memory server plugs into Copilot CLI’s mcp-config.json and gives the agent explicit save and search tools. It wins on being wired into the agent loop, so recall does not depend on the agent obeying a sentence of prose. MCP memory server versus plain markdown files covers that trade.

A decisions/ directory committed to the repository wins on review. History travels with the code, teammates see it in pull requests, and git dates and attributes every entry. It only covers one repository, though, and it holds nothing you would rather keep off the team’s radar.

A notes app with a command-line interface stays plain markdown while adding structure and safe writes. That is the rest of this guide.

A sturdier setup: a notes vault with hash-checked writes

Jotura is a free local-first markdown notes app for Mac, Windows, Linux, and Android. It ships a first-party command-line tool called jotura that agents drive directly, and the vault is an ordinary folder of .md files you can open in any editor. Only cloud sync costs money. The app and the CLI do not.

jotura memory log --kind decision --title "Use Postgres advisory locks for the job queue" --project Billing
jotura memory recall "job queue locking"
jotura context "add retry backoff to the billing worker"

Each entry becomes its own note rather than a line in a growing file. The decision above lands at Memory/Decisions/2026-08-30 use-postgres-advisory-locks-for-the-job-queue.md with kind, status, importance, and date in the frontmatter. Writes are atomic, so a crashed run leaves no half-written file. Marking a decision superseded flips its status, which is how a reversed call stops coming back.

jotura memory recall ranks across those notes and prints one line each.

Memory/Decisions/2026-08-30 use-postgres-advisory-locks-for-the-job-queue.md	decision	active	Advisory locks keep the queue single-writer without a Redis dependency.
Memory/Facts/2026-08-14 staging-billing-schema-lags-production.md	fact	active	Staging runs migration 214, production is on 219.

jotura context is the call to make at the start of a task. It prints your vault conventions, the memories most relevant to the task description, and any open follow-ups.

Ordinary notes get hash-checked writes. The agent reads a note and gets a content hash, then passes it back with --if-hash when it writes. If anything changed in between, the write fails with a distinct exit code instead of overwriting silently. Replacements require a unique string match, and body edits never touch the YAML frontmatter.

One command installs the app, the CLI, and the agent wiring.

curl -fsSL jotura.io/install.sh | bash
jotura skill install copilot

On Windows, run irm jotura.io/install.ps1 | iex instead. The skill install copilot step amends ~/.copilot/copilot-instructions.md with a block explaining the commands, preserving what was already there. Jotura ships a session-start hook for Claude Code only, so Copilot CLI will not run jotura context on its own. The instruction has to ask for it, and the agent has to comply.

At the start of any task, run `jotura context "<task description>"` and
read the output before doing anything else.

Keeping the same instructions on every machine

Jotura treats an Agents/ folder inside the vault as the canonical copy of your agent config. For Copilot, Agents/Copilot/copilot-instructions.md in the vault maps to ~/.copilot/copilot-instructions.md on the machine. Edit the vault copy, run jotura agents sync, and Jotura updates the system file, skipping anything that changed on both sides until you pick --prefer vault or --prefer system. It syncs Copilot’s instructions file but not its skills folder, because skill syncing covers Claude Code and Codex only.

Because the vault is a plain folder, a file-sync tool you already run will carry it, with the caveat that Dropbox and OneDrive resolve simultaneous edits by leaving conflict copies rather than merging them. Jotura Sync is the built-in option at £4 per month or £40 per year, end-to-end encrypted, with no free trial. The same pattern applies to every agent config file, covered in sync AGENTS.md across computers.

What this does not fix

Copilot CLI still starts every session cold. Recall stays explicit, so the agent has to run the command, and sometimes it will not. Read through the store yourself every few weeks.

Jotura has its own gaps. There is no iOS app, no plugin system, no graph view, no publish-to-web, and the app is closed source. If those matter more to you than a first-party agent CLI, it is the wrong tool.

Questions people ask

Does Copilot CLI remember anything on its own? It does not remember anything across sessions. It keeps context within a running session, and it re-reads your instruction files every time you start it. Anything else has to be written to disk.

Should memory live in the repo or in my home directory? They belong in different places. Facts about a codebase belong in that repo’s AGENTS.md or .github/copilot-instructions.md, where teammates and other agents see them. Personal working memory that spans several repositories belongs outside any repo.

Can several agents share one memory store? Yes, and that is the main reason to keep it in plain markdown. Copilot CLI reads AGENTS.md, and it also honors CLAUDE.md and GEMINI.md, so one file can serve several agents at once. The Claude Code persistent memory guide walks through the same setup from the other side.