GitHub Copilot Memory in VS Code: local files, cloud memory and control

FuturPulse analysis · 18 October 2026

GitHub Copilot Memory remains a public-preview, cross-agent feature, while Visual Studio Code keeps three separate memory scopes locally; only VS Code user memory automatically loads its first 200 lines at each new session. (docs.github.com)

What has GitHub Copilot Memory actually shipped?

GitHub Copilot Memory is not the same thing as Visual Studio Code’s local memory tool. GitHub’s feature stores repository facts and personal preferences for use by supported GitHub Copilot workflows. Those workflows currently include Copilot cloud agent, Copilot CLI, Copilot code review and agentic autofix. (docs.github.com)

Repository facts cover items such as build commands, architecture decisions and code conventions. GitHub says each fact carries citations to supporting code, then checks those citations against the active branch before using the fact. That is a useful guard against an old convention steering a new change. (docs.github.com)

User preferences are different. They describe how one person wants Copilot to work, such as a preferred explanation style or coding habit. GitHub says these preferences follow that user across repositories, while repository facts remain limited to the repository where they were learned. (docs.github.com)

How does local memory work in VS Code?

Visual Studio Code’s built-in memory tool gives agents local notes that can outlive one chat. The editor divides those notes into user, repository and session scopes. The names matter because each scope has a different audience and lifetime. (code.visualstudio.com)

User memory is for preferences that should follow you between projects. Visual Studio Code says the first 200 lines are added to the agent context when a new session begins. Keep that file short, because every auto-loaded line competes with the task for the model’s working context. (code.visualstudio.com)

Repository memory persists between conversations for one workspace. It suits provisional facts: a legacy module pattern, an awkward test command, or a deployment constraint discovered during a fix. Session memory is deliberately temporary, making it the right place for a plan or a scratch investigation. (code.visualstudio.com)

Comparison based on Visual Studio Code memory guidance, GitHub’s Copilot Memory documentation, and Visual Studio Code’s customization guidance. (code.visualstudio.com)

Where are VS Code memory files stored?

Visual Studio Code documents logical memory paths, not a supported operating-system folder for manual browsing. The paths are /memories/ for user memory, /memories/repo/ for repository memory, and /memories/session/ for session memory. These are tool-managed local stores, not project files in Explorer. (code.visualstudio.com)

That distinction explains why a chat can claim it created a memory file while the developer cannot find a Markdown file in the repository. In a March 2026 GitHub Community reply, a participant described VS Code memory as local and tool-managed, rather than regular files in the project tree. That reply is helpful context, but it is not product documentation. (github.com)

The reliable way to inspect local memory is the Command Palette command Chat: Show Memory Files. It lists memory across the scopes and opens a selected file. To delete all local memories, use Chat: Clear All Memory Files; for one file, Visual Studio Code instructs users to ask the agent to update or delete it. (code.visualstudio.com)

How do you enable and use persistent memory?

For GitHub Copilot Memory, paid individual users should first check their GitHub Copilot settings. GitHub’s current guidance says the feature is enabled by default for paid individual accounts, and users can switch it to Enabled or Disabled under Features. Organization-managed accounts depend on the organization’s policy. (docs.github.com)

Then use a supported Copilot workflow normally. GitHub says memory is created only from Copilot activity started by users who have memory enabled. A repository owner can later open the repository’s Settings, then Copilot and Memory, to review and delete stored repository facts. (docs.github.com)

For Visual Studio Code, use plain language rather than hunting for an undocumented directory. Ask an agent: Remember that I prefer concise commit message subjects. The agent selects a scope, then creates or updates the corresponding local memory file. (code.visualstudio.com)

A disciplined local-memory workflow is simple:

1. Put personal habits in user memory.
2. Put emerging workspace knowledge in repository memory.
3. Use session memory for a plan that can safely disappear.
4. Move settled team rules into reviewed instructions or project documentation.
5. Clear or revise old local memories when the code changes.

This last step is not optional housekeeping. Visual Studio Code explicitly advises teams to verify stable repository memory, move it into project documentation or custom instructions, review it normally, then update or remove the local copy. That prevents a private note becoming a competing source of truth. (code.visualstudio.com)

When should a team use instructions instead?

Use source-controlled instructions for rules that must be visible, reviewed and shared. Visual Studio Code describes instructions as persistent context for standards and architecture decisions. Unlike a local repository-memory file, an instructions file belongs in the team’s ordinary maintenance process. (code.visualstudio.com)

That makes instructions the better home for rules such as “run this test command before changing the parser” or “all public endpoints use this error format.” Use memory for discoveries that still need confirmation. Use instructions once the team agrees the discovery is policy. (code.visualstudio.com)

There is also a control difference. Instructions guide the model, while hooks can enforce an action at a lifecycle point. Visual Studio Code’s documentation says a hook runs independently of whether the model remembers an instruction. If a formatter must run after every edit, a memory note is the wrong control. (code.visualstudio.com)

How do third-party memory tools compare?

Independent tools fill a different niche: searchable local archives rather than the editor’s three built-in memory scopes. The open-source Copilot-Mem project says it captures chat activity, edits and tool use, stores data in a local SQLite database, and lets Copilot call memory through Model Context Protocol tools. MCP is a standard way for an agent to call external tools. (github.com)

Copilot-Mem advertises a browser viewer, individual deletion, ignore rules and private-content tags. Those controls can be useful for someone who wants a searchable session history. They also add an MCP server, local database and separate configuration to a development environment. (github.com)

The project should not be confused with GitHub or Microsoft shipping a Copilot feature. Its repository says the Marketplace extension is still “coming soon,” despite documenting a proposed extension workflow. Use it only after assessing the code, storage policy and access permissions for your environment. (github.com)

Ken Muse’s May 2026 explanation provides a useful mental model: instructions are long-term and deliberately maintained, while adaptive memory sits between permanent rules and disposable session notes. That framing is more useful than asking which memory product is “best.” The real question is who needs the fact, how long it should live, and whether it must pass code review. (kenmuse.com)

What was promised, and what shipped?

The terminology changed quickly in 2026. This timeline separates published intentions from documented behavior, and avoids assuming that a feature announced for GitHub Copilot is the same as local memory inside Visual Studio Code.

The meaningful change is not merely that memory persists. GitHub’s system applies validated repository facts across supported workflows. Visual Studio Code’s system lets one developer control local notes by scope. Teams should choose the latter for private working context and the former when GitHub’s supported agents need a shared, repository-scoped learning loop. This is an inference from the two products’ published scope and storage models. (docs.github.com)

What we could not verify?

Visual Studio Code does not publish a supported absolute disk location for its built-in memory files in its memory guide. Microsoft could settle that question by documenting the operating-system paths and backup behavior. Until then, use Chat: Show Memory Files instead of scripting against an assumed folder. (code.visualstudio.com)

GitHub’s public documentation does not state whether a fact learned through one specific Visual Studio Code local-memory file can enter GitHub Copilot Memory. The published materials describe distinct local and GitHub-managed stores. GitHub could settle the integration boundary with a supported data-flow diagram or an explicit compatibility statement. (docs.github.com)

Copilot-Mem’s repository lists a future Marketplace extension, but does not establish a release date for it. The project maintainers could settle that with a published extension release and versioned installation guidance. (github.com)

Sources

• GitHub Docs: About GitHub Copilot Memory
• GitHub Docs: Managing Copilot Memory for your personal account
• Visual Studio Code: Use memory with agents in VS Code
• Visual Studio Code: Understand agent customization
• GitHub Blog: Building an agentic memory system for GitHub Copilot
• GitHub Community discussion #189688
• Copilot-Mem repository
• Ken Muse: Understanding Agentic Memory in GitHub Copilot