Anthropic 为 Claude Code 桌面版开发本地沙箱，这个方向最近很值得关注。原因很简单：Claude Code 不再只是在终端里帮人改代码的命令行工具，而是开始变成带图形界面的桌面应用，能直接关联项目目录、读取文件、执行命令。工具能力变强之后，风险边界也跟着变大。本地沙箱解决的核心问题就是：当 AI 在本地环境里执行命令或读写文件时，怎么把它的影响范围限制在一个可控区域内，而不是直接碰宿主机上的敏感目录和系统配置。
这篇文章适合三类人看：已经在用 Claude Code 的开发者、准备把 AI 编程助手接入真实项目或自动化流程的工程师，以及想了解桌面端 AI 工具安全设计的人。最值得关注的点不是“沙箱是不是万能保险箱”，而是“沙箱到底隔离了什么、怎么配置、怎么验证、哪些场景不该开”。
下面按我实际测试和理解，把这件事拆开讲。
1. 先搞清楚：桌面版和 CLI 版为什么不能共用一套安全思路
很多人容易把 Claude Code 桌面版理解成“带界面的终端命令工具”，觉得安全和 CLI 一样。这个理解不够准确。交互方式变了，安全模型也要跟着变。
1.1 CLI 版的授权习惯到了桌面版会失效
CLI 版最典型的使用场景是用户在终端里发出任务，AI 给出建议命令，用户确认后执行。这种模式下，用户天然会看到完整命令文本，风险感知相对明确。桌面版把流程简化成按钮、确认框和自动执行，用户很容易连续点击“允许”而不逐条检查。同一句rm -rf，在终端里可能会多看两秒，在图形界面里可能就是下意识地确认。所以桌面版需要更强的默认拦截能力，沙箱就是补上这一环。
1.2 桌面版能接触的资源范围更广
CLI 版通常从当前目录开始工作，桌面版则更像一个完整项目工具：它会读取最近项目、扫描工作区、管理多个目录。访问范围变大后，敏感文件暴露面也变大。如果没有沙箱，AI 一旦被误导，或者某个脚本出错，就可能去读.ssh、.aws、.env这类文件。沙箱的价值不是防止 AI“变坏”，而是即使它尝试访问这些路径，也会被权限策略拦下，或者至少弹出一个明确的审批请求。
1.3 沙箱保护的是宿主机，不是 AI
这个认知很重要。沙箱不是给 AI 穿防护服，而是给当前这台机器画一条安全边界。AI 本身没有安全需求，真正需要保护的是机器上的代码、配置、运行服务和用户时间。理解了这一点，才会主动考虑目录颗粒度、命令白名单和网络访问控制，而不是简单地把沙箱开关打开就觉得万事大吉。
1.4 不只是桌面版，CLI 和编辑器扩展也需要同样的边界意识
如果你平时在 VSCode 里使用 Claude Code 扩展，也应该用同一套思路看待权限问题。图形界面会弱化用户对命令的感知，编辑器扩展尤其明显。所以无论你用的是终端 CLI、桌面版还是编辑器插件，都要先确认三个问题：AI 能读哪些目录、能执行哪些命令、能不能访问外部网络。沙箱不是某个平台独有的后门，而是一个应该默认开启的使用习惯。
2. 本地沙箱到底隔离了什么：从命令拦截到网络策略
本地沙箱并不是单一功能，而是一组控制机制的组合。按常见实现来看，至少包含三层：命令执行控制、文件系统访问限制、网络访问策略。
2.1 第一层：命令执行审批和命令白名单
命令执行控制是最直接的一层。常见形式有两种。第一种是全量审批，AI 每次要执行命令都需要用户确认，优点是可控性强，缺点是高频使用时很烦。第二种是白名单模式，只在配置里指定允许执行的命令，比如ls、grep、cat、python3，不在名单里的默认拒绝。交互式使用可以选择审批模式，批量任务或半自动流程更适合白名单。
白名单的粒度也要注意。只写命令名不够，最好能对参数做一定限制。例如允许执行git diff，但默认阻止git push；允许pip install到虚拟环境，但不允许全局安装。判断标准是：这条命令的副作用是否超出了当前任务范围。
2.2 第二层：文件系统访问限制
文件系统隔离决定 AI 能读哪些目录、写哪些目录。一个好的配置至少要有读目录列表、写目录列表和禁止访问路径。常见做法是允许 AI 读写项目工作目录，禁止读取用户主目录下的敏感配置目录。如果项目里存在符号链接，还要考虑沙箱是否按真实路径判断。因为很多项目目录链向其他磁盘，沙箱按真实路径去匹配策略时，可能直接拒绝读写。
这里有一个通用经验：不要只限制“禁止读取.ssh”，还要考虑.env、.aws、credentials这类文件。敏感信息往往不只在一个固定目录里，建议先用小样例测试 AI 能否读取这些路径，再决定是否需要在策略里增加更多禁止项。
2.3 第三层：网络访问策略
网络策略是很多人忽略的一层。AI 执行命令访问外网，有时候是合理需求，比如git fetch、pip download；有时候就是风险来源，比如脚本向外部服务器上传本机文件。沙箱的网络策略通常有三种：默认禁止全部网络、按域名或端口白名单放行、完全放行并记录日志。对大多数开发机来说，我建议先默认禁止，等具体任务确实需要联网时再按需放开。
2.4 不同操作系统的实现差异
沙箱落地方式和操作系统强相关。Linux 上常见的是容器、bubblewrap或权限隔离；macOS 上可能用系统沙箱扩展或用户级权限控制；Windows 上则可能借助进程隔离和文件系统 ACL。桌面版要跨平台，不同平台的沙箱能力不一定完全一致。实测时不要假设“Windows 上能拦的，macOS 上也一定能拦”。判断标准很简单：在你自己的系统上拿敏感目录和危险命令测一下，看它是不是真的被拦住。
2.5 沙箱不是虚拟机
还有一点容易被混淆：沙箱和虚拟机不是一回事。有人把沙箱理解为虚拟机，期待它像快照一样随时回滚，崩溃了还能还原。但本地沙箱通常只做权限和命令控制，不一定提供完整系统快照。如果任务需要强隔离和可回滚环境，应该优先考虑容器或虚拟机，而不是只依赖工具的沙箱配置。沙箱适合解决“AI 的行为边界”问题，虚拟机解决的是“整个环境可重来”的问题，两者定位不同。
3. 实操路径：把桌面版跑起来，再验证沙箱是否生效
理论说清楚了，下面进入实际操作。我不建议一上来就开最大权限跑真实项目，应该先让桌面版能启动，再逐步验证沙箱行为。
3.1 环境准备
运行 Claude Code 桌面版前，先确认基础条件：
- 安装了较新版本的 Node.js LTS。
- 有可用的 API 密钥或账号权限，且已经正确写入环境变量。
- 网络出口能正常访问 Anthropic 官方 API 域名，可以用一次简单的
curl请求验证。 - 磁盘空间和内存要足够。桌面版虽然是本地应用，但涉及项目扫描、日志写入和模型会话缓存，占用不会太低。
不要急着安装一堆扩展和汉化插件。第一次测试时，插件越多，问题越难定位。尤其是第三方汉化包或配置增强工具，可能会覆盖掉原本的默认配置，导致沙箱策略失效。
3.2 安装与启动
安装步骤以官方文档为准。如果是通过 npm 安装，一般是先全局安装 CLI 包，然后在终端执行启动命令进入会话。桌面版则需要在安装完成后从应用列表或启动器打开。安装完成后，先确认版本号，不要直接用最新版的“小版本号”猜测功能。本地沙箱这类能力通常和版本强相关，版本太旧可能连配置字段都不存在。
3.3 找到沙箱配置入口
桌面版里，沙箱配置一般会出现在设置页、项目级配置文件或全局配置文件中。打开配置后，优先找这几个关键词：sandbox、permissions、command approval、file access、network access。如果界面里找不到，就看配置文件里是否存在类似字段。不同版本叫法可能不一样，但思路是一致的。
下面是一个通用示例配置，用来理解参数含义，不是某个版本的官方 schema：
{ "sandbox": { "enabled": true, "working_directory": "/tmp/claude-project", "read_directories": ["/tmp/claude-project"], "write_directories": ["/tmp/claude-project/output"], "allowed_commands": ["ls", "grep", "cat", "python3"], "allow_network": false, "allowed_domains": ["pypi.org", "files.pythonhosted.org"], "log_file": "/tmp/claude-sandbox.log" } }如果你在当前文档里没找到完全一致的字段，不要硬套。先看自己的配置模板，按模板提供的选项来改。
3.4 第一次验证：最小样例测试
开启沙箱后，不要直接跑项目任务。先做一轮最小样例验证，我一般按这个顺序来：
- 启动桌面版，打开一个临时目录作为工作区。
- 让 Claude Code 执行一个高风险的命令，例如删除临时测试目录里的文件，看它是否被拦截或要求审批。
- 让 Claude Code 读取工作区内的普通文件，确认正常功能没有被误伤。
- 让 Claude Code 把内容写入输出目录，确认写权限是否生效。
- 再看一眼日志，确认被拒绝的命令和文件访问记录都能被检索到。
判断标准是：风险操作被拦，普通读写正常，日志完整。如果普通读写也被拦，说明配置过严，需要放宽工作目录权限；如果风险操作也能通过，说明沙箱可能没有真正生效，需要继续检查配置入口和版本。
注意：这里不要一上来就开最大并发，先用一条样例确认输入、输出和日志都正常，再考虑批量任务。
3.5 如果当前版本没有沙箱功能怎么办
如果确认当前版本没有沙箱配置入口，不要到处找“隐藏开关”或第三方补丁。先更新到最新版本，再查官方文档。如果确实没有，就用通用工程手段做替代隔离：单独建一个专用目录作为工作区，用系统账号限制读写权限，或者把 Claude Code 放到容器里运行。这些方法不依赖官方功能，但同样能达到控制影响范围的目的。
4. 沙箱配置参数怎么取舍：默认配置、学习环境和生产任务
沙箱配置没有绝对正确的答案，只有适不适合当前任务。我见过不少人在第一次配置时把所有权限都放开，理由是“这样省事”。短期看确实省事，长期看风险很大。
4.1 默认配置适合学习和验证，不适合生产任务
如果桌面版默认开启沙箱，配置通常比较保守：只允许读写工作目录，允许少量基础命令，网络默认关闭。这种配置适合体验功能和验证流程，但放到真实项目里会很难受，因为git pull、pip install、npm install这类高频操作都会被拦。于是有人想直接关掉沙箱。我建议不要这样做，更合理的办法是根据任务需要，逐步放宽
