Copilot Memory vs MemoryRouter: Who Keeps Your Preferences?
A Copilot memory can be about you without belonging to you.
When you change the organization providing your Copilot license, your GitHub username can stay the same while the preferences Copilot retrieves change. Before choosing where to keep work preferences, check who controls that record.
"Personal" describes the subject, not necessarily the owner
GitHub's Copilot memory documentation distinguishes repository facts from user preferences. Repository facts describe a codebase. User preferences describe how an individual works.
On Copilot Business and Enterprise, user preferences belong to the organization or enterprise granting the license. Each preference is stored against the active billing entity when it is created.
When building an agent session's context, Copilot checks that entity again and retrieves only preferences it owns. GitHub's billing-entity guide makes the transition explicit: existing preferences stay with their original owner after a license move, and Copilot stops retrieving them for you.
That is not deletion. Repository facts also remain attached to their repository, rather than following this user-preference filter.
Inspect the record before moving it
Suppose Copilot learned your review style while one organization provided your license. You later select another organization as your billing entity. The preference sounds personal, but its subject does not determine its owner.
GitHub's personal memory settings show the owner of each displayed preference. Organization and enterprise owners have export and deletion controls.
An export is not permission to move company information into a personal service. Keep company-owned context within the approved workflow. Establish your own preferences deliberately instead of copying an employer's memory collection.
MemoryRouter uses a vault you select
MemoryRouter offers a separate home for authorized context across its supported clients. Its MCP vault model binds a connection to the vault chosen during OAuth.
That vault determines where saves go and searches look. Changing it requires disconnecting and reconnecting. Asking the model to switch projects does not change that destination.
| Decision | Copilot Business/Enterprise user preferences | MemoryRouter over MCP |
|---|---|---|
| Which record is searched? | Preferences owned by the active Copilot billing entity | Memories in the OAuth-selected vault |
| What changes the boundary? | Moving to a different billing entity | Reconnecting to a different vault |
| Who initiates saves? | Copilot's native memory system | The client, by calling store_memory with write permission |
| Does connecting migrate Copilot memories? | GitHub provides separate management and export controls | No. Connecting a vault does not import Copilot memory |
Try one preference in Claude
Use the Claude browser connector instructions for the complete setup. The Claude integration page describes this supported route, separate from Copilot's native store.
- Add
https://mcp.memoryrouter.ai/mcpas Claude's custom connector. Complete OAuth, choose your vault, and enable the connector. Managed workspaces need administrator approval; this trial needs write access. - Ask: "Use MemoryRouter to store this synthetic preference: In demo code reviews, label untested suggestions as unverified." Approve the write and inspect the
store_memoryresult. - In a new conversation with the connector enabled, ask: "Search MemoryRouter for my demo code-review preference." Check the returned memory without supplying the preference again.
Claude's connector calls are model-directed. A successful trial proves that write and retrieval worked, not that every future turn will be captured automatically.
Create a MemoryRouter account and test one preference in a fresh conversation.