Roo Code 自動審批 2026 安全驗收清單

症狀： Roo Code 不斷要求確認，令連續執行被打斷；但一旦全部放行，檔案、終端與 MCP 權限會一起擴大。
最快解法： 不要一次開啟全部自動審批，先在隔離環境按「讀取 → 受限編輯 → 命令 → 瀏覽器 → MCP」逐級驗收，只放行可回滾且作用域明確的動作。

這篇適合三類讀者：經常被 Roo Code 確認提示打斷的個人開發者；準備把它放到遠端開發環境或雲端 Mac 長時間執行的團隊；以及需要審核 Agent 權限、密鑰與 MCP 工具邊界的安全或平台工程人員。

自動審批的權限邊界

Roo Code 的自動審批不是單一的「安全／不安全」開關。官方工具說明把能力分成讀取、編輯、命令與 MCP 等工具群；不同模式可使用的工具組合也不同，例如只讀取與說明用途的模式，不應與可執行命令及修改程式碼的模式共用同一套放行政策。官方工具群與模式說明 (github.com)

你可以先把動作分成五層：

• 只讀操作： 列出目錄、搜尋檔案、閱讀程式碼，前提是工作區範圍已固定。
• 受限編輯： 只修改指定倉庫、測試分支或明確副檔名，而且能透過 Git 變更差異回復。
• 終端命令： 建置、單元測試等作用域可預測的命令，與安裝依賴、清理、部署分開。
• 瀏覽器及外部網路： 可能接觸未驗證內容、登入狀態或外部服務，不能只因為「讀取」就視為低風險。
• MCP 工具： 可能讀取資料庫、寫入第三方服務、觸發工單或使用外部憑據，應視為獨立的高權限面。

密鑰讀取、系統目錄修改、發布部署、刪除資料、改寫 .roo/ 設定，以及會觸發外部副作用的 MCP 工具，預設保留人工確認。官方安全公告曾記錄一個與專案 MCP 設定及自動批准檔案寫入相關的高嚴重度遠端程式碼執行問題，修補版本為 3.20.3，公告列出的 CVSS 基準分數為 8.1；這不代表所有版本都有同一漏洞，但說明「自動寫入設定檔」不能當作普通編輯處理。官方安全公告 (github.com)

第一階段：讀取與受限編輯

第一輪不要從完整程式庫和正式分支開始，而是準備一個可重新建立的測試分支，並先完成以下操作：

1. 固定 Roo Code 的工作區路徑，只把必要倉庫放入範圍。
2. 檢查它能否讀取工作區以外的目錄、家目錄或掛載磁碟。
3. 在工作區放入測試用符號連結，確認是否可能沿著連結離開預期目錄。
4. 只允許修改一至兩類程式檔，避免設定檔、祕密檔案與部署檔同時可寫。
5. 讓 Roo Code 完成一個小型編輯，再用 git diff、測試與回復指令驗證結果。
6. 故意要求它修改工作區以外的檔案，確認系統會拒絕，而不是只在對話中聲稱拒絕。

這一階段的通過條件是：變更差異可讀、測試分支可完全回復、越界讀寫被攔截，而且拒絕事件可在對話或日誌中追蹤。停止條件則包括：無法確定實際工作區、編輯會改寫未指定檔案、回復後仍殘留設定，或拒絕請求只靠模型自行承諾。

驗收證據至少保存三類：權限設定截圖、成功任務的變更差異，以及一次越界操作的拒絕記錄。不要以「這次沒有出錯」代替證據，因為未觸發越界路徑並不等於越界已被阻止。

第二階段：終端命令與連續執行

終端命令要按代表性場景逐條測試，而不是勾選一個全域授權後觀察幾分鐘。建議依序測試：

• 建置命令：確認只在測試倉庫執行，不會讀取正式環境變數。
• 單元測試：確認測試失敗時不會自動改寫測試資料或重試無限次。
• 依賴安裝：確認套件來源、鎖定檔及安裝目錄均符合團隊政策。
• 清理腳本：確認刪除範圍是暫存檔或建置輸出，而不是整個工作區。
• 失敗命令：故意提供錯誤參數，觀察 Roo Code 是否會自行擴大命令範圍。

每條命令都要回答四個問題：目前目錄是否固定？參數是否可預測？執行多次是否冪等？失敗後能否回復？只有四項均能回答，才有資格進入短期自動放行名單。

官方文件另提供自動批准動作的 Max Requests 限制；例如設定為 5 時，完成五次自動批准的 API 呼叫後，下一次會停下來要求重新確認，而不是無限連續執行。這個數字是保護連續任務的上限，不是命令安全性的證明；長時間任務仍須搭配超時、日誌和工作區隔離。官方用量與請求限制說明 (github.com)

提醒： 建置成功不代表命令沒有副作用。尤其是依賴安裝、清理腳本與自訂工作流程，真正要驗收的是命令內容及參數所能觸及的範圍，而不是終端最後顯示的成功狀態。

MCP 工具的逐項允許列表

接入 MCP 後，應把「伺服器已啟用」和「工具可自動執行」視為兩次不同的授權。官方資料顯示，MCP 工具可透過工具群接入外部伺服器；另外，專案設定與全域設定可能把工具帶入不同工作區，因此不能因為某個 MCP 伺服器由團隊維護，就把旗下所有工具一併放行。官方 MCP 工具說明 (github.com)

每個 MCP 工具都建立一筆紀錄，至少包括：

1. 工具名稱與所屬伺服器。
2. 可讀取或寫入的資料範圍。
3. 輸入參數是否有路徑、網址、查詢條件或批量操作。
4. 使用哪一組環境變數、存取權杖或登入工作階段。
5. 是否會建立、刪除、發布、發送或修改外部資料。
6. 撤銷權限、旋轉密鑰及停用伺服器的方法。

低風險通常是限定資料集的查詢；中風險是會寫入測試資料或建立草稿；高風險則包括正式資料寫入、部署、發送訊息、修改權限及讀取敏感資源。允許列表應精確到工具層級，不能只寫「允許這個 MCP 伺服器」。

遠端試跑與無人值守隔離

只要任務需要長時間執行，就不要直接在存放個人密鑰、瀏覽器登入狀態或正式倉庫的日常工作機上測試。遠端開發環境或雲端 Mac 應先建立獨立帳戶、獨立工作區與最小化網路出口；若任務依賴 Xcode 或其他 macOS 工具鏈，也要單獨驗證遠端 Mac，不能把一般容器的隔離結論直接套用。

試跑時安排兩個任務：

• 可回滾任務： 修改測試分支、執行測試、產生差異，最後完整回復。
• 故意越權任務： 嘗試讀取工作區外檔案、呼叫未列入允許列表的 MCP 工具，或執行被禁止的清理命令。

通過條件包括：工作區權限符合預期、網路出口可追蹤、密鑰沒有直接寫入日誌、命令日誌可保留、超時後能終止程序、回滾後沒有殘留檔案。沙箱或遠端伺服器只能縮小影響範圍，不能消除提示注入、惡意依賴、錯誤腳本或 MCP 服務本身的風險。

中段 FAQ：四個容易混淆的判斷

哪些操作可以先自動批准

先從只讀、限定目錄搜尋與可回復編輯開始；只有當差異檢查、工作區邊界與 Git 回復均通過，才考慮短期放行建置及測試命令。密鑰、部署、刪除、系統目錄與外部寫入仍應維持人工批准。

終端命令為何不能只看命令名稱

同一個命令在不同目前目錄、環境變數或腳本版本下，可能產生完全不同的結果。命令級允許列表應連同參數格式、工作目錄、輸出路徑及失敗處理一起檢查，否則「測試命令」也可能間接觸發安裝或寫入。

MCP 允許列表應以伺服器還是工具為單位

應以工具為最小授權單位，伺服器只代表一個承載邊界。讀取資料、寫入資料、觸發外部動作及接觸敏感資源的工具，風險不同，必須分開記錄和撤銷；未使用的 MCP 功能則直接停用。

無人值守任務何時必須隔離

當 Roo Code 會在你不在螢幕前持續修改檔案、執行命令或使用 MCP，就應轉移到隔離的遠端開發環境。隔離不是批准權限的替代品，而是當錯誤發生時，限制倉庫、網路、密鑰及作業系統影響面的第二道防線。

長期複核與回退條件

首次通過不代表永久安全。以下事件一旦發生，就應重新執行至少一輪越界與回滾測試：

• Roo Code 升級或切換執行方式。
• MCP 伺服器、工具描述或啟動命令變更。
• 倉庫內建置腳本、清理腳本或工作流程修改。
• 新增 API 金鑰、部署憑據或資料庫連線資訊。
• 遠端 Mac 的使用者、網路出口、掛載目錄或工具鏈改變。

保留自動審批的條件是：動作作用域固定、日志完整、回滾可驗證、越權會被攔截，而且最近抽查沒有異常差異。若只是任務變複雜但邊界仍清楚，可以縮小允許列表或降低 Max Requests；若出現未預期的外部寫入、密鑰進入日誌、無法回滾或拒絕記錄缺失，就應立即撤銷自動審批，回到人工確認模式。

你可以把這套流程整理到 SSHMac 使用說明中心，並在每次環境變更時重新核對。若團隊需要把遠端 Mac 納入研發流程，也應先確認工作區權限、密鑰注入和日誌保留政策，而不是只比較 CPU 或記憶體配置；SSHMac 的服務資訊可作為規劃遠端環境時的入口。

方案評分與上線門檻

下表不是替你選擇「全開」或「全關」，而是用風險和可驗收程度判斷下一步。分數越高，代表越適合進入短期自動執行；任何一項涉及正式資料或不可逆副作用，都應直接回到人工確認。

如果你目前使用的是沒有工作區隔離、缺少回滾、日誌不完整的本機方案，主要缺點不是 Roo Code 本身，而是錯誤命令可能直接碰到個人檔案、正式憑據和長期登入狀態；遠端環境若沒有固定網路出口與權限邊界，也同樣不適合無人值守。對需要臨時算力、測試分支或獨立 macOS 工具鏈的任務，租用 SSHMac 的 Mac 環境通常比在日常工作機上硬開全部批准更容易分隔風險；但長期穩定重負載、必須接入實體裝置，或要求完全掌控硬體的團隊，仍應評估自購 Mac 是否更合適。

最穩妥的做法，是先複製本文的分級驗收流程，在隔離開發環境完成一輪低風險任務；只有當日誌、越權攔截與回滾結果都通過，才逐步擴大 Roo Code 自動審批範圍。