store_memory fails for repositories whose origin is not on github.com (e.g., Azure DevOps) #3060

Summary

The store_memory tool returns the following error for every write attempt in a repository whose origin remote points somewhere other than github.com:

Unable to store memory. The repository may not exist or you may not have write access to it. You can continue with your task without storing this information.

Reads of previously-stored memories still succeed (they're surfaced in the system prompt as Repository memories for owner/repo), so the failure is write-only.

Reproduction

1. Take any repo that has stored memories from when origin was on GitHub.
2. Migrate hosting (e.g., to Azure DevOps): rename the GitHub remote, set origin to the new host:

   git remote rename origin github-archive
   git remote add origin https://dev.azure.com/<org>/<project>/_git/<repo>

3. In a fresh copilot session, ask the agent to remember a fact (so it calls store_memory).

Expected: memory is stored.
Actual: every store_memory call returns the access-denied message above. Reads of the previously-stored memories continue to work.

Diagnosis (best guess)

Memory is keyed by GitHub owner/repo. The CLI infers that identifier from the origin remote URL. After migration, origin is no longer a GitHub URL, so the backend can't resolve the identifier and the write is rejected with a permissions-shaped error.

Reads work because the memories were written when origin was still GitHub and persist server-side; the read path may key off a cached / historical identifier or off the system-prompt repository hint.

Why this matters

Teams that host code outside GitHub but still use Copilot CLI lose all session-to-session persistence of standing rules and conventions. The error message also misleads users into investigating GitHub permissions when the real issue is the remote URL scheme.

Suggestions

1. Don't silently fail. When store_memory is called against a non-GitHub repo, return a clear error ("Memory store currently requires a GitHub origin; this repo's origin is <URL>.") instead of "the repository may not exist or you may not have write access" — the latter sends users on a wild goose chase through GitHub permissions.
2. Allow an explicit override, e.g., a --memory-repo owner/name flag, an env var (COPILOT_MEMORY_REPO), or a config key so a project hosted on ADO/GitLab/Bitbucket can pin its memory namespace to a sibling GitHub repo (often a mirror or an "ops" repo).
3. Document the GitHub-origin requirement in the README/help so users know up front.
4. Long term, decouple the memory namespace from the host (key by canonical workspace ID, repo path, or user-chosen string).

Workaround I'm using

AGENTS.md at the repo root, which the CLI auto-loads every session per its docs. Captures the same standing rules, persists in git, and doesn't depend on the memory backend. Works well, but it's a workaround — multi-repo / per-user nuance that store_memory could express isn't replicable in a checked-in file.

Environment

• macOS (Darwin)
• Repo originally on GitHub, migrated to Azure DevOps
• Multiple store_memory calls in a row, all returned the same error
• githubstatus.com shows Copilot operational at the time (no incident)

Happy to provide more detail or test patches.