GitHub Copilot Content exclusions 設定與驗證清單

Content exclusions 實際會阻止什麼#

GitHub 的概念文件列出四個直接效果：

這裡的「不納入」是 Copilot 的內容存取政策，不是 Git 的 ignore，也不是把檔案從 repository 移除。檔案仍會照常存在於工作樹、commit 和 CI 流程中；管理員要解決的是「哪些 Copilot surface 可以使用它」，而不是檔案本身的保存與權限。

先確認方案與管理權限#

Content exclusion 的文件適用於 Copilot Business 與 Copilot Enterprise。可配置的人員是：

• repository administrator：設定自己的 repository。
• organization owner：為該 organization 配置規則。
• enterprise owner：把規則套用到 enterprise 範圍。

如果你只是 repository 的 Maintain 角色，可以查看 repository 的設定，但不能編輯。先確認規則究竟應該放在 repository、organization 還是 enterprise；同一個團隊若同時有上層繼承和 repository 自訂規則，排查時要把來源一起記錄。

Repository 層的設定方式#

要設定單一 repository：

1. 開啟 repository 首頁，進入 Settings。
2. 在 Code, planning, and automation 底下選 Copilot，再選 Content exclusion。
3. 在 Paths to exclude in this repository 輸入路徑，每行一個項目。
4. 儲存後記下生效時間，接著依本文後面的驗證流程測試。

Repository 設定使用類似 YAML list 的格式，例如：

1
# 指定目錄以下的所有檔案
2
- "/config/private/**"
3

4
# repository 中任何位置的 .env
5
- "**/.env"
6

7
# 任何以 secret 開頭的檔名
8
- "secret*"
9

10
# 指定單一檔案
11
- "/src/internal/license.ts"

官方說明使用 fnmatch pattern matching，路徑 pattern 不分大小寫。/scripts/** 是從 repository 根目錄開始的路徑，而 secret* 可以匹配 repository 中符合檔名條件的檔案；不要把 glob 寫成自己熟悉的 .gitignore 規則後，就假設兩者語意完全相同。

Organization 與 Enterprise 層要記錄 repository reference#

Organization 或 enterprise 規則除了 path，還可能需要指定 repository reference。Organization 的格式可以是：

1
# 所有 Git repository 與非 Git 路徑的 .env
2
"*":
3
  - "**/.env"
4

5
# 只套用到某個 repository
6
https://github.com/example/acme-api.git:
7
  - "/config/private/**"
8
  - "*.pem"

同一個 repository 可能以 HTTPS、SSH 或 Git protocol clone。GitHub 文件表示會忽略 reference 中的 user 與 port，並用 repository reference 判斷規則；因此團隊應在設定表中留下實際採用的 repository reference，而不是只留一張 UI 截圖。

Enterprise 層的規則會影響 enterprise 中的 Copilot 使用者；organization owner 設定的規則則依該 organization 分配的 seat 套用。當你要處理跨 organization 的共同規範，例如所有 .env 或憑證檔案，enterprise／organization 層通常比每個 repository 手動複製更容易維護。

一份可重複執行的驗證流程#

設定儲存後，先不要直接把它當成完成。GitHub 文件指出，已載入設定的 IDE 可能需要最多 30 分鐘才會取得更新；也可以手動重新載入：

• VS Code：Command Palette 執行 Developer: Reload Window。
• JetBrains IDE 與 Visual Studio：關閉並重新開啟應用程式。
• Vim／Neovim：開啟檔案時會重新取得規則。

接著用一個「有排除」和一個「沒有排除」的檔案做對照：

1. 在未排除檔案中輸入一段平常會觸發 inline suggestion 的程式碼，確認控制組有建議。
2. 在已排除檔案中做同樣的輸入，確認沒有建議。
3. 開啟已排除檔案的 Copilot Chat，關閉其他可能被附加的檔案，將該檔案明確附加為 context，送出 explain this file。
4. 確認 Chat 回應不能使用它，也不會把它列為 reference。
5. 建立一個只修改受排除檔案的測試 pull request，確認 Copilot code review 不審查該檔案。
6. 若團隊使用 Copilot app 或 CLI，另用該實際入口做一次負面測試；不要用 IDE 測試結果代替 app／CLI 的驗證。

測試記錄至少包含 client 名稱與版本、repository、實際 path、設定儲存時間、reload 時間和測試結果。Content exclusion 是政策設定，驗證也應像測試權限規則一樣留下可重現的證據。

文件差異要怎麼處理#

目前官方資料有一個需要管理員正面處理的差異：

• 2026 年 9 月 2 日的 Changelog 說 Copilot app 與 Copilot CLI 現在會遵循 content exclusion policy。
• 設定教學 目前仍註明 Copilot CLI 不支援 content exclusion。
• 概念文件 的支援表列出 Copilot app 與 CLI，但另外註明 IDE 的 Edit 與 Agent mode 目前不支援。

因此，實務上的判斷方式是：

1. 把 Changelog 當成新能力的 rollout 訊號。
2. 把概念文件與設定教學的限制當成需要驗證的邊界。
3. 在 organization 的標準 client 與版本上執行實測。
4. 在文件同步前，不把 CLI、IDE Agent mode、symlink 或 remote filesystem 納入「已完成保護」的範圍。

這樣可以避免兩種常見誤判：一是忽略新版本已支援的入口，二是把某個入口的支援延伸解讀成所有 agent workflow 都已排除。

不要把它當成完整的秘密防護#

GitHub 同時列出幾項限制：

• IDE 可能間接提供被排除檔案的 semantic information，例如 symbol 的型別、hover 定義或一般 project build 設定。
• Content exclusions 目前不套用到 symbolic links。
• 位於 remote filesystem 的 repository 不適用。
• IDE 已載入政策時，變更可能要等待最多 30 分鐘，或手動 reload。
• 受到排除的是 Copilot 的內容使用，不會替你處理 repository 權限、artifact、log 或其他外部工具。

所以 .env、private key 和 production credential 仍不應提交到 repository。應搭配 secret manager、GitHub secret scanning、CI log 遮罩和最小權限；Content exclusion 適合降低 Copilot context 的暴露面，不適合當成秘密已安全保存的理由。

建議交付給團隊的設定表#

可以用下列欄位建立一份 policy record：

這份表的價值不是重複 GitHub UI，而是讓下一位管理員知道：哪些入口真的測過、哪些只是依文件推定、規則變更後是否已過 propagation delay。

結論：設定只是開始，入口驗證才是完成#

Content exclusions 可以把 Copilot 的內容使用範圍縮小，並且涵蓋 inline suggestions、Chat 與 code review；但新入口的 rollout 和文件更新不一定同時完成。先在正確的管理層設定明確 path，再等待或 reload client，最後以 control／excluded pair 驗證每個實際使用入口。對 secrets、symlink、remote filesystem 和 IDE Agent mode，則維持更保守的邊界，搭配真正的權限與秘密管理控制。

常見問題#