設定護欄
本指南說明如何設定護欄：這些規則決定代理的某項操作是直接執行、先請求核准，還是被拒絕。
護欄涵蓋每個變更工具所宣告的十三個效果類別。它們在工具被呼叫的位置於伺服器端強制執行， 絕不倚賴提示中的指令。
為某個操作類別設定決定
標題為「為某個操作類別設定決定」的章節- 前往 設定 → 工作區 → 代理權限
- 以分段控制項選擇範圍：工作區、代理（然後選擇代理），或空間（然後選擇空間）
- 在操作類別所在的那一行，選擇允許、先詢問或拒絕
- 若要移除你設定過的規則，請按該行末端出現的重設按鈕（還原為繼承）——決定會回退至較寬的 範圍
每一行都會以狀態標籤顯示生效的決定，並以徽章標明它的來源：此範圍、繼承或內建預設。
這個矩陣在代理（chat）模式下解析，因此模式預設在這裡從不出現——若要查看這一層，請選擇某個
唯讀模式後再使用假設情境探測。
撰寫規則需要 admin 角色；讀取矩陣則不需要。
檢查點：在工作區範圍把推送到遠端設為拒絕，然後對 git push origin main 執行下面的假設
情境探測。結果會顯示 deny，來源為 workspace。
了解決定如何判定
標題為「了解決定如何判定」的章節判定原則是先看具體程度，再看限制性：
- 先看空間規則，再看代理，最後看工作區。第一個有相符規則的範圍作出決定，判定即在 此停止
- 若沒有規則相符，便套用模式預設——唯讀模式（plan、review、orchestrate）會拒絕十三個類別 中的十一個
- 若模式沒有規定，便套用內建預設
在同一個範圍內，指令規則以最長的相符前綴判定，而具體程度相同的衝突則按最嚴格判定——拒絕勝過 先詢問，先詢問勝過允許。一項操作若宣告多個類別，會各自獨立判定每個類別，然後以最嚴格的方式合併。
先詢問決定只會顯示一個核准提示，涵蓋所有判定為 prompt 的類別。在未連接核准人的情況下，
它會被拒絕，shell 指令與執行環境的工具呼叫皆然。這是刻意為之：一次沒有把關的執行，比一次被
拒絕的執行更糟。
操作類別與內建預設
標題為「操作類別與內建預設」的章節| 操作類別 | 內建預設 |
|---|---|
| 刪除檔案 | 先詢問 |
| 寫入工作樹以外 | 允許 |
| 建立提交 | 允許 |
| 推送到遠端 | 先詢問 |
| 開啟 pull request | 先詢問 |
| 發佈審查或合併 | 先詢問 |
| 寫入外部追蹤器 | 先詢問 |
| 存取網絡 | 允許 |
| 讀取密鑰 | 允許 |
| 安裝套件 | 允許 |
| 執行程序 | 允許 |
| 變更工作區結構 | 允許 |
| 操控 enclosure（rig） | 允許 |
這套分類法是封閉的。新工具若在發佈時沒有宣告自己的類別，就無法通過 CI 中的棘輪測試，因此不會有 工具帶着一個悄悄為空的效果集合上線。
用假設情境探測測試規則
標題為「用假設情境探測測試規則」的章節更改規則之前，先檢查目前政策已經如何判定它。
- 在同一頁向下捲動到會怎樣？
- 選擇一個動作（十三個類別之一）
- 可選填指令（例如
git push origin main）、代理、空間與模式 - 讀取結果：決定、原因，以及來源：
探測會針對你的即時規則，執行與強制執行路徑相同的解析器，因此答案是精確的。若結果出乎意料，就在 上面的矩陣中更改規則，然後再次探測。
設定空間的自主程度旋鈕
標題為「設定空間的自主程度旋鈕」的章節這個旋鈕按每個空間中的每個代理分別生效，並與規則疊加，而不是取代規則。
- 開啟該空間
- 從空間標頭開啟管理參與者
- 在代理所在那一行的自主程度下，選擇一個級別：
| 級別 | 效果 |
|---|---|
| 預設 | 沒有空間設定——行為等同經核准後行動 |
| 僅提出建議 | 每個設有閘門的工具都會被直接拒絕，並附上一則訊息，指示代理改為提出該操作 |
| 經核准後行動 | 有風險的操作會進入失效即拒絕的核准閘門 |
| 自由行動 | 預先核准任何未判定為硬性拒絕的操作 |
這個旋鈕只及於內建執行環境。Claude Code 配接器會在這一閘門之外執行它自己的工具。
了解護欄覆蓋不到的地方
標題為「了解護欄覆蓋不到的地方」的章節同一頁底部的規則套用位置表就是這段內容的應用程式內版本：它會逐一效果類別說明每個執行器是在 政策閘門攔截它、把它交給沙箱處理，還是根本無法攔截它。
- Claude Code 配接器自身的工具呼叫只有一部分受把關。Claude Code 以
--dangerously-skip-permissions啟動，因此它的 read、write 與 edit 呼叫從不經過這道 護欄。它的 bash 指令會經由一個把命令列分類的鉤子抵達護欄，它的推送也和所有代理一樣 經過推送閘道。它回呼的 MCP 工具介面，以及 Control Center 為啟動它而衍生的 shell 指令，同樣受把關。 - 模式自身的輸出動詞（
submit_plan、propose_orchestration）已被釘住，永遠無法被拒絕—— 否則模式在結構上將無法產出它唯一的交付項目。 - 沙箱是否為這些規則兜底取決於主機。 當
cc_server找到可用後端時，它會包裹 Claude Code CLI 與執行環境的bash工具，因此即使是你沒有寫過的規則，其下仍有作業系統底板。在 Windows 上 完全沒有，而在缺少bwrap和socat的 Linux 或 WSL2 上也同樣沒有——在那裡，護欄加上模式 的工具介面就是全部的強制執行手段，而不是它的第二道防線。用 設定沙箱政策 確認你屬於哪種情況。