Claude Code 新增受限模式，安全靠的是少给能力

8 月 28 日，Claude Code 2.1.248 的更新日志里多了一行很短的新参数，--restricted。

短到只有一句话，做的事却相当凶。它会拿掉能运行命令或代码的内置工具，拿掉 WebFetch，把文件工具圈在当前工作目录里，拒绝 bypassPermissions，还会忽略用户、项目和本地设置文件。

好家伙，别的更新都在给 Agent 加手加脚，这个更新反过来拆手脚。

我觉得它比又一个自动模式更值得团队看一眼。过去大家谈 Agent 安全，很容易落回两种做法。一种是在提示词里写「不要执行危险命令」，另一种是给每次操作弹确认框。前者像在机房门口贴一张「闲人免进」，后者则把安全责任变成了人肉点按钮。任务一多，人迟早会条件反射地按下允许。

Claude Code 官方 changelog 这次换了个思路。既然代码审查、仓库问答、文档核对这些任务根本不需要执行 shell，也不需要访问公网，那就别把这些能力交给模型。

不是提醒它少用。

是直接不给。

受限模式的第一步不是提醒 Agent 克制，而是把不需要的能力从工具箱里拿走。

这个开关不是只读模式

先把最容易误读的地方讲清楚。--restricted 不等于只读。

官方原文说的是，文件工具被限制在工作目录内。文件工具里既有 Read、Grep、Glob，也可能有 Edit 和 Write。它禁止模型跑命令、跑代码和随手抓网页，不代表模型必然不能改工作区里的文件。

这点很关键。如果你只是给一个陌生仓库做架构问答，或者在 CI 里让 Claude 对补丁做静态审查，最好继续用 --tools 把可用工具缩到任务真正需要的集合。官方的 CLI reference 也明确区分了两件事，--allowedTools 控制哪些工具不用再询问，--tools 才是限制会话里究竟有哪些工具。

一个偏保守的只读审查入口可以长这样。

claude --restricted \
  --tools "Read,Grep,Glob" \
  -p "阅读 .review-input.diff，并检查权限扩大、错误处理和测试缺口"

这里真正有价值的不是 prompt 写得多漂亮，而是 Claude 连 Bash、Edit、Write、WebFetch 都拿不到。它可以读补丁、追调用关系、找测试，却没有顺手执行仓库脚本或改源码的通道。

如果审查需要 git diff，别急着把 Bash 塞回去。让 CI 在 Agent 启动前生成输入文件。

git diff origin/main...HEAD > .review-input.diff
claude --restricted \
  --tools "Read,Grep,Glob" \
  -p "审查 .review-input.diff，并把结论写到标准输出"

这个小变化很朴素，却把职责分清了。CI 负责确定性地准备材料，Agent 负责阅读和判断。版本控制、凭据、网络、构建命令仍在确定性脚本手里，不因为模型临时觉得「跑一下更稳」就扩出一条新路径。

很多朋友可能会问，那测试怎么办。答案也不复杂，测试继续由 CI 跑，结果落成日志文件，再交给受限会话分析。模型不必亲自执行 npm test，照样能把失败栈、变更文件和测试缺口串起来。你损失的是一点即兴操作，换来的是执行路径可以复现、失败位置可以定位、权限范围可以解释。

我始终觉得，这才是 Agent 进入流水线时应该有的样子。不是让一个万能终端住进 CI，再祈祷它每次都克制，而是把任务拆成「机器准备证据」和「模型做判断」两段。

先把 CI 的手脚拆开

--restricted 最适合的，不是所有 Claude Code 会话，而是那些收益很明确、能力需求却很窄的任务。

仓库问答就是一类。新同事想知道登录状态从哪里写入、订单取消会经过哪些模块、某个 feature flag 是否还有调用，只需要 Read、Grep 和 Glob。让模型在工作区里追代码，比把整个终端权限交出去合理得多。

代码审查也是一类。补丁、相关测试、接口定义和调用方已经足够支撑大部分静态判断。真要运行测试，交回 CI。真要修改代码，开另一条有写权限、带独立 worktree 和验收步骤的会话。审查 Agent 和修复 Agent 不该默认是同一个角色。

文档核对也很适合。让模型检查 README、配置示例和实际代码是否一致，不需要联网，不需要执行包管理器，更不需要读取工作区外的 ~/.aws、~/.ssh 或全局配置。受限模式忽略用户、项目和本地设置文件，还能减少一部分「换台机器就换一套行为」的漂移。

但要注意，忽略这些设置也会拿走你原本依赖的个人 hooks、项目权限规则和本地 MCP 配置。不是哥们，安全开关不是打开以后什么都更方便。它故意让环境变得贫瘠，代价就是某些自动化会消失。

所以受限任务最好把需要的输入显式准备好，把允许的工具显式列出来，把输出格式写进调用参数或外部校验。别指望某台开发机里的隐藏配置替你补齐流程。隐藏配置越少，CI 里越不容易出现「我电脑上明明能跑」的经典节目。

官方工具参考 给了一个很实用的判断方法。工具名就是权限规则、Agent 工具清单和 hook matcher 使用的准确字符串。你可以按任务列能力，不必拿「Claude Code」当成一个不可拆的整体。

这块需要注意一下，明确点名也可能重新扩大能力。更新日志写得很直白，受限模式会移除 WebFetch 和执行类工具，除非它们在 --tools 中被点名。要是启动脚本一边写着 --restricted，一边又把 Bash、WebFetch 和一堆 MCP 全塞回来，那就只剩下心理安慰了。

有点子牛逼的地方，恰好是这个参数没有承诺万能。它只是给出一个更窄的起点。团队仍然要回答每个任务到底需要读什么、写什么、访问什么、由谁批准。

少给工具，还不等于安全

为什么不能把 --restricted 当成一键安全。Claude Code 2.1.251 的后续修复已经给了现成答案。

2.1.251 修了几类路径边界问题。文件工具可能在权限检查后跟随被替换的符号链接，读写到工作区之外。插件命令可能指向插件目录之外。Workflow 可能在权限检查前读取目录外的脚本路径。Grep 和 Glob 也修了经由符号链接搜索路径时没有正确应用 Read deny 规则的问题。

这些都不是模型在提示词里「不听话」。它们是路径解析、检查顺序和运行时实现的问题。

段错误。

能力清单只能决定门口发了哪些钥匙，不能保证门锁本身没有缝。受限模式把攻击面压小了，客户端版本、符号链接处理、插件来源和工具实现仍要持续更新。把旧版 CLI 丢进 CI，然后在启动参数里加一个新单词，不会自动得到新版本的修复。

再看网络。官方 权限文档 和 组织部署指南 都提醒过，权限规则和沙箱是两层东西。禁用 WebFetch 只能挡 Claude 的抓取工具。如果会话又拿回 Bash，curl、wget 和仓库脚本仍可能访问网络。真正的网络边界要靠沙箱和域名白名单。

Sandboxing 文档 说得更细。Bash 沙箱在 macOS 上用 Seatbelt，在 Linux 和 WSL2 上用 bubblewrap，子进程继承同一套文件系统与网络限制。网络过滤通过外部代理按域名控制，但默认不做 TLS 内容检查。允许了一个可信域名，不代表发往该域名的每个请求都天然安全。

MCP 也一样。--restricted 处理的是 Claude Code 内置能力和若干设置来源，不是替组织决定所有外部工具的信任关系。一个能读生产数据库、发消息或改工单的 MCP，本身就是另一扇门。团队要用 managed settings 限制允许的 MCP 服务器和插件市场，不能只盯着 Bash。

身份更不能省。受限会话如果继承了一枚权限过大的云密钥，即使工具很少，任何被明确放回来的网络或 MCP 能力都可能放大后果。Server-managed settings 能强制只使用管理员下发的权限规则，禁掉跳过权限模式，并统一下发 hooks。可它也不会替你完成短期凭据、最小 scope、离职失效和服务端审计。

工具清单只是第一道门，工作区、身份、审计与网络出口缺一层都不踏实。

坦率讲，安全是这些层一起工作，不是某个参数单独封神。

把它放在正确的一层

如果今天就要把 --restricted 用起来，我会把它放在能力入口这一层。

最外面先由 CI 或调度器创建干净工作区，固定 Claude Code 最低版本，生成补丁、测试日志和任务说明。受限会话启动时只拿到完成这次判断所需的工具。网络默认断开，确实需要的域名通过沙箱白名单放行。MCP、插件与 hooks 只接受组织管理的来源。凭据按任务发短期 token。结果写标准输出或固定报告文件，再由确定性规则检查格式、敏感信息和退出码。

听着步骤不少，对吧。可这些步骤并不是给模型添麻烦，它们是在替人保留撤销、复现和追责的能力。

官方 headless 文档 里还有一个 dontAsk 模式，未在 allow 规则或只读命令集里的操作会被拒绝，很适合无人在场的 CI。--restricted、明确的 --tools、dontAsk、沙箱和 managed settings 不是互相替代，而是从不同方向收窄会话。

你也可以把任务分成三档。只读问答只给 Read、Grep、Glob。静态审查由外部脚本准备 diff 和测试日志，Agent 只输出报告。真正需要改代码的任务则进入隔离 worktree，允许 Edit 和 Write，但提交、测试、推送与合并仍由外部闸门验收。

这样做最大的收益，不是风险从此归零。那种承诺谁说谁心虚。真正的收益是，出了问题你能回答几个具体问题，模型当时有什么工具，读写范围在哪里，能否访问网络，使用了哪种身份，产生了什么变更，谁验收过。

能回答，才有资格把 Agent 接进生产。

Claude Code 这次新增的受限模式，表面上是在命令行里多放了一个参数。我自己的感受是，它更像一次产品方向上的表态。AI 编程工具下一阶段比的，不只是能把多少活自动做完，还要比能否为不同任务主动少拿一些权力。

万能终端很爽。直到它住进 CI，拿着生产凭据，凌晨没人盯着。

所以我愿意给 --restricted 点个赞。不是因为它已经解决了 Agent 安全，而是因为它终于把一个朴素原则写进了产品入口。

用不到的能力，别交出去。