GitHub Copilot Memory: What Persists Between Coding Sessions
GitHub Copilot can retain repository facts and coding preferences, but that is different from a project handoff. Here is how to check what exists and what your next session still needs.
Updated 5 min read
GitHub Copilot memory can preserve facts about a repository and preferences about how you work across supported Copilot sessions. It is separate from the instructions you put in project files, and it should not be your only record of unfinished work. Tools like fenbs keep explicit project decisions, lessons and handoffs available outside a single coding session.
The useful question is whether the next session has the right information for its next action. A remembered testing convention helps, but it does not establish that yesterday’s change passed its tests or that a person approved a proposed design.
What can Copilot carry into another coding session?
GitHub distinguishes repository-level facts from user-level preferences. Repository facts concern the codebase; preferences concern how a particular person wants to interact with Copilot. The official memory overview (opens in a new tab) lists supported features and current availability, so check it for the exact Copilot surface you use.
Do not treat the Copilot name as a promise that every screen shares identical memory. GitHub currently documents memory for Copilot cloud agent, code review, CLI and agentic autofix, with differences in which kinds each uses. Our GitHub Copilot app guide helps identify the different places you can work.
For example, learning that a repository keeps shared validation code in one package can make a later change more consistent. Learning that you prefer a short explanation can make the response easier to read. Neither fact tells the assistant whether the product owner accepted a new validation rule.
How is memory different from repository instructions?
Repository instructions are guidance you deliberately place in files. GitHub documents a repository-wide .github/copilot-instructions.md file and other instruction types in its repository instructions guide (opens in a new tab). Support depends on where Copilot runs, so follow the instructions for that environment.
| Record | Useful contents | What to verify |
|---|---|---|
| Learned memory | A repository fact or a coding preference worth reusing. | Does the saved entry still match the work? |
| Repository instructions | Guidance intentionally maintained with the code. | Was the right file read for this request? |
| Project handoff | Completed work, checks, unresolved questions and the next step. | Does the status reflect what actually happened? |
Put a mandatory build rule in the maintained instructions instead of relying on Copilot to infer it. Put a temporary blocker in the task or handoff instead of turning it into a permanent coding preference. Each record becomes easier to review when it has a clear purpose.
For decisions that extend beyond the repository, fenbs keeps the project record with the tasks and people it concerns.
Where can you inspect what was saved?
Use the stored entries as evidence before testing an assistant’s recollection. GitHub’s personal memory management guide (opens in a new tab) explains how to control memory in personal Copilot settings, inspect personal preferences and review repository facts when you own the repository.
- Confirm which GitHub account and repository you are using. Write down the Copilot feature you are testing, such as CLI or code review.
- Open your personal Copilot settings and check the Copilot Memory setting under Features. An organization policy may affect whether you can use it.
- Review personal preferences in Copilot settings under Memory. If you own the repository, inspect its Settings, Copilot, Memory page for repository facts.
- Read an entry in full. Compare it with the current code or the preference you actually intended, and remove incorrect entries using the available controls.
Ask the repository owner or administrator for help when the relevant controls are outside your access. A missing setting and an incorrect saved fact are different problems; recording which you found gives the person helping you a useful starting point.
How can you test recall without confusing it with a guess?
Choose a harmless fact that you can verify. Avoid passwords, customer details and anything that would cause damage if repeated. In a fresh supported session, ask Copilot to explain the relevant convention before it changes code, then check the explanation against the saved record and the repository.
A correct answer alone does not prove memory was responsible. The assistant might have read the code, instructions or your prompt. Keep the question small enough that you can distinguish those sources, and ask it to identify the evidence it used rather than merely announce that it remembers.
Say you want to verify the test command for a package. Compare the proposed command with the package’s scripts and the repository instructions. If they disagree, resolve the source of that disagreement before accepting a claim that the assistant has learned the project.
Changing the underlying model is another variable, but model selection is a separate topic in GitHub Copilot models. Keep this check focused on information supplied to the session.
What should you save explicitly before stopping work?
Save the state another developer would ask for: the task, the change, what was checked, what remains and what needs a person’s decision. Include a branch or file reference when it helps someone find the work. A summary that says only “authentication updated” leaves the most consequential questions unanswered.
- Completed: which behavior changed and where the change lives.
- Verified: the check you ran and its actual result.
- Uncertain: a failed check, untested path or assumption that still needs evidence.
- Next: the first useful action, plus any approval needed before taking it.
Keep a lesson separate from a one-time failure. “The preview build failed because the variable was missing” describes an event. “Check required variables before requesting a preview” is the reusable lesson. fenbs handoffs put that next step beside the work it continues.
Give the next coding session an explicit starting point
Keep the project’s approved decisions, reusable lessons and current progress in fenbs. A connected GitHub Copilot session can read the project context before working and save what changed before it stops. You can inspect the record yourself instead of relying on a successful recall prompt.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
How to do this with fenbs
- Create a free account, then add the project and its current tasks to your kanban board.
- Record decisions people have made in Decisions and rules. Add a lesson only when there is a clear event, takeaway and better action for next time.
- Follow the GitHub Copilot guide in Integrations. It uses MCP, a standard way for an AI app to use an outside tool, with browser sign-in.
- Ask Copilot to read the project context before starting. Before ending, ask it to save task progress and Where we left off with checks, uncertainties and the next step.
fenbs is not the right fit if your only need is a personal response preference or a short repository instruction file. It does not import Copilot memories. Use it when the ongoing work needs a record you can maintain across people or supported assistants.
If you meant Microsoft’s general assistant, see Microsoft Copilot memory. For terminal setup, use the Copilot CLI guide; for the wider principles, browse the AI memory hub.