GitHub 於 2026 年 9 月 23 日公布 Copilot App 的本地 sandboxing 公開預覽。新功能的目的，是降低代理執行意外指令時的影響範圍，按專案限制它可以讀寫哪些檔案、連接哪些網絡，以及是否可以使用 Git 和 GitHub CLI 憑證。
設定以專案為單位，包括額外可讀寫資料夾、額外只讀資料夾和拒絕存取資料夾；網絡部分可控制外部互聯網和本地網絡；憑證部分則包括用於已驗證 HTTPS Git 操作的 Git credential，以及 GitHub CLI authentication。這比單純為整個電腦開一個總開關更接近真實開發流程，因為不同 repository 的信任邊界可以不同。
GitHub 說，這些設定是 Copilot 啟動 sandboxed session 時要求的政策，實際有效政策可以因 enterprise-managed settings 而更嚴格。還有一個重要的故障安全行為：如果作業系統無法執行所要求的政策，sandboxed shell 會直接失敗，而不是退回到沒有 sandbox 的模式。這種 fail-closed 設計可避免使用者誤以為代理仍在受限環境內運作。
功能目前預設關閉。使用者要在 App settings 選擇專案，再開啟 Sandbox new sessions；設定只套用到新的工作階段，現有 session 不會即時重置。現有工作階段亦可以輸入 `/sandbox on` 啟用，但修改檔案、網絡和憑證政策，通常要等新 session 或重新啟動才生效。
本地 sandbox 不會套用到 cloud sandbox 或 remote host，而且 Copilot App 與 Copilot CLI 的 sandbox 設定分開管理。這個範圍界線很重要：企業不能假設在一個介面設定的限制會自動延伸到另一個代理執行環境，必須分別審查執行位置、網絡路徑和可用憑證。
從代理治理角度看，sandbox 解決的是執行層面的隔離，不是模型判斷本身。它可以縮窄錯誤指令的檔案、網絡和身份影響，但不能代替程式碼審查、版本控制、最小權限、secret rotation 或人工批准。允許某個資料夾寫入，也不代表所有寫入內容都安全；團隊仍需在結果層面做測試和審閱。
這次公開預覽亦提醒採用者先畫清楚工作區邊界，再讓代理執行。適合的起點是沒有生產憑證的測試 repository，先限制外部網絡和敏感資料，記錄代理要求的權限，再按需要放寬。若遇到 sandbox 不支援或政策解析失敗，應把錯誤當成需要修正的部署問題，不應以關閉限制作為快速解法。
對本地 AI coding agent 而言，安全不只是模型能否拒絕危險指令，也包括系統在指令成功執行時可以碰到甚麼。GitHub 把檔案、網絡和憑證拆成可配置的專案政策，並在無法強制時選擇失敗，令代理工作流更接近可審計的工程系統，而不是一個擁有整台電腦權限的黑盒。
