多组织与多企业的政策冲突

用户可能同时从多个组织或企业获得 Copilot 许可。政策合并并不是统一地取“最严格”或“最后修改的值”，需要先判断授权层级，再按具体政策检查。

同一企业内的多个组织

企业把政策委派给组织后，不同组织可能作出不同选择。多数功能采用 least restrictive：只要其中一个授予许可证的组织启用，用户便可使用。

官方冲突表将以下项目列为较宽松规则：web search、Mobile Chat、IDE Chat、IDE Agent Mode、code review、cloud agent、Spark、GitHub.com、GitHub Desktop、CLI、Copilot app、Editor preview features、MCP servers in Copilot，以及 Copilot 生成提交信息。

这不代表用户可越过仓库权限或功能自身限制，也不能据此推断任何未列政策都采用同一算法。

更严格的例外

政策	合并规则
Copilot Metrics API	最严格组织
Semantic indexing for non-GitHub repositories	所有组织必须明确 Enabled；Unconfigured 视为 Disabled
Suggestions matching public code	最严格组织
Allow members without a Copilot license to use Copilot code review in GitHub.com	最严格组织

例如非 GitHub 仓库语义索引不能仅因一个组织启用就使用；其他授席组织未配置也会阻止。有关特定功能的其他条件仍按其专门页核对。

多个企业

从不同企业获得许可时，通常采用 most restrictive。例如任一企业关闭 GitHub 上的 Copilot Chat，就会限制该用户。

官方列出的例外是 AI credit paid usage 和 GitHub Spark。前者按各企业自身应用，而不是统一作用于用户；该来源没有展开 Spark 的完整跨企业合并算法，本页不自行给它补一个规则。

模型与个人计划

政策概念页特别说明，在 GitHub Team 计划下，模型访问由承担该用户用量的组织决定，可在个人 Copilot features 页面查看 Usage billed to。不要把这个限定条件扩展为所有企业模型政策都只看账单组织。

用户被加入 Business / Enterprise 后，个人计划会取消，所以不能把个人设置看作另一套可覆盖管理政策的并行来源。

排查顺序

先列出实际授予许可证的组织与企业，查看企业是否强制设置，再核对具体政策的合并规则、直接授席默认值与客户端范围。只在一个组织里看到 Enabled，不足以证明用户最终可用。