配置护栏
本指南介绍如何配置护栏：这些规则决定智能体的某项操作是直接运行、先请求批准，还是被拒绝。
护栏覆盖每个会改变状态的工具所声明的十三种效果类别。它们在工具被调用的位置于服务器端强制执行， 绝不依赖提示词里的某条指令。
为某个操作类别设置决策
标题为“为某个操作类别设置决策”的部分- 前往 设置 → 工作区 → 智能体权限
- 用分段控件选择范围：工作区、智能体（然后选择智能体），或空间（然后选择空间）
- 在操作类别所在的行上，选择允许、先询问或拒绝
- 要删除你设置过的规则，请按该行末尾出现的重置按钮（恢复为继承值）——决策会回退到更宽的范围
每一行都会以状态标签显示生效的决策，并用徽章标明它的来源：此范围、继承或内置默认值。
该矩阵在智能体（chat）模式下解析，因此模式预设在这里从不会出现——要查看这一层，请选择
某个只读模式后再使用预演探针。
写入规则需要 admin 角色。读取该矩阵则不需要。
检查点：在工作区范围把推送到远程仓库设为拒绝，然后对 git push origin main 运行下面的
预演探针。结果会显示 deny，来源为 workspace。
了解决策如何解析
标题为“了解决策如何解析”的部分解析的顺序是先看具体程度，再看限制程度：
- 先看空间规则，再看智能体规则，最后看工作区规则。第一个存在匹配规则的范围做出决策， 解析就此停止
- 如果没有规则匹配，就应用模式预设——只读模式（plan、review、orchestrate）会拒绝十三种类别中 的十一种
- 如果模式没有规定，就应用内置默认值
在同一个范围内，命令规则按最长匹配前缀解析，而具体程度相同的冲突则按限制最强解析——拒绝优先于 先询问，先询问优先于允许。一个操作如果声明了多个类别，会分别独立解析每个类别，然后以限制最强的 方式把它们合并起来。
先询问决策只会弹出一个批准提示，覆盖所有解析为 prompt 的类别。在未连接审批人的情况下，它
会被拒绝，无论是 shell 命令还是内置运行器的工具调用都是如此。这是有意为之：一次没有把关的运行
比一次被拒绝的运行更糟。
操作类别与内置默认值
标题为“操作类别与内置默认值”的部分| 操作类别 | 内置默认值 |
|---|---|
| 删除文件 | 先询问 |
| 写入工作树之外 | 允许 |
| 创建提交 | 允许 |
| 推送到远程仓库 | 先询问 |
| 打开 pull request | 先询问 |
| 发布评审或合并 | 先询问 |
| 写入外部跟踪器 | 先询问 |
| 访问网络 | 允许 |
| 读取密钥 | 允许 |
| 安装软件包 | 允许 |
| 运行进程 | 允许 |
| 更改工作区结构 | 允许 |
| 操控隔离舱（机台） | 允许 |
这套分类法是封闭的。新工具如果发布时没有声明自己的类别，就通不过在 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 上同样没有——在那里， 护栏加上模式的工具集就是全部的执行手段，而不是它的第二道防线。用 配置沙盒策略确认你属于哪种情况。