把 .env 擋在 Copilot 之外：內容排除在 App 與 CLI 正式上線，三層設定位置、YAML 寫法，以及仍然擋不住的三個地方

2026-09-02，GitHub 在更新日誌宣布：內容排除（content exclusion）在 GitHub Copilot App 與 Copilot CLI 正式上線（GA）。官方一句話的重點是——Copilot 不會把被排除的檔案當作上下文。

這件事之所以值得寫成教學，是因為多數團隊的實際情況是：.env、secrets.json、私鑰、客戶資料樣本就躺在 repo 裡，而 agent 會整個目錄掃過去。這篇不是新聞複述，是照著做就能設起來的步驟，最後一節列出官方自己承認仍然擋不住的地方——那一節比設定步驟更重要。

一、先確認你有沒有這個功能

官方文件寫明：內容排除是 Copilot Business 與 Copilot Enterprise 的功能。

也就是說，個人的 Copilot Free／Pro／Pro+／Max 沒有這個開關。個人方案要保護敏感檔，只能靠「不要把密鑰放進工作區」這種土法。各方案差異我們整理過：Copilot 免費版與付費版差在哪。

二、三層設定位置（照抄路徑）

排除規則有三個層級，範圍由小到大：

實務建議：.env 這種全公司都會有的東西，設在組織或企業層，不要每個 repo 各設一次——設一百次就會漏第一百零一次。

三、YAML 怎麼寫（可直接複製）

儲存庫層最單純，一行一個路徑：

# 這個 repo 內不給 Copilot 看的東西
- "/.env"
- "/config/credentials.yml"
- "/src/some-dir/kernel.rs"

組織層／企業層要指名 repo，並且支援萬用鍵 "*"：

# "*" 代表所有 repo，以及不在 Git 內的位置
"*":
  - "**/.env"
  - "**/*.pem"

octo-repo:
  - "/src/some-dir/kernel.rs"

https://github.com/primer/react.git:
  - "secrets.json"

其中 "*" 這個鍵是關鍵：官方說明它涵蓋所有儲存庫，以及非 Git 的位置——也就是使用者本機開著、根本不屬於任何 repo 的檔案。大多數團隊真正需要的就是這一條。

四、比對規則：fnmatch，而且不分大小寫

官方寫明使用 fnmatch 樣式，且比對不分大小寫。常見寫法：

最常見的設定失誤是只寫 .env（或 /.env），結果 apps/api/.env、packages/web/.env.local 全部漏掉。monorepo 一律要用「任意深度」的寫法（也就是 **/.env 這種前綴），並且把變體一起列進去：

"*":
  - "**/.env"
  - "**/.env.*"
  - "**/*.pem"
  - "**/*.key"
  - "**/id_rsa"

（**/.env.* 這種變體樣式是本站依官方 fnmatch 規則推導的寫法，官方範例未逐一列出；建議設定後照第六節實測驗一次。）

五、生效要等：最多 30 分鐘

這是最多人以為「設了沒用」的原因。官方寫明：變更最多需要 30 分鐘才會在 IDE 生效。想立刻套用就手動重載：

• JetBrains／Visual Studio：關掉再開
• VS Code：命令面板 → Developer: Reload Window
• Vim／Neovim：開檔時自動套用

另外官方註明：為了取得正確的政策，儲存庫 URL 會送到 GitHub 伺服器，但不會被記錄（not logged anywhere）。

六、設完要自己驗一次

不要相信「我設了所以它擋住了」。最省事的驗法：

1. 在被排除的檔案裡打幾行程式，確認行內建議完全不出現（被排除的檔案會停掉 inline suggestions）。
2. 開 Copilot Chat，直接問「這個 repo 的資料庫密碼是什麼」，確認它不會引用該檔內容。
3. 改完規則後先重載視窗再測，否則你測到的是 30 分鐘前的舊政策。

七、最重要的一節：官方自己說擋不住的地方

以下全部出自 GitHub 官方文件，不是本站推測：

1. IDE 內 Copilot Chat 的 Agent 模式不支援內容排除。 官方原文寫明 agent mode 不支援；VS Code 的 Edit 與 Agent 模式同樣不遵守排除規則。這代表你最擔心的那個情境——agent 自己去讀整個工作區——恰好是保護最弱的地方。
2. IDE 間接提供的語意資訊仍可能外洩。 官方原文：Copilot 有可能使用被排除檔案的語意資訊，如果那些資訊是由 IDE 間接提供的。
3. 符號連結（symlink）與遠端檔案系統的儲存庫目前不支援。 用 symlink 把密鑰目錄接進工作區，等於繞過排除。

另外，各介面的支援程度不一致：行內建議在 Visual Studio、VS Code、JetBrains、Vim／Neovim、Xcode、Eclipse 都支援；但 chat／agent 的支援只在 VS Code、Visual Studio、JetBrains 以及 GitHub 網頁版與行動版，Xcode、Eclipse、Azure Data Studio 沒有 chat 側的支援。

所以正確的心理模型是：內容排除是「降低意外吸入」的政策層，不是密鑰保險箱。 真正的密鑰仍然應該放在 repo 之外（環境變數注入、密鑰管理服務），並且輪替。

八、建議的起手式（三步）

1. 企業層先設一條 "*" 規則，涵蓋 **/.env、**/*.pem、**/*.key。一次保護所有 repo。
2. 各 repo 再補自己的特殊路徑（資料樣本、客戶匯出檔、內部演算法目錄）。
3. 公告團隊：agent 模式不受保護。 這一條要用人的流程補：處理敏感目錄時不要開 agent 模式跑全庫任務。

順帶一提，Copilot 這條線最近動作很密集，同一週還有 Copilot code review 可以直接核准 PR 的變更，設定位置與費用區間我們寫在這裡。

九、這篇查不到、不寫死的部分

• 排除規則的數量上限：官方本次查核頁面未載明，待查核。
• Copilot App／CLI 在 GA 後是否仍有介面差異：更新日誌只寫「現在會遵守」，未列出與 IDE 的逐項對照表，待查核。
• 排除生效後，既有的索引／嵌入是否會回溯清除：官方未說明，待查核。
• 個人方案未來會不會開放此功能：官方未預告，待查核。

官方連結

• GitHub Changelog（2026-09-02）：https://github.blog/changelog/2026-09-02-content-exclusions-generally-available-in-copilot-app-and-cli
• 內容排除概念頁（限制與支援矩陣）：https://docs.github.com/en/copilot/concepts/context/content-exclusion
• 設定內容排除（YAML 與路徑）：https://docs.github.com/en/copilot/how-tos/configure-content-exclusion/exclude-content-from-copilot

延伸閱讀

• GitHub Copilot 工具頁（方案與額度查核紀錄）
• Copilot 免費版與付費版差在哪
• Copilot code review 可以直接核准 PR 的三層開關
• Copilot 模型費率換算