Copilot内容排除已覆盖App和CLI，但仍有两处绕行风险

2026年9月2日，GitHub正式让GitHub Copilot app和Copilot CLI遵守企业、组织及仓库管理员配置的内容排除策略。GitHub的发布公告 将其标记为正式可用，并明确适用于Copilot Business和Copilot Enterprise：被排除文件不会被这两个入口用作上下文。

这意味着，从2026年9月2日起，企业配置的既有规则正式覆盖独立App与终端CLI，但并不等于所有敏感内容路径都已封闭。9月3日发布的 独立配置与验证清单 也记录了这次扩展，同时提醒管理员区分新入口的发布状态、尚未同步的说明页面以及仍未覆盖的使用场景。

App和CLI现在执行同一套排除策略

此次变化的重点不是增加新的路径语法，而是把GitHub Copilot app和Copilot CLI纳入原有治理范围。仓库管理员、组织所有者和企业所有者配置的排除规则，现在可以限制这两个入口将哪些文件作为上下文。

• GitHub Copilot app：被排除文件不应进入其Copilot上下文；该入口没有编辑器式行内建议，因此行内建议一栏不适用。
• GitHub Copilot CLI：被排除文件同样不应用作上下文；终端入口也没有编辑器式行内建议。
• 适用方案：这项管理能力面向Copilot Business和Copilot Enterprise，不是个人方案中的本地排除开关。

管理员因此无需为App和CLI重新维护一份敏感目录清单。不过，正式支持只说明产品能够执行策略，不能证明某个具体工作区已经正确取得规则。仓库身份、路径模式、配置层级、用户席位归属和客户端状态仍会影响实际结果。

排除限制Copilot上下文，不改变文件权限

内容排除作用于Copilot如何使用文件，而不是操作系统、Git仓库或构建工具能否读取文件。规则命中后，受影响文件不会获得行内建议，其内容不应影响其他文件中的行内建议或Copilot回答，也不会进入Copilot代码审查。

这可以缩小专有实现、内部文档和配置样例进入模型上下文的范围，但不会从工作树、提交历史、构建产物或日志中删除它们。拥有原始权限的用户和工具仍可读取这些文件，因此内容排除不能代替访问控制、凭据轮换或密钥管理。

这一边界对CLI尤其重要。CLI能够在获准后读取、修改文件或执行命令，而内容排除只约束被排除文件是否成为Copilot上下文；它不是终端沙箱，也不是文件系统权限规则。

两处风险分别来自间接路径和语义信息

标题中的“两处绕行风险”并非指已经发现App或CLI普遍绕过策略的漏洞，而是把官方列明的限制归为两类。GitHub内容排除文档 明确指出，排除目前不适用于符号链接和远程文件系统中的仓库；IDE也可能间接向Copilot提供被排除文件的语义信息。

第一类是文件系统间接路径，其中包括符号链接和远程文件系统。路径规则描述的是管理员希望排除的位置，但客户端实际访问内容时，文件可能通过链接解析到另一位置，或者整个仓库位于未受支持的远程存储环境。一个本地仓库中的测试结果，不能直接证明其符号链接副本或远程挂载版本获得相同保护。

第二类是IDE间接提供的语义信息。即使被排除文件全文没有直接加入上下文，类型信息、符号的悬停定义以及构建配置等项目属性仍可能由IDE提供。对于需要隐藏内部接口名称、模块关系或构建条件的团队，这些信息同样属于需要评估的暴露面。

因此，标题中的“两处”指两个风险类别，而不是只有两个具体技术条件：符号链接与远程文件系统共同构成文件系统路径问题，IDE语义信息则构成另一条间接上下文路径。

支持矩阵仍不能只写“已启用”

App和CLI获得正式支持，不代表所有名称相近的Copilot入口都具有相同状态。当前支持说明仍把GitHub网站和GitHub Mobile上的内容排除列为公开预览，并指出Visual Studio Code及其他编辑器中的Copilot Chat Edit和Agent模式暂不支持内容排除。

企业的支持矩阵至少应分开记录Copilot app、Copilot CLI、普通编辑器聊天、行内建议、Edit模式、Agent模式、GitHub网站和移动端。CLI测试通过只能说明CLI在对应仓库、身份和策略条件下获得预期结果，不能替代编辑器Agent模式或远程工作区的验证。

• 已确认的新覆盖：Copilot app与Copilot CLI会遵守管理员配置的内容排除策略。
• 另有发布边界：网站与移动端仍处于公开预览，部分编辑器Edit和Agent模式尚不支持。
• 明确的技术限制：符号链接、远程文件系统和IDE间接语义信息不能纳入同一保护承诺。

用虚构哨兵验证实际入口

管理员可以用不含任何真实敏感信息的哨兵文件验证App和CLI，无需把凭据或专有代码带入测试。目标是判断指定入口能否取得一个无业务价值、可明确识别的虚构标记，而不是诱导Copilot复述真实秘密。

1. 在隔离测试仓库中创建一个普通文件，写入虚构且唯一的标记，并另建包含不同标记的未排除对照文件。
2. 由对应层级的管理员排除测试文件或目录，记录配置位于企业、组织还是仓库层，并使用属于该策略范围的测试席位。
3. 分别在Copilot app和Copilot CLI中打开同一仓库，提出只有哨兵文件才能回答的问题。两个入口都不应从被排除文件取得标记。
4. 确认Copilot可以取得未排除对照文件中的标记，以排除客户端根本没有读取工作区上下文的情况。
5. 如需评估已知限制，应在隔离副本中分别测试符号链接、远程文件系统和虚构的类型或构建信息，并将结果标记为限制验证，而不是生产保护证明。

记录客户端名称与版本、仓库位置、用户身份、规则层级、测试时间及结果，可以把“产品已经支持”与“当前环境已经生效”区分开。若App和CLI结果不同，首先应核对版本、仓库识别、席位归属和策略获取状态。

覆盖已经扩大，安全边界仍未闭合

目前可以确认的是，GitHub Copilot app和Copilot CLI已经正式进入企业内容排除的执行范围，被规则直接命中的文件不应再由这两个入口用作上下文。这个变化补上了App和终端工作流此前的治理缺口。

仍不能纳入同一保证的，是符号链接与远程文件系统构成的间接文件路径，以及IDE可能提供的语义信息；部分编辑器模式也有各自的支持缺口。在这些限制仍然存在时，内容排除应被视为Copilot上下文控制，而不是替代文件权限和密钥管理的完整安全边界。