設定護欄

本指南說明如何設定護欄：決定代理動作要執行、先要求核准，還是直接拒絕的規則。

護欄涵蓋每個會變更狀態的工具所宣告的十三種效果類別。它們在伺服器端、於工具被呼叫的那一刻強制執行，絕不會倚賴提示中的指示。

為動作類別設定決策

每一列都會以狀態標籤顯示生效的決策，並以徽章顯示它的來源：此範圍、繼承或內建預設。這份矩陣是在 Agent（chat）模式下解析的，因此這裡永遠不會出現模式預設——若要看那一層，請選取唯讀模式後使用假設情境探測器。

撰寫規則需要 admin 角色。讀取矩陣則不需要。

檢查點：在工作區範圍把推送到遠端設為拒絕，然後對 git push origin main 執行下方的假設情境探測器。結果會顯示 deny，來源為 workspace。

解析順序是先比具體性，再比限制性：

在同一個範圍內，命令規則以最長相符前綴解析，而具體程度相同的衝突則以最嚴格者為準——拒絕勝過先詢問，先詢問勝過允許。一個動作若宣告多個類別，會各自獨立解析，再以最嚴格者合併。

先詢問的決策會跳出一個核准提示，涵蓋所有解析為 prompt 的類別。在沒有連接任何核准者的情況下，一律拒絕，shell 命令與執行環境工具呼叫皆然。這是刻意的：一次未設閘門的執行，比一次被拒絕的執行更糟。

這套分類法是封閉的。新工具若未宣告其類別就出貨，會在 CI 的棘輪測試中失敗，因此不會有任何東西帶著悄然為空的效果集合出現。

在變更規則之前，先查看目前政策已經如何解析它。

探測器會針對你目前的實際規則，執行與強制執行路徑相同的解析器，因此答案精確無誤。如果結果令你意外，請在上方的矩陣中變更規則，然後再探測一次。

這個旋鈕是每個代理在每個空間各一組，而且會與規則疊加，而不是取代規則。

層級	效果
預設	沒有空間設定——行為等同經核准後行動
僅提出建議	每個受閘控的工具都直接拒絕，並以訊息告知代理改為提出這項動作
經核准後行動	有風險的動作會落入失效即拒絕的核准關卡
自由行動	預先核准任何未解析為硬性拒絕的動作

這個旋鈕只觸及內建執行環境。Claude Code 配接器會在這個閘門之外執行它自己的工具。

同一頁面底部的規則套用位置表格，就是這件事的應用程式內版本：它會針對每個效果類別，說明各個執行器是在政策閘門攔截它、交給沙箱處理，還是根本無法攔截。

Claude Code 配接器自身的工具呼叫只有一部分受閘控。Claude Code 是以 --dangerously-skip-permissions 啟動，因此它的讀取、寫入與編輯呼叫永遠不會通過這道防護。它的 bash 命令會經由一個將命令列分類的鉤子抵達防護，它的推送也和所有代理一樣經過推送閘道。它回呼的 MCP 工具介面，以及 Control Center 為了啟動它而生成的 shell 命令，同樣設有閘門。
模式自身的輸出動詞（submit_plan、propose_orchestration）是固定的，永遠無法被拒絕——否則模式在結構上就無法產出它唯一的交付成果。
沙箱是否為這些規則提供後盾，取決於主機。 當 cc_server 找到後端時，它會包裝 Claude Code CLI 與執行環境的 bash 工具，因此即使規則不是你寫的，底下仍有作業系統下限。在 Windows 上完全沒有下限，而在缺少 bwrap 與 socat 的 Linux 或 WSL2 上也沒有——在那些環境裡，護欄加上模式的工具介面就是全部的強制執行，而不是第二道防線。請用設定沙箱原則確認你屬於哪一種情況。