---

description: 权限提示越多，不代表实际控制越强。Claude Code 的沙箱把安全重点从逐次猜测命令意图，转向由操作系统强制限制文件、网络与凭据边界。
tags: [Claude Code, Agent 安全, 沙箱, 提示注入, AI 编程]

---

少点几次“允许”，Claude Code 为什么反而更安全？

Claude Code 准备运行测试，你点一次“允许”；测试脚本要下载依赖，再点一次；接着它调用格式化工具、Git 和构建脚本，每一步都弹窗。刚开始你还会逐字检查，十几次以后，手指往往先于判断按下确认。

这暴露了 Agent 安全里一个反直觉问题：**权限提示越多，不代表实际控制越强。**当系统把安全寄托在用户每次都能正确理解命令、识别上下文并保持警觉时，审批疲劳本身就会变成漏洞。

Anthropic 在 2025 年的《Beyond permission prompts: making Claude Code more secure and autonomous》中提出了沙箱方案。它的重要之处不只是减少弹窗，而是换了一种控制对象：不再反复猜测“Agent 现在想做什么”，而是先用操作系统规定“无论它想做什么，最多能碰到哪些文件、连接哪些网络”。安全的自主性来自可强制执行的影响边界，而不是来自 Agent 的自律，也不是来自用户永不犯错。

权限提示审查的是意图，沙箱限制的是结果

传统权限提示发生在操作执行前。系统展示一条命令，用户根据命令文本和当前任务判断是否允许。这种机制适合少量、高风险、语义明确的动作，例如向生产环境部署或删除数据库。

但编程 Agent 会连续调用脚本、包管理器、测试框架和它们产生的子进程。一条看似普通的 npm test，实际执行什么，取决于仓库里的 package.json、依赖包、环境变量和测试脚本。只看入口命令，用户未必能知道完整行为；逐个审查所有子进程，又会让自动化失去意义。

沙箱采用另一条路线：先定义允许读写的路径和允许连接的域名，再由操作系统约束已经运行起来的进程。即使命令名看起来安全，或者某个脚本在执行中做了意外操作，它及其子进程仍不能自然越过边界。

图中的差别不是“要不要审批”，而是默认执行之后还有没有一道不依赖模型判断的强制边界。权限系统仍然有用，但它更适合决定 Agent 能调用哪些工具；沙箱则负责限制 Bash 命令真正运行后能访问什么。

审批疲劳不是体验问题，而是安全模型失效

权限弹窗隐含了三个苛刻前提：用户看得懂操作，拥有足够上下文，并且每一次都保持注意力。编程 Agent 的长调用链会同时破坏这三个前提。

首先，命令文本不等于完整效果。make build、pytest 或一段仓库脚本都可能继续启动其他程序。其次，用户看到的是当前动作，却未必记得 Agent 先前读过什么数据、获得过哪些网络权限。最后，低风险动作与高风险动作混在同一种弹窗里，会训练用户形成条件反射。

因此，减少权限提示并不是放弃控制。前提是把高频、可预期的动作放进足够窄的沙箱，让系统自动处理；把出站网络、新增写入路径、凭据访问和生产操作等真正改变风险面的动作留给人工确认。

这条判断也适用于其他 Agent：审批应该集中在“扩大能力边界”的时刻，而不是平均分配给边界内的每一步。

文件系统与网络必须同时收紧，因为攻击会沿另一条路绕行

文件系统隔离限制 Agent 能读写哪些路径，网络隔离限制进程能连接哪些目标。两者解决的不是同一个问题。

如果只限制写文件，却允许任意联网，受到提示注入影响的进程仍可能读取环境中的数据并发送给攻击者。如果只限制网络，却允许修改主机上的启动脚本、可执行文件或 Agent 配置，它可以留下持久化修改，等待另一个不受限进程替它联网。

这也是为什么“只把项目目录设成可写”还不够。可读数据、环境变量、出站域名、Unix Socket 和沙箱外重试都会影响最终边界。安全性取决于所有出口的交集，而不是某一个开关是否显示为已启用。

本地 Bash 沙箱保护了什么，也没有保护什么

按 2026 年 8 月 26 日的 Claude Code 沙箱文档，本地沙箱支持 macOS、Linux 和 WSL2：macOS 使用 Seatbelt，Linux 与 WSL2 使用 bubblewrap。它约束 Bash 命令及其脚本、程序和子进程。

默认情况下，沙箱化命令可以写当前工作目录和会话临时目录，不能修改工作区外的大多数文件；网络连接通过沙箱外代理，并按域名控制。Claude Code 还会保护 .claude 设置、Skills、Hooks、.mcp.json、Shell 启动文件和部分 Git 配置，避免工作区内的命令通过修改 Agent 自己的配置来扩权。

不过，下面这些边界不能从“已开启沙箱”四个字里自动推出：

• 默认读取范围很宽。 当前文档明确写明，Bash 沙箱默认可以读取电脑上的大部分文件，甚至可能包括 ~/.aws/credentials 和 ~/.ssh/；需要用 sandbox.credentials 或 denyRead 额外保护。
• **内置代理默认不检查 HTTPS 内容。**它主要依据目标主机名放行。过宽的域名规则仍可能形成数据外传路径；高威胁模型需要能终止 TLS 并检查流量的自定义代理。
• 沙箱主要约束 Bash。 内置的 Read、Edit、Write 使用权限系统；Computer Use 操作的是实际桌面，也不在这层 Bash 隔离里。
• 兼容性例外会打洞。 不兼容的命令可能请求在沙箱外重试；允许 Docker Socket、Apple Events、过宽写路径或大量 excludedCommands，都可能削弱隔离。
• 它不是原生 Windows 沙箱。 当前支持 macOS、Linux 和 WSL2，不支持 WSL1 与原生 Windows。

这也修正了一句容易被过度理解的话：沙箱可以阻止受损的 Claude Code 窃取 SSH 密钥或向攻击者服务器回传，但前提是密钥不可读、出站路径受限、例外没有重新打开通道。当前默认配置并不自动满足所有前提。

Web 版的关键不是“在云上”，而是把执行环境与长期凭据分开

本地沙箱仍运行在用户电脑上，并共享一部分主机上下文。Claude Code on the web 采用更完整的隔离单元：在 Anthropic 托管模式下，每个会话运行在独立虚拟机中，与用户设备和其他会话分开。

更关键的是，Git 凭据与签名密钥不直接进入会话环境。沙箱里的 Git 客户端拿到范围受限的凭据，把请求交给外部代理；代理验证操作内容，再附加真正的认证令牌。这样，Agent 可以完成被授权的 Git 操作，却不必持有可以被复制和长期滥用的原始密钥。

这个设计给出了一条比“把 Secret 注入环境变量”更普遍的 Agent 安全原则：**让 Agent 使用能力，不等于把能力的长期凭证交给 Agent。**能通过代理代办、缩小范围、限制目标和缩短有效期的凭据，就不应以明文长期驻留在执行环境中。

当然，云端隔离也不是绝对封闭。当前官方文档明确指出，即使关闭普通网络访问，Claude Code 仍需连接 Anthropic API，这仍可能成为数据离开虚拟机的路径；自托管环境的隔离与凭据策略则由部署方负责。

高自主任务该用哪一层边界，取决于失败后果

没有一种权限模式适合所有任务。更实用的选择方式，是先判断错误或提示注入成功后，最坏会影响什么。

任务条件	应采用的安全边界
接触生产、资金或高权限基础设施	保留人工审批与外部发布门禁
仓库或输入不完全可信	使用独立 VM、容器或云端会话，并配置短期范围凭据
输入可信，但需要长期自主运行	使用本地沙箱，收紧文件、网络与凭据规则
输入可信，且只是短时普通开发	使用常规权限，并按需启用沙箱

对于普通本地开发，Bash 沙箱适合把测试、构建、格式化和工作区内改动放进可控范围；同时应显式保护 SSH、云厂商和包管理器凭据，并保持域名白名单足够窄。

对于不可信仓库、外部任务描述或长时间无人值守任务，独立虚拟机、容器或 Claude Code on the web 更容易控制主机影响面。凭据应使用短期、限定仓库和限定操作的形式，结果通过 Diff、测试与 Pull Request 再进入主分支。

对于生产部署、基础设施变更、资金操作和不可逆数据修改，沙箱不能取代业务级门禁。此时仍需要显式审批、最小权限账号、环境隔离、审计日志和可回滚流程，因为风险已经超出“这条 Bash 命令能访问哪些本地资源”。

真正可复用的安全判断，是检查边界而不是统计弹窗

下次配置编程 Agent，不要先问“怎样让它少弹窗”，也不要用“弹窗多所以更安全”安慰自己。先检查四件事：

1. 可写边界：Agent 能修改哪些文件，能否改启动项、工具配置或其他执行入口；
2. 可读边界：SSH、云凭据、Token 与敏感源码是否对执行进程可见；
3. 出站边界：允许连接哪些目标，代理是否只看域名，是否存在 Socket、浏览器或沙箱外命令等旁路；
4. 授权边界：Agent 使用的是长期全量凭据，还是短期、范围受限、可审计的代理能力。

只有这四层足够窄，减少审批才会带来更安全的自主性。否则，少弹窗只是少了一道提醒；多弹窗也只是把系统安全押在用户永远不会疲劳上。