讓程式代理在另一個分支工作，可以避免把變更混在一起；但如果它執行的指令仍能讀取整台電腦，分支本身不會保護其他資料夾。這正是桌面 AI 工具需要另外處理的權限問題。
GitHub 在 9 月 23 日公布 Copilot app 本機沙箱，讓使用者按專案限制檔案、網路與憑證存取。功能仍屬公開預覽，預設關閉；不能只因為更新了 app，就假設原本的工作已受到限制。
要開在哪裡？先分清楚專案預設與目前工作
新工作可在 app 設定中選擇專案，再於 Sandbox 開啟 Sandbox new sessions。已經進行中的本機工作則可輸入 /sandbox on；這會改變該工作階段，不會順便替其他工作更改專案預設。
修改檔案、網路或憑證政策後，也要注意生效時間。目前官方文件說明，新政策套用於新工作或重新啟動的工作階段；可用 /restart-session 保留歷史後重啟。若指令在工作尚未開始前輸入，其作用可能是修改專案預設，操作時應確認自己所在的狀態。
我的建議是先用一個可回復的測試專案檢查設定。記下預期能讀寫的資料夾，開啟新工作後再核對行為；不要等到代理碰到客戶資料時，才回頭猜測剛才的設定究竟有沒有生效。
三種權限，要配合任務與作業系統決定
官方提供的控制分成以下三類。表格右欄是我建議的判斷方式，不是工具替所有人選好的預設。
| 控制 | 可調整的範圍 | 開始前先問 |
|---|---|---|
| 檔案 | 額外讀寫、額外唯讀、禁止資料夾 | 只是查文件，是否真的需要修改那個資料夾？ |
| 網路 | 對外網路與本機／區域網路 | 任務是否需要下載套件、連 API 或開發伺服器？ |
| 憑證 | HTTPS Git 與 GitHub CLI 的認證 | 只要產生修改建議，是否需要推送或建立 PR？ |
文件顯示，預設政策仍可使用網路與 Git／GitHub CLI 認證，所以「已開沙箱」不能直接理解成完全離線或沒有帳號權限。企業管理政策也可能比專案畫面上的設定更嚴格。
以整理專案文件為例，可以先保留完成任務所需的檔案存取，再評估是否需要連網和認證。若接著要安裝依賴或提交 PR，才重新核對新增需求，並在自己的作業系統上確認限制有生效。
還要記得，允許修改的工作區內仍可能發生錯誤。沙箱縮小能接觸的範圍，不能取代 diff 審查、測試與備份；也不會替你判斷某段需求是不是應該照做。
依公告，作業系統若無法執行要求的政策，沙箱 shell 會報錯停止，不會默默改成無沙箱執行。Windows 的特定禁止路徑若無法受到保證，也可能出現 unsupported-policy；此時應先處理支援問題，而不是把報錯當成設定成功。
Linux 另有沙箱概念文件明列的限制：對 shell、本機 MCP 或 LSP 等子程序，沙箱不能獨立控制區域網路存取；該設定仍適用於部分程序內操作。若任務特別需要隔離內網，應先核對實際執行方式，不能僅憑一個開關做保證。
這份設定只適用 Copilot app 的本機工作。雲端沙箱、遠端主機不在其範圍內，Copilot CLI 也要另行設定。 如果你使用的是 IDE 外掛，本站的 Copilot JetBrains 沙箱與企業管理說明是另一個入口，不能直接混用操作步驟。
想評估整個桌面工具是否適合團隊，可接著看 Copilot app 的導入清單。先把一個小任務的檔案、連線與認證範圍確認清楚，再擴大到更多專案，會比一次全開後追查權限更容易管理。