Copilot for JetBrains 加入企業託管沙箱：管理員能鎖住檔案、網路與鑰匙圈權限，員工改不動

GitHub 在 2026-09-08 發布 Copilot for JetBrains 的更新，主角是企業託管的沙箱政策（public preview）。對台灣的軟體團隊來說，這則更新的意義不在「多了什麼功能」，而在公司終於能用設定而不是規定來限制 AI 代理能碰什麼。以下依 GitHub Changelog 原文整理（查核日 2026-09-09）。

一、企業管理員能鎖什麼

官方列出的可集中控管項目：

• 是否啟用沙箱
• 檔案系統存取
• 網路存取
• 代理伺服器（proxy）設定
• 開發工具存取
• macOS 鑰匙圈（Keychain）存取
• 以及其他項目

最關鍵的一句是：受管的限制優先於使用者設定。Copilot 會把受影響的控制項在 IDE 裡鎖起來，並標示哪些設定是由你的組織管理的——也就是開發者看得到「這是公司鎖的」，而不是以為功能壞了。

二、看不到沙箱設定？官方講了條件

這點很容易變成客服問題，先記下來：GitHub Copilot > Sandbox 底下的沙箱設定，只有在以下兩種情況才會出現——

1. 你的組織啟用了 Editor Preview 功能旗標，或
2. 組織設定了「啟用或停用沙箱」的受管設定。

兩個條件都不成立時，沙箱設定根本不會顯示。所以看不到不代表版本不對，先問管理員。

三、同批的四個實用改動

除了沙箱，這次更新還帶了幾項日常有感的：

1. 跨檔案的游標跳轉（next edit suggestions）：當建議的修改延續到另一個檔案時，可以直接跳到對應位置，不用自己去找。
2. 聊天的全域專案脈絡：可以把全域的檔案與資料夾加進聊天脈絡，省掉每次重複設定，對跨區塊的修改更有幫助。
3. 企業政策診斷：可以驗證政策是否正確被偵測與強制執行在你的裝置上——用來確認你的 Copilot 設定真的符合組織要求。
4. 終端機的 Copilot CLI 用 /ide 連進 JetBrains：把終端機工作階段連上 IDE 脈絡，包括選取範圍、診斷訊息與檔案引用（public preview）。

官方另提到此版同時改進了模型選擇、聊天體驗，以及 MCP 伺服器與代理工作階段的可靠性。

四、本站觀點：「沙箱」正在變成 AI 編碼工具的標配

把這則跟同期其他工具對照就看得出趨勢：Zed 從 1.14 版起預設對代理的終端機與 fetch 工具啟用沙箱（詳見〈Zed 代理沙箱：預設擋住哪些動作、怎麼臨時放行〉），Cursor 則走自架機器讓工具執行留在自家網路內（見〈Cursor 自架機器與 computer use〉）。

三家的共同前提是同一件事：你沒辦法靠「叫代理不要做某件事」來確保它不做。 提示詞可以被覆寫、可以被注入，作業系統層級的限制才是硬的。GitHub 這次補上的是企業視角——不是每個開發者自己設，而是組織統一設、而且開發者改不掉。

五、導入前的三個提醒

• 這是 public preview，官方以預覽狀態發布沙箱政策，導入前請自行評估穩定度。
• 鑰匙圈與網路存取一鎖，某些工作流會壞（例如需要抓內部套件庫或憑證的流程），建議先在小組試跑。
• 政策診斷要用起來：官方特別做了診斷功能，代表「以為有生效、其實沒有」是真實存在的風險。

Copilot 相關實查文章：〈Copilot 四款模型 10 月 2 日淘汰〉、〈GPT-6 Astra 在 Copilot 的用量與計費〉。方案現況見 GitHub Copilot 工具檔案。

資料來源

• GitHub Changelog〈Enterprise-managed sandbox in Copilot for JetBrains〉，2026-09-08：https://github.blog/changelog/2026-09-08-enterprise-managed-sandbox-in-copilot-for-jetbrains

最後查核：2026-09-09