copilot_spaces: org-owned Spaces unreachable via the app's managed github MCP token (missing organization_copilot_spaces: read)

从 README 中关于 copilot_spaces 身份验证的说明以及 get_copilot_space 和 list_copilot_spaces 入口开始。将应用管理的 github MCP 令牌行为与 CLI 进行比较，重点关注 organization_copilot_spaces: read 和通用的未找到响应。完成的标准是应用支持所需的访问权限，或记录受支持的 PAT 使用路径，并在适当情况下提供可区分的权限错误。

Summary

get_copilot_space and list_copilot_spaces cannot read org-owned Copilot Spaces when called through the GitHub Copilot app's managed github MCP server. The same calls work from the Copilot CLI. Per this repo's README, org-owned spaces require a fine-grained PAT with organization_copilot_spaces: read installed on the owning org — and the app's auto-provisioned Copilot token appears not to carry that scope, with no user-facing way to add it.

Environment

• Surface: GitHub Copilot app (built on Copilot CLI), MCP server github (https://api.githubcopilot.com/mcp/), toolset copilot_spaces enabled.
• Comparison surface: Copilot CLI ~v1.0.66 on macOS.
• Space under test: GitHub Roadmaps Space, owner github, URL github.com/copilot/spaces/github/445 (org-owned).

Steps to reproduce

1. In the app, call get_copilot_space with owner: "github", name: "GitHub Roadmaps Space". → not found.
2. In the app, call list_copilot_spaces. → returns only the user's own/bookmarked spaces; the org space is absent.
3. Star/bookmark github/445 in the browser, wait ~1 day, repeat steps 1–2 in a fresh app window. → still not found / still absent.
4. In the CLI, call get_copilot_space with owner: "github", name: "GitHub Roadmaps Space". → success, ~17 documents. list_copilot_spaces returns ~505 org spaces.

Expected

A user who has access to an org-owned space (and has starred it) should be able to read it via get_copilot_space / see it via list_copilot_spaces in the app, matching CLI behavior — or there should be a documented, user-actionable way to grant the app's github MCP token the required organization_copilot_spaces: read scope.

Actual

Org-owned spaces are "treated as not found" in the app. The tools are present (so it's not a toolset-availability issue) but fail on org spaces. This matches the README's copilot_spaces authentication note:

• Fine-grained PATs are not hidden by classic PAT scope filtering, so these tools may still appear even when the token cannot use them.
• For org-owned spaces, fine-grained PATs must be installed on the owning organization and include organization_copilot_spaces: read.
• If an org-owned space contains repository-backed resources, the token must also have access to every referenced repository or the space may be treated as not found.

Root cause (hypothesis)

The app's managed github MCP token does not carry organization_copilot_spaces: read for the owning org (github), whereas the CLI's credentials do. Starring a space is a personal action and does not change the token's org scope, which is why bookmarking had no effect.

Asks

1. Confirm whether the app's auto-provisioned Copilot token can include organization_copilot_spaces: read for orgs the user belongs to.
2. If not, document a supported way for a user to supply a fine-grained PAT (with that scope) to the github MCP server in the app context, the same way it works in the CLI.
3. Consider returning a distinguishable auth/permission error for org spaces instead of a generic "not found," so clients can tell "missing scope" apart from "wrong name" and guide the user.

Impact

Tools/agents that pin org-owned Spaces (e.g. an internal PM router) work in the CLI but silently fail in the app, forcing a degraded "here's the URL, open it in your browser" fallback for every org Space.