如果你最近正在折腾 Claude Code、OpenClaw 这类 AI Agent大概率已经体会过那种矛盾它们写代码、跑命令、调接口时就像开了外挂效率高得离谱但某次它突然自作主张执行了一个你没授权的操作你又会后背发凉——这玩意儿到底能在我机器上折腾到哪一步x-cmd 在 v0.8.4 版本里给出的回答很直接给 Agent 套一层安全沙盒让它在受限的权限边界里干活。所谓安全沙盒说白了就是一套“默认拒绝、按需放行”的门禁机制Agent 想执行的命令、想读取的文件、想访问的域名都必须先经过规则检查通过了才放行没通过就拦截并且把拦截记录写进审计日志。这篇文章不聊理论只说我实际配置 Claude Code 和 OpenClaw 的过程、踩过的坑以及我目前仍在用的最小策略长什么样。如果你正好被 Agent 的“自作主张”坑过或者正准备把 Agent 接进自己的工作流这篇应该能帮你少走一段弯路。1. 为什么我决定给 Agent 套沙盒一次让我后背发凉的日志回放1.1 Agent 的权限比你想象的更接近 root先讲一段真实经历。上个月我给 Claude Code 布置了一个任务把项目里的临时文件清理掉顺便整理 dist 目录里的旧产物。结果它很勤快跑了一串 find 加 rm 命令把整个 dist 目录连同我还没导出的一份配置一起删了。我反应过来的时候git 里一片飘红。当时我没有用任何防护单纯是因为觉得“它就在终端里跑我能看到输出”所以没在意。问题就出在这里——你能看到输出不代表你能及时阻止。等你发现不对劲命令早就执行完了。这不是 Claude Code 独有的毛病。只要是 LLM 驱动的 Agent本质上都在做“基于上下文的决策”而它的上下文里可能包含项目文档里的误导信息、来自外部网页的注入内容甚至只是它自己推断出来的错误路径。OpenClaw 这类长期驻留的 Agent 更猛它会自己监听消息、调用工具、决定下一步动作你不可能每条都确认。给 Agent 配上当前用户权限就等于让它能在你的工作目录、配置目录甚至 SSH 密钥目录里随便进出。我算了一笔账一个 Agent 能访问的敏感面至少包括源码目录、构建脚本、环境变量里的各种密钥、云服务的凭据文件、以及它自己生成的会话记录。如果这些全部裸奔那它一次误操作造成的损失可能比它一个月帮我省下的时间还多。所以问题不是“要不要加防护”而是“防护做在哪一层才不耽误干活”。1.2 “人肉盯梢”为什么靠不住有人会说那我全程盯着它不就行了我试过三种盯法全都失败。第一种是全程看屏幕Agent 一停我就切进去看它准备干什么结果半小时后眼睛先受不了而且它的执行速度比我读日志快得多。第二种是强制它每步都停下来确认原本十分钟的活儿拖了一个小时因为大部分确认请求对我而言都是噪音根本提不起精神逐条审。第三种是等任务结束后翻日志但日志动辄上千行人眼检索关键命令的效率实在太低。真正的问题不是“盯不盯得过来”而是缺少一个“提前设限、违规即停”的机制。人类审查是事后诸葛亮的补救规则拦截才是事前控制。就像你雇了个临时工帮你整理仓库你不会等他搬完所有箱子再检查他有没有搬错过而是提前告诉他哪几个架子不能碰。给 Agent 套沙盒就是这个逻辑不是不信任它而是把信任边界提前声明清楚。1.3 为什么不是 Docker也不是虚拟机可能有人会问那为什么不直接上 Docker 或虚拟机我一开始也走了这条路。Docker 确实能把 Agent 关进隔离环境但问题是 Claude Code 要操作的是我宿主机上真实存在的项目OpenClaw 要读写我的配置文件虚拟机加目录挂载加端口映射一套下来配置成本够我写好多行代码了。沙盒的定位和它们不一样沙盒不做完整的运行环境隔离只做“权限边界控制”。打个比方Docker 是给 Agent 单独开一间房沙盒是让它待在你工位旁边工位上的抽屉上了锁它想拉开抽屉必须经过你批准。对日常开发场景来说这个边界粒度刚刚好既能防住危险操作又不会因为环境隔离导致 Agent 什么活都干不了。2. x-cmd 的沙盒边界是怎么划出来的命令、文件、网络、环境四道闸2.1 四道闸各管什么x-cmd 的沙盒模块在 v0.8.4 里把控制面收敛成了四个闸口命令层、文件层、网络层、环境层。命令层管的是 Agent 通过 shell 发起的一切指令文件层管的是它能读哪些路径、能写哪些路径网络层管的是它能访问哪些域名环境层管的是它继承哪些环境变量、工作目录在哪里、最长能跑多久。四层都命中才算合法操作任何一层不满足都会被拦下来。实际用下来命令层是拦截次数最多的也是最容易设计出问题的。因为 Agent 执行任务时产生的 shell 调用千奇百怪你很难穷举它需要哪些命令但你又不能为了省事把所有命令都放开。我的做法是只放行那些“确定无副作用”的只读命令加上少数我明确授权的构建命令其他一律默认拒绝。文件层的设计则要精细一点你把某个目录设为 writableAgent 就能在里面新建和删除文件所以可写范围宁小勿大。2.2 一份最小可用策略长什么样下面这份是我目前用于 Claude Code 日常开发的策略文件名字叫claude-code-dev.yml。它不是最全的但它是能跑通的最小集profile: claude-code-dev shell: allow: - ls - pwd - cat - grep - git status - git diff - find . -maxdepth 3 -type f - npm run build - npm test deny: - rm -rf ~/project/dist - chmod 777 - shutdown fs: read_only: - ~/project/src/** - ~/project/docs/** writable: - ~/project/tmp/** - ~/project/dist/** deny: - ~/.ssh/** - ~/.aws/** - ~/.env net: allow_domains: - api.anthropic.com - *.npmjs.org deny_domains: - *.pastebin.com env: inherit: true mask: - ANTHROPIC_API_KEY - AWS_ACCESS_KEY_ID timeout: max_seconds: 600这个策略的思路很明确默认拒绝只放行开发中确实需要的基础命令和构建命令。注意我特别把rm -rf ~/project/dist放进了 deny 列表因为上面讲过那次事故就出在这种命令上。env.mask的作用是把密钥从子进程可见的环境变量里过滤掉防止 Agent 在不知情的情况下把它们打进日志或者发给第三方。策略里我故意没把vim、curl、wget放进 allow因为这些都是高风险的入口编辑器可以改任意文件curl 和 wget 可以下载执行不明脚本。如果你确实需要 Agent 访问网络就把对应的 API 域名写进net.allow_domains而不是直接给它一个畅通无阻的网络出口。2.3 它比 Docker 轻在哪又比裸奔稳在哪我自己做过一张对比表把 Docker、x-cmd 沙盒和裸奔放在一起看差别就很直观了对比维度Docker 容器x-cmd 沙盒裸奔运行环境隔离完整隔离不隔离无命令级拦截需要额外配置内置规则引擎无文件路径控制挂载配置复杂支持 glob 读写规则无网络域名控制依赖网络策略域名白名单无审计日志依赖容器日志内置审计无配置成本高低零但无保护这张表不是要否定容器。如果你的 Agent 需要接触不可信数据、运行不可信代码那 Docker 依然是更优选。但如果只是让 Claude Code 和 OpenClaw 在日常环境里帮你写代码、管文件沙盒的投入产出比明显更高。我现在的习惯是“能上沙盒就不裸奔必须隔离才上 Docker”。3. 把 Claude Code 装进沙盒三步配置和一次实测3.1 安装 x-cmd 并拉起沙盒模块第一次配置我推荐按三步走装好 x-cmd、写策略文件、跑一次拦截验证。安装 x-cmd 很直接我在 Linux 和 macOS 上用的是官方安装脚本安装完重启终端确认xc命令能正常调用。Windows 上建议先开 WSL在 Linux 环境里跑这样路径和权限模型都统一少踩很多坑如果非要在 PowerShell 里跑就要注意命令名应该写成x-cmd并且路径分隔符要提前确认。拉起沙盒的命令格式是xc sandbox run --policy claude-code-dev.yml -- claude这条命令的意思是用claude-code-dev.yml这份策略包裹 Claude Code策略之外的任何操作都不放行。为了日常使用方便我顺手在 shell 配置里加了个别名alias claude-sboxxc sandbox run --policy claude-code-dev.yml -- claude之后写代码时开claude-sbox而不是直接claude心理负担一下就轻了。3.2 给 Claude Code 写一份克制策略写策略时最常犯的错是只考虑“要允许什么”不考虑“要挡住什么”。我建议从只读开始先把项目源码目录设为read_only把编译产物目录设为writable再把 HOME 下面的敏感目录全部deny。这样 Agent 能安心读代码但不能顺手改源码等它确实需要改文件时你再决定要不要放开 writable 的范围。还有一个很容易被忽略的点策略文件本身要放在 Agent 没权限写的地方。如果你把策略写在~/.x-cmd/sandbox/下同时又把整个 HOME 都设为writable那 Agent 完全可以改写策略文件本身沙盒瞬间形同虚设。我一开始就踩过这个坑浪费了半天排查“为什么规则不生效”。另外如果你给 Claude Code 接入的是 DeepSeek 或其他非官方模型的端点记得把对应的 API 域名补进net.allow_domains。我之前有一次接好之后所有请求全部失败翻审计日志才发现是网络层把模型 API 域名拦了。3.3 验证沙盒是否真在起作用验证沙盒是否真生效简单粗暴的方法就是制造一次“犯规”。让 Claude Code 在沙盒里执行一个被 deny 的命令比如 curl 一个不在域名白名单里的地址或者直接尝试读取~/.ssh/id_rsa。正常情况下命令会被拦截审计日志里会出现一条记录告诉你命中了哪条规则。如果日志里什么都没出现说明 Agent 可能绕过了沙盒包装。这时候要检查是不是用了绝对路径调用程序、或者通过其他 shell 间接起子进程。在 VS Code 里用 Claude Code 插件时需要额外注意插件内部如果直接拉起 Claude Code 进程而不经过xc sandbox run包装那么沙盒是不生效的。我在插件设置里把命令改成xc sandbox run --policy claude-code-dev.yml -- claude之后才真正跑进沙盒。4. OpenClaw 接入沙盒部署时最容易翻车的三处细节4.1 工作目录和记忆文件必须提前放行OpenClaw 这种常驻型 Agent 和 Claude Code 不太一样。Claude Code 是你在终端里临时拉起来干活的而 OpenClaw 通常是跑在后台、监听多个渠道消息、自动调工具和回复的长期进程。它启动时就要初始化会话文件、记忆目录和日志文件如果沙盒策略没把这几个目录提前放行最常见的现象就是启动直接失败或者报锁文件超时。就拿网上反复被问到的 OpenClaw session file locked 问题来说本质是多个进程竞争同一个会话文件。OpenClaw 的 session 文件通常放在~/.openclaw下如果之前有进程异常退出残留进程还占着锁再次启动就会报session file locked (timeout 60000ms)。我排查的时候先用lsof去看哪个进程拿着锁再决定是清理残留进程还是把工作目录切换到新的副本。这个和沙盒本身没直接关系但如果你没把~/.openclaw目录写进 writable 白名单系统里的报错会先以权限问题的形式出现很容易干扰判断。4.2 channel 决定了网络层要开哪些口子OpenClaw 的 channel 选择会直接影响沙盒策略。不同 channel 需要开放的域名完全不同接飞书就要允许飞书的网关域名接 Teams 就要允许微软的域名接本地终端就基本不需要额外网络出口。我在配置 OpenClaw 的时候习惯先定 channel 再写网络白名单。有些人一上来就把所有 channel 都接满结果策略文件越写越乱。我建议先只保留一个 channel 跑通再逐步加。每加一个 channel回来看一遍策略文件把对应的 API 域名补进去。比如说接飞书网络层至少要有这一段profile: openclaw-lark net: allow_domains: - *.openfeishu.cn - *.feishu.cn - api.anthropic.com如果你在 OpenClaw 里把模型配成千问这类第三方服务记得把对应模型的 API 域名也加进去。这个细节很容易漏因为配置模型时你关注的是 Key 和模型名但沙盒关心的是网络出口两者不在同一个界面里所以策略文件反而成了唯一能对上的地方。4.3 Windows 和 Linux 的路径差异跨平台部署的坑主要集中在路径风格上。Windows 原生部署路径用反斜杠在 YAML 策略文件里容易转义出错我的做法是统一在策略层使用正斜杠先做路径归一化再写规则。如果在 WSL 里跑要注意~/.openclaw指的是 WSL 里的 HOME而不是 Windows 用户目录别把策略里的路径写错了。Linux 下用 systemd 跑 OpenClaw 时环境变量是独立维护的沙盒使用的策略文件路径也最好用绝对路径。否则 systemd 的 WorkingDirectory 和你手动测试时不一样可能出现“手动跑一切正常装进 systemd 就报策略找不到”的诡异问题。5. 沙盒跑起来之后的常见报错与排查思路5.1 session file locked多半是残留进程排查这类报错我有一个固定的链路先看进程列表找还有没有老版本的 Agent 在跑再用lsof或者fuser查 session 文件被哪个 PID 占用确认之后清理掉残留进程或者换一个工作目录重新启动。如果你用了沙盒还要顺手看一眼审计日志确认不是策略阻止了进程创建锁文件。这两种情况的处理方式完全不同如果是残留进程直接清理就恢复如果是策略把~/.openclaw的写权限挡了那就要去补充 writable 规则。我遇到过几次以为自己在清理进程结果问题一直复现最后才发现是沙盒策略里少了一条写入规则。所以遇到锁相关报错第一反应应该是“看审计日志再动手杀进程”顺序反了会浪费时间。5.2 Agent execution terminated 这类报错信息量很低Agent execution terminated due to error.这种报错几乎不提供有效信息正确姿势是先看 x-cmd 的审计日志因为它记录了 Agent 每次执行命令时的拦截结果。如果审计日志里没有拦截记录再去翻 Agent 自己的日志。常见的根因有三个网络层没放行对应域名导致 API 请求失败文件层没放行某个写入目录导致任务中途退出以及超时配置过短导致长任务被掐断。把这三个按顺序查一遍大部分问题都能定位。我自己比较常用的做法是查日志时加一个关键字过滤比如把 session 和 permission 一起 grep能在几十行日志里很快找到关键线索。如果 Agent 在飞书这类 IM 渠道里输出容易被截断多半是渠道侧有消息长度限制跟沙盒关系不大要去调整 channel 的消息分割配置。5.3 误拦截处理给策略留一条快速迭代回路沙盒使用一段时间后一定会出现“误拦截”——某个命令其实无害但规则没放行。我维护策略文件的方式是每当 Agent 报错先看审计日志确认是不是某条命令被拦了如果是再判断这条命令是否真的危险没危险就在对应的 allow 列表里加一条。这里有一条很重要的原则一次只加一条加完立刻重跑任务。不要一次性放开一个命令类别否则你根本不知道哪条规则才是真正被需要的。我吃过这个亏为了省事一次放行了所有 git 开头的命令结果 Agent 顺手执行了git push --force把我远程仓库的历史都改了那一次比删除 dist 目录更让我崩溃。最后补一张近期排障的速查表都是我真实遇到过的组合报错现象典型原因处理方式session file locked (timeout 60000ms)残留进程占用会话锁清理占用进程或切换工作目录Agent execution terminated due to error网络、文件权限或超时先查沙盒审计日志再查 Agent 日志curl/wget 请求失败网络层域名白名单未覆盖在 allow_domains 里补对应域名IM 渠道输出被截断渠道侧有消息长度限制调整 channel 消息分割配置策略文件未生效路径写错或环境变量缺失检查绝对路径与 systemd/WSL 的 HOME我个人现在的习惯是所有 Agent 一律先进沙盒策略文件按项目单独维护。给 Claude Code 用偏向读的宽松策略给 OpenClaw 用更窄的、只开放必需 channel 和工具的策略。坚持一段时间之后最大的收获不是拦住了多少个危险命令而是我从“事后翻日志后悔”变成了“事前设规则安心”。最后再分享一个小技巧别把沙盒当成纯粹的限制工具它其实是最好的“日志放大器”。每次 Agent 被拦截都等于它在主动告诉你它想干什么。把这批记录翻出来看你会比任何人都了解自己项目里 Agent 的使用习惯也能逐步把策略打磨得越来越顺手。