---
title: "How Copilot Memory Works: Microsoft and GitHub"
description: "Copilot memory means two different systems. A teardown of Microsoft Copilot and GitHub Copilot memory: storage, retention, controls, deletion."
canonical: https://past.dev/blog/copilot-memory
date: 2026-09-02
category: Research
authors: The past.dev team
---
# How Copilot Memory Works: Microsoft and GitHub

Copilot memory is one search term for two unrelated systems. Microsoft Copilot, the assistant in Windows and Microsoft 365, saves facts about you from chat, stores them in your Exchange mailbox, and applies them to later conversations. GitHub Copilot, the coding assistant, has run its own Copilot Memory in public preview since January 2026: it deduces repository facts and user preferences while it works, validates them against your code, and deletes any entry that goes unused for 28 days. Same brand, different storage, different controls, different scopes. This post documents both from official Microsoft and GitHub documentation, as of September 2026.

## Microsoft Copilot memory: what gets saved and when

Microsoft documents four personalization mechanisms for Copilot Chat: saved memories, details inferred from your chat history, custom instructions you write yourself, and temporary chats that bypass the other three ([Microsoft Support](https://support.microsoft.com/en-us/topic/get-started-with-personalizing-what-microsoft-365-copilot-remembers-cba7b79a-c46f-4ca7-b46e-2fa22c563f90)).

Saving is on by default. When Copilot judges something worth keeping, it "asks you if you would like to save that information for future chats," and you can also tell it directly to remember a fact ([Microsoft Support](https://support.microsoft.com/en-us/topic/manage-copilot-memory-in-microsoft-365-copilot-b3231eae-9e60-4b3c-ac58-81fddbe56279)). Microsoft's examples of what gets stored: your job role, common tasks, skills you want to improve, and your "communication style, favorite topics, goals, and recurring tasks" ([Microsoft Support](https://support.microsoft.com/en-us/privacy/microsoft-copilot/privacy-controls)). The same design covers personal Microsoft accounts in the consumer app and work accounts in Microsoft 365 Copilot, where the feature is documented as a preview under the Frontier program ([Microsoft Learn](https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-personalization-memory)).

Storage is unusually concrete for [agent memory](/what-is-agent-memory): memories "are stored in the user's Exchange mailbox in a hidden folder," which means they inherit mailbox compliance behavior such as encryption at rest and Customer Lockbox ([Microsoft Learn](https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-personalization-memory)). In eDiscovery the items carry the IPM.Contact item class and sit in a folder named CopilotMemory.

## Controls, deletion, and retention in Microsoft 365

User controls live under Settings > Personalization (via Chat settings in Microsoft 365 Copilot). You can toggle Saved memories off, delete individual memories with the trash icon, or select Delete all memories ([Microsoft Support](https://support.microsoft.com/en-us/topic/manage-copilot-memory-in-microsoft-365-copilot-b3231eae-9e60-4b3c-ac58-81fddbe56279)). A temporary chat "won't access or store any personalized information" and skips chat history.

The retention rules come from Microsoft's admin documentation ([Microsoft Learn](https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-personalization-memory)):

- Turning a memory control off stops Copilot from applying that data. It deletes nothing. Microsoft states this for saved memories and for custom instructions.
- Saved memories persist until you delete them. Deleting a chat does not delete memories generated from that chat.
- Chat-history details are dynamic: Copilot "might update or discard older details" on its own. If you delete every chat where a detail appeared, its traces are removed within seven days. Turning the chat-history control off deletes all inferred details after 30 days.

For admins, the tenant switch is called Enhanced personalization. It is on by default and is configured through the Microsoft Graph enhancedPersonalizationSetting resource; turning it off locks each user's personalization toggles in the off position ([Microsoft Learn](https://learn.microsoft.com/en-us/microsoft-365/copilot/copilot-personalization-memory)). The documented admin gaps are just as specific: Purview retention policies and labels "don't apply to Copilot memory," memory actions generate no audit log entries, and admins cannot restrict what types of information get memorized. Saved and inferred memories are discoverable through eDiscovery, custom instructions are excluded from discovery, and temporary chats remain discoverable like normal chats even though they skip personalization. Anyone mapping [AI data retention](/guides/ai-data-retention) obligations should note that memory here follows mailbox rules rather than chat retention policy.

## GitHub Copilot memory: the learned layer

GitHub's version is newer and narrower. Copilot Memory entered public preview for all paid Copilot plans on January 15, 2026, capturing "tightly scoped insights" as Copilot works in your repositories, "validated against the current codebase before use" ([GitHub Changelog](https://github.blog/changelog/2026-01-15-agentic-memory-for-github-copilot-is-in-public-preview/)). The concept documentation splits entries into two kinds ([GitHub Docs](https://docs.github.com/en/copilot/concepts/agents/copilot-memory)):

- Repository-level facts: coding conventions, architectural decisions, build commands. Stored with citations to the code that supports them, and available to everyone using memory in that repository.
- User-level preferences: stated or implied preferences about how you want Copilot to behave, applied only to your own interactions, across repositories.

Memory is currently read and written by Copilot cloud agent, Copilot code review, and Copilot CLI, and "facts and preferences captured by one Copilot feature can be used by another." Code review applies repository facts only. Expiry is precise: "any stored fact or preference that goes unused is automatically deleted after 28 days," with the timer resetting when an entry is validated and used again. That is a built-in [memory decay](/glossary/memory-decay) policy.

The controls: memory is enabled per user rather than per repository, on by default for individual plans, and policy-gated for organizations and enterprises, where an administrator enables it before members can use it and each user can still opt out ([GitHub Docs](https://docs.github.com/en/copilot/concepts/agents/copilot-memory)). Repository facts are reviewed and deleted under Repository Settings > Copilot > Memory; your own preferences live in personal Copilot settings. In the CLI, /memory on, /memory off, and /memory show manage the feature, and the choice persists across sessions ([GitHub Changelog](https://github.blog/changelog/2026-05-26-copilot-memory-has-more-controls-for-deletion-scope-and-the-copilot-cli/)). Disabling memory on a repository stops new storage and reads but leaves preexisting facts in place until someone deletes them. On Business and Enterprise plans, administrators can export or delete user preferences in bulk or per user.

## The authored layer: Copilot custom instructions

Before Copilot Memory existed, persistence in GitHub Copilot was entirely files you write, and those still apply. A `.github/copilot-instructions.md` file covers the whole repository. Path-specific `NAME.instructions.md` files under `.github/instructions/` target files through an applyTo glob in their frontmatter. `AGENTS.md` files can sit anywhere in the tree, with the nearest one taking precedence, and a single `CLAUDE.md` or `GEMINI.md` at the root also works ([GitHub Docs](https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions)). Personal instructions, set from your profile in Copilot Chat on GitHub, take priority over repository instructions, which outrank organization instructions written by org owners ([GitHub Docs](https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-personal-instructions)). All of these are injected into requests as written. Nothing is learned from them or written back.

One related feature is gone: Copilot knowledge bases, the Enterprise-only Markdown collections, were retired on November 1, 2025 and "fully replaced by Copilot Spaces" ([GitHub Changelog](https://github.blog/changelog/2025-08-20-sunset-notice-copilot-knowledge-bases/)).

## Documented boundaries

Microsoft's memory is scoped to one user in one tenant, offers admins no memory-specific retention rules and no audit trail, and carries a preview label. GitHub's memory is scoped to a repository or a single user, is read by three features as of September 2026, and expires unused entries after 28 days. Neither company documents a way to use these memories outside its own Copilot surfaces.

## For builders: memory as an infrastructure layer

If you are building your own assistant or agent, both systems sketch the requirements well (extraction, validation, scoping, expiry, admin controls), and none of their memory is available to your product. past.dev provides that layer as an API: POST /api/v1/ingest accepts raw text with its original timestamp (fields content and timestamp), entity resolution links references to the same person across sources, and facts carry event time, validity windows, and supersession links. POST /api/v1/recall (field query) returns ranked, dated evidence with sources and one of four status values: Supported, Conflicted, NoKnownSupport, or UnknownBecauseDegraded. It runs managed or self-hosted in your own Postgres; start with the [quickstart](/docs/memory-api/quickstart) and the [benchmarks](/benchmarks).
