权限控制

本文是阅读这篇博文后的简单记录与思考： How we built Claude Code auto mode: a safer way to skip permissions 使用Claude Code时，经常会遇到各种权限的申请，也就是human-in-the-loop，导致提了一个复杂需求给CC后，如果人离开电脑了任务就会卡在这个申请上。所以网友各种hack，使用happy或者是远程登陆软件连到自己电脑上。 CC官方新增了auto mode功能，尽可能的利用AI的能力来帮助简化审批流程。避免--dangerously-skip-permissions带来的灾难性破坏 为什么可以做 系统基于一个数据前提：CC用户通过了93%的权限申请。 这是一个很关键的前提条件，他给auto mode的实现提供了很大的可能性：仅有很小比例的情况下是需要拒绝的，如果反过来CC用户通过了7%的权限申请。，那么auto mode需要处理的情况就复杂的多了。 怎么做的 prompt注入探针 CC团队在server端实现了一个运行在服务器端的prompt注入探针，它扫描tool消息，并在发现风险时插入warning消息 为啥需要这个prompt注入探针？原因是两层决策机制没有把tool result作为输入，这可能导致prompt注入成功，这时候如果有warning消息，则agent被劫持的概率会大大降低。 两层的决策机制 在client端实现了两层的决策机制，使用Claude Sonnet 4.6 进行判断，第一层是简单输出是否拦截，当拦截时进入第二层，使用更多的reasoning token来给出更准确的判断。输入是user消息+tool消息，干掉了assistant消息和tool result 为啥是两层？因为大部分情况下不会拦截，当第一层拦截时再花费更多token去进行判断。效果是一样的，可以节省更多成本。 为啥干掉assistant消息和tool result？因为assistant消息可能会误导LLM，tool result可能会含有注入的有毒信息 结合服务端与客户端的两种自动审查，劫持主agent会变得很难 auto mode下拦截后发生了什么 不执行tool，并提示模型：find a safer path, don’t try to route around the block. 如果连续三次被拦截，或者是累积20次被拦截，则让人类来决策 如果是headless模式，则退出执行 这还挺聪明的，如果发生了拦截了不该拦截的tool调用，则多次重试可以将false positive的情况降到最低 怎么评价，结果怎样 先看效果：日常流量的误拦率从 8.5% 压到了 0.4%，但 overeager 动作还是有 17% 会漏过去。 为啥漏拦这么高？因为难点不在「看没看见危险」，而在「用户到底授没授权」。force-push、删分支模型都识别得出来，但「清理一下分支」这句话算不算允许批量删除？分类器在这条边界上经常拿不准，prompt 工程暂时也没招。 那它到底值不值得用？得看跟谁比。跟 --dangerously-skip-permissions 裸奔比，这是实打实的进步；跟逐条认真审批比，反而是退步——你把自己的判断换成了一个会偶尔出错的分类器。所以它不是给所有人的，而是接住前文那批被 approval fatigue 折磨、又不敢裸奔的用户，做 happy 这类 hack 的官方替代品。

本文是 Claude Code 源码逆向系列 的第四篇，聚焦权限系统与沙箱在工具调用前的门控机制。 第三块是"安全边界"核心：工具不是想调就调，必须经过权限判定。这也是 Claude Code 敢于在用户本地机器上运行 rm -rf 或 curl 的底气所在。 1. 架构总览：双层防御体系 在恢复代码的过程中，我发现 Claude Code 的安全机制并非铁板一块，而是清晰地分成了两个层级： Sandbox（沙箱）：系统级的硬约束。例如"绝对禁止读取 /etc/passwd“或"只允许访问 github.com"。这是一道不可逾越的红线。 Permissions（权限）：用户意图的软确认。例如"可以运行这个命令吗？“或"确认写入这个文件吗？"。这通过 Human-in-the-Loop（人机回环）来实现安全兜底。 主要涉及的代码目录： src/core/sandbox/：沙箱策略、路径标准化、网络白名单。 src/core/permissions/：权限决策引擎、上下文状态、规则匹配。 src/core/agent/runtime.ts：执行循环中的拦截点。 2. Sandbox：绝对的系统边界 沙箱的核心逻辑在 src/core/sandbox/policy.ts。它不关心"用户同不同意”，只关心"系统允不允许”。 文件系统限制 最基本的防御是文件路径检查。SandboxPolicy 类中有一个关键的细节：路径标准化。 1 2 3 4 5 6 // src/core/sandbox/policy.ts private resolvePath(input: string) { if (input === ".") return resolve(this.cwd); if (input.startsWith("/")) return resolve(input); return resolve(this.cwd, input); // 相对路径转绝对路径 } 这一点非常重要。如果没有这一步，攻击者（或幻觉中的模型）可能会尝试用 ../../ 逃逸出工作目录。恢复后的代码显示，所有的 checkRead 和 checkWrite 都会先调用 resolvePath，然后与 denyRead / denyWrite 列表进行比对。 网络访问控制 对于 WebFetch 和 WebSearch 工具，沙箱检查的是域名： 1 2 3 4 5 6 7 8 9 10 11 // src/core/sandbox/policy.ts (简化) checkNetwork(target: string): SandboxDecision { const hostname = this.extractHostname(target); // 1. 黑名单检查 if (this.matchesDomain(hostname, denied)) return { allowed: false, ... }; // 2. 白名单检查 (如果配置了白名单) if (allowed.length > 0 && !this.matchesDomain(hostname, allowed)) { return { allowed: false, reason: "allowedDomains" }; } return { allowed: true }; } 这意味着企业用户可以通过配置 allowedDomains 来强制 Claude Code 只能访问内网文档或特定的 API 服务，杜绝数据外泄风险。 ...