GitHub Copilot App 新策略如何单独控制企业访问

GitHub Copilot App 现在有了独立的客户端访问策略。企业管理员不必再通过 Copilot CLI 的策略间接控制 App，而是可以在企业或组织设置中单独决定谁能使用它。对 Copilot Business 和 Enterprise 来说，管理员需要保持该策略启用，用户才可以正常使用 App；个人方案则由对应账户权限决定。

实际管理时先记住一句话：Copilot App 策略管“能不能进入这个客户端”，Copilot CLI 策略管 CLI，两者分开设置；团队的分支、Pull Request、检查和审计流程不会因为新增这个开关而消失。

这次变化解决了什么管理冲突

此前 Copilot App 的访问受 Copilot CLI 策略影响，两个客户端的授权边界绑在一起。现在 App 和 CLI 各自拥有策略，企业可以允许一种客户端而暂时关闭另一种，或者把组织级决定权交给各组织管理员。这个变化更适合分阶段上线：先让少数组织试用 App，同时保留现有 CLI 管理方式。

管理员从哪里修改 Copilot App 策略

进入企业设置或组织设置，依次打开 AI Controls、Copilot Clients，再选择 Copilot App policy。页面中的三个选项含义并不相同：

• Enabled everywhere：企业范围内开放 App。
• Disabled everywhere：企业范围内关闭 App，用户打开时会看到管理员未启用的提示。
• Let organizations decide：企业不替组织做最终选择，由各组织管理员决定。

该策略按官方说明默认处于 Enabled everywhere。即使暂时不调整，也建议管理员先记录企业当前的授权意图，再决定是否切换为全禁用或交由组织决定，避免把“默认可用”误认为“所有组织都必须使用”。

三种策略值应该怎样选择

如果企业已经完成客户端评估，希望所有组织都能直接采用 App，可以选择 Enabled everywhere。如果安全审查或内部流程尚未完成，选择 Disabled everywhere 更容易形成明确的阻断面。需要让不同业务线自主试点时，则选择 Let organizations decide，同时把组织管理员、试用范围和复盘时间写进内部变更记录。

对开发团队的影响不只是一个开关

Copilot App 面向 agent-driven development，支持并行工作流、GitHub issue 与 Pull Request 生命周期管理。官方说明中，开发者在隔离工作区里运行 agent 会话，再通过分支和 Pull Request 落地修改，因此管理员评估的重点应是“哪些团队可以进入这条工作流”，而不是把 App 当成绕过审查的特殊入口。

企业和组织用户还要复核企业托管设置是否覆盖 Copilot App。已有的客户端护栏，例如插件使用限制，应与 App 的策略一起检查。访问被允许不代表代码可以跳过评审、CI 检查或合并规则。

常见问题

Copilot App 策略和 CLI 策略还能一起改吗？

可以，但它们是两个独立策略。需要分别确认 App 和 CLI 是否开放，不能通过修改 CLI 策略推断 App 的最终状态。

选择 Disabled everywhere 后用户会看到什么？

用户打开 Copilot App 时会看到管理员尚未启用该 App 的提示；这表示访问策略阻止了入口，不等同于账号或仓库被删除。

Let organizations decide 适合什么场景？

适合企业希望保留统一护栏、但让不同组织分阶段试用的情况。企业管理员应提前定义组织管理员的责任和试点范围。

启用 App 后是否还需要 Pull Request 审查？

仍然需要。官方描述的工作流仍以隔离工作区、分支、Pull Request、检查和审计记录为治理链路，客户端开关不会替代仓库规则。