MCP OAuth tokens intermittently invalidated — shared ~/.copilot profile conflicts with other local apps

Description:
GitHub Copilot Desktop/CLI stores its profile (m-mcp-servers.json, m-preferences.json, m-settings.json, mcp-oauth-config/) under %USERPROFILE%\.copilot. On this machine, that directory's creation date and several of its files predate this Copilot install entirely, and a separate installed application (Microsoft Scout) bundles code that directly references and manages the identical filenames (m-mcp-servers.json, m-preferences.json, m-settings.json, m-sync-state.json), including its own MCP store (setMcpStore).

Repro / symptom: Remote MCP servers requiring OAuth (custom endpoints, e.g. NinjaOne, Hudu-style integrations) fail with "no cached tokens; marking as needs-auth" in logs, even seconds after completing the interactive OAuth sign-in in the app. A valid, non-expired token file exists on disk for that server at the same time. Additionally, multiple orphaned OAuth config entries accumulate for the same server URL with different client IDs/redirect ports and non-contiguous timestamps — consistent with more than one process/app independently negotiating OAuth against the same server without coordination.

Expected: Once a user completes OAuth for an MCP server, that session should reliably reuse the cached token across new Copilot processes, and Copilot's profile/token cache shouldn't be readable/writable by unrelated applications.

Ask: Please confirm whether ~/.copilot is intended to be shared across Microsoft products, and if so, add per-writer/owner identification or locking to mcp-oauth-config so concurrent writers can't silently shadow each other's valid tokens.

---
| Field | Value |
| --- | --- |
| App version | 1.0.21 |
| OS | Windows 10.0.26200 |
| Theme | Noctis Azureus |
| Path | /chat |
| Tenure | Day 1 |

Beginne damit, die im Bericht genannten Profildateien nachzuverfolgen: m-mcp-servers.json, m-preferences.json, m-settings.json, m-sync-state.json und mcp-oauth-config/. Überprüfe die Logs, in denen neben der vorhandenen Token-Datei „no cached tokens“ angezeigt wird, und ermittle anschließend, ob gleichzeitig ausgeführte Prozesse dieselbe OAuth-Konfiguration schreiben können. Als erledigt gilt die Aufgabe, wenn das Besitzmodell bestätigt und eine zuverlässige Wiederverwendung von Tokens definiert wurde, ohne dass nicht verwandte Anwendungen Einträge unbemerkt überschatten.

Vom Indexierungsmodell aus dem Issue-Text verfasst.