MCP OAuth tokens intermittently invalidated — shared ~/.copilot profile conflicts with other local apps
- 主要语言
- 没有语言数据
- 星标
- 2.1k
- 派生
- 153
- PR 合并指标
- 30 天内没有已合并 PR
描述
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 |
贡献指南
调研方向
首先追踪报告中提到的配置文件:m-mcp-servers.json、m-preferences.json、m-settings.json、m-sync-state.json 和 mcp-oauth-config/。检查在现有 token 文件旁显示“no cached tokens”的日志,然后确定并发进程是否能够写入同一个 OAuth 配置。完成的标准是确认所有权模型,并定义可靠的 token 复用方式,同时避免无关应用程序悄无声息地遮蔽条目。
由索引模型根据 Issue 内容生成。
评估
- 领域
- authentication, desktop, security
- Issue 类型
- 缺陷
- 难度
- 5/5
- 预计耗时
- 一周以上
- 活跃度
- 冷清
- 描述清晰度
- 基本清楚
- 新手友好度
- 30/100