Claude Code权限修复后的配置检查清单

Claude Code v2.1.321 修补了五处涉及权限和 hooks 的缺口：OAuth 凭据可能跨主机泄露、只读命令可能绕过沙箱、文件写入可能漏过规则，以及两种 hook 检查失效。按原文记录，该版本发布于 2026 年 11 月 9 日。

对允许 Agent 执行命令、修改文件或调用 MCP 的团队，升级只是第一步。更有用的是顺着这些缺口检查：规则是否覆盖实际操作，多个 hook 是否正确协作，检查失败后究竟放行还是阻断。

权限规则为什么会漏掉实际操作

这次有两个修复，都与「系统如何理解命令」有关。

第一个是被判定为只读的 Bash 命令，可能在没有提示的情况下运行到沙箱之外。作者提醒，只读判断来自命令文本，而文本可能误导判断。因此，他们建议增加一个执行前的 PreToolUse hook，检查即将运行的完整命令。

这里有两道不同的防线：权限检查决定能不能执行，沙箱限制执行后的影响范围。判定为只读，不应自动成为离开沙箱的理由。

第二个缺口发生在 cp x dir/ 和 mv x dir/。原有 deny 规则和受保护文件提示，没有覆盖这两条命令实际写入的目标文件。命令中写的是目录，真正落盘的却是目录下的文件，检查对象出现了偏差。

作者把它与 v2.1.319 的带引号路径修复归为同类问题：同一次写入可以有不同的路径表达方式，规则只认其中一种，就可能漏检。

升级后，如果团队限制写入 .env、.github/workflows/ 或 hook 配置，应重新测试 cp、mv 和带引号路径，确认实际出现拒绝或确认提示。仅仅在配置里看见一条 deny 规则，还不能证明它覆盖了这些写法。

MCP 要单独管，多个 hook 也要测协作

MCP 的问题发生在 OAuth 重定向过程中。修复前，原本发给某个主机的秘密信息，例如 refresh token，可能被发送到另一个主机。

作者建议运行 claude mcp list 清点服务器，移除不用的连接，并为不受自己控制的服务器轮换 token。原文没有给出实际泄露案例或受影响配置范围，不能把潜在风险写成已经发生的泄露。

这也解释了为什么 MCP 需要独立规则：shell 和文件权限无法直接回答「凭据会发往哪里」这个问题。

另外两处修复针对 hook：

• 一个 PreToolUse hook 返回的 ask，可能因为另一个 hook 的 defer 先完成而丢失。需要人工确认的要求，可能没有被保留下来。
• MCP 答复超过 16 MiB 时，mcp_tool hook 原先会被跳过；修复后，这次调用会被拒绝。

前者是多个检查之间的协作问题，后者是超大答复触发的检查缺失。它们共同提示：不能只测试单个 hook 正常返回的情况，还要检查并发、异常和大小边界。

检查无法完成时，要提前决定放不放行

作者建议按工具类别分别组织 hook：shell、文件写入、文件读取和 MCP，每类设置一个 PreToolUse 入口，并明确失败策略。

「失败关闭」（fail closed）是检查无法完成就阻断；「失败开放」（fail open）是检查无法完成仍继续。作者主张 shell、文件写入和 MCP 默认阻断，文件读取通常可以继续。

后半句需要结合项目判断。读取源码与读取凭据文件的风险不同，不能因为都是读取，就采用同一种放行策略。

对于允许 Agent 长时间自主运行的团队，作者还建议保留执行前策略检查、人工审批和审计日志，并配合沙箱。hook 配置文件本身也应禁止 Agent 修改，否则它可能改动约束自己的规则。

我的判断

这篇最有价值的提醒，是把「配置存在」与「约束生效」分开。路径变体、多 hook 协作和超大答复，都适合进入权限回归检查。

但原文没有提供复现脚本、测试矩阵或对照数据。「额外 hook 是便宜的一层保护」「读取失败通常可以放行」属于作者的经验判断，不能直接当作普遍结论。新增检查也会带来维护成本，而且 hook 自己同样可能出错。

作者披露自己参与开发 SecGuardRail。该产品面向 Claude Code、Cursor 和 Codex，按工具类别拆分 hooks，提供风险审批、默认阻断策略和哈希链审计日志。这个利益关系需要摆明：文章能支持升级和复测的必要性，不能据此证明团队必须购买额外产品。

能拿来做什么

• 先运行 claude --version，确认版本至少为 v2.1.321；团队可按作者建议，将最低版本要求纳入托管设置或开发环境脚本，并加入新人检查清单。
• 在可丢弃的测试目录里验证受保护路径，用 cp、mv 和带引号路径触发写入，检查拒绝或确认提示是否真正出现。
• 运行 claude mcp list 清理闲置连接，为第三方 MCP 服务器轮换 token，并单独审查 MCP 权限。
• 梳理现有 hooks，明确四类工具的失败策略，检查 ask 与 defer 的协作，并保护 hook 配置文件。