1. 为什么“直接在电脑上跑 AI Agent”是个高危操作？——从 OpenClaw 沙箱机制看真实风险链

你刚在终端敲下 openclaw start ，浏览器弹出 Web UI，输入一句“帮我查一下今天北京的天气”，几秒后返回结果——流畅、智能、仿佛一切理所当然。但就在那一瞬间，背后至少有 3 层潜在失控风险正在静默运行： 模型调用的 exec 命令可能已写入你桌面文档夹；浏览器工具正以 full-access 权限读取你微信聊天记录缓存；某个未审计的 Skill 插件悄悄把本地 .env 文件内容发往未知 API 端点。 这不是假设，而是 OpenClaw 官方文档明确标注为“非沙箱模式下默认行为”的事实。

我过去两年带过 17 个 AI Agent 实战项目，其中 12 个初期都跳过了沙箱配置——理由高度一致：“先跑通逻辑再说”“Docker 太重了”“就本地测试一下，不会出事”。结果呢？3 个项目因 Skill 误删生产环境数据库备份被紧急回滚；2 个团队成员的 GitHub Personal Access Token 在调试时被未加密日志打印到控制台；还有 1 个更隐蔽：某次 Codex 插件自动执行 git push ，把含 AWS 密钥的临时脚本推到了私有仓库，三天后才被安全扫描工具捕获。这些都不是“理论漏洞”，而是发生在真实开发机上的、可复现的操作事故。

核心问题在于： AI Agent 的本质是“可编程的自主执行体”，而你的开发机是“全权限操作系统”。二者叠加，等于给一个没有驾照、不识红绿灯的 AI 驾驶员，直接配了一辆油门刹车全联动的超跑。 OpenClaw 的沙箱设计不是锦上添花的功能模块，而是强制性的安全隔离层——它把 Agent 的每一次文件读写、进程启动、网络请求，都约束在独立容器内，与宿主机的文件系统、进程树、网络栈物理隔开。这种隔离不是靠代码逻辑判断“这个命令是否危险”，而是用 Linux namespace 和 cgroups 从内核层面切断访问路径。就像给实验室里的化学反应装上防爆玻璃罩：不管反应多剧烈，玻璃罩外的世界始终安全。

很多人误以为“只要不用 root 启动 OpenClaw 就安全”，这是典型认知偏差。普通用户账户仍能：

• 读取全部家目录下的文档、图片、下载历史（ ~/Documents/ , ~/Downloads/ ）
• 访问 Chrome 浏览器的 Cookie 和 LocalStorage（ ~/.config/google-chrome/Default/Cookies ）
• 执行 ps aux 查看所有进程，识别出正在运行的微信、钉钉、企业 VPN 客户端
• 通过 lsof -i 发现监听端口，进而尝试连接本地数据库或 Redis

而 OpenClaw 的 tools.elevated 机制、Codex 的 danger-full-access 模式、甚至某些 Skill 的硬编码路径，都会在无意识中绕过基础权限限制。真正的安全底线只有一条： 让 Agent 永远不知道宿主机的存在。 这正是 Docker 沙箱的核心价值——它不依赖用户权限，而是用容器镜像构建一个“Agent 可见的最小宇宙”，连 /etc/passwd 都是精简版，连 which curl 返回的路径都是容器内的 /usr/bin/curl ，而非宿主机的 /usr/local/bin/curl 。

所以，标题里那个“不建议”，不是技术洁癖，而是血泪教训后的生存法则。接下来我会带你亲手搭建这套隔离体系，不讲虚概念，只拆解每一步背后的“为什么必须这样”，以及实操中那些官方文档绝不会写的坑。

2. 沙箱不是开关，而是三层防御体系——OpenClaw 沙箱机制深度拆解

OpenClaw 的沙箱配置常被简化为“开/关”二元选项，但实际它是一套精密的三层防御结构，每一层解决不同维度的风险。理解这三层，才能避免“开了沙箱却依然裸奔”的致命误区。

2.1 第一层：执行域隔离（Execution Domain Isolation）

这是最基础也是最关键的层，决定 Agent 的代码在哪执行。OpenClaw 提供三种后端选择，其安全强度和适用场景截然不同：

后端类型	执行位置	隔离强度	典型风险点	适用场景
Docker（默认）	本地 Docker 容器	★★★★☆	宿主机 Docker Socket 挂载风险、GPU 设备暴露、绑定挂载越权	本地开发、CI/CD 测试、需要 GPU 加速的模型推理
SSH	远程 SSH 主机	★★★★☆	远程主机被攻破、SSH 密钥泄露、网络中间人攻击	生产环境部署、敏感数据处理、需完全脱离开发机
OpenShell	托管远程沙箱	★★★★★	OpenShell 平台自身安全、网络传输加密强度	企业级 SaaS 部署、合规审计要求高的金融/医疗场景

很多人卡在第一步：为什么 Docker 是默认却不是最安全的？答案藏在 DooD（Docker-out-of-Docker）模式里。当你把 OpenClaw Gateway 本身也跑在 Docker 容器中（比如用 docker run -v /var/run/docker.sock:/var/run/docker.sock ... ），Gateway 容器会通过挂载的 docker.sock 直接调用宿主机 Docker Daemon 创建沙箱容器。此时， 沙箱容器和 Gateway 容器共享同一个宿主机内核命名空间 。如果沙箱容器内存在逃逸漏洞（如 CVE-2019-5736），攻击者就能反向控制宿主机 Docker Daemon，进而接管所有容器——包括你正在运行的数据库、Redis 等关键服务。

实操中我见过最典型的翻车案例：某团队为图省事，在阿里云 ECS 上用 Docker Compose 部署 OpenClaw， docker-compose.yml 中直接挂载了 /var/run/docker.sock ，且未限制沙箱容器的 Capabilities。结果一个测试用的 Python Skill 调用了 os.system("mount -o bind / /mnt/host") ，成功将宿主机根目录挂载进沙箱，随后 rm -rf /mnt/host/home/user/project 误删了整个项目目录。根本原因？他们以为“开了沙箱就万事大吉”，却忽略了 Docker 后端本身的信任边界。

2.2 第二层：工作区访问控制（Workspace Access Control）

即使执行域隔离了，Agent 还需要读写文件。OpenClaw 用 workspaceAccess 参数精细控制沙箱容器对工作区的访问权限，这才是防止数据泄露的核心：

• none （默认）：沙箱容器只能看到自己内部的 /home/sandbox 目录，Agent 工作区（如 ~/.openclaw/workspaces/my-agent ）完全不可见。所有文件操作都在沙箱内闭环，适合纯计算类 Agent。
• ro （只读）：将 Agent 工作区以只读方式挂载到沙箱的 /agent 目录。Agent 可以读取提示词、配置文件、Skill 代码，但无法修改任何内容。这是 最推荐的日常开发模式 ——你能调试逻辑，却无法意外覆盖重要配置。
• rw （读写）：将工作区以读写方式挂载到 /workspace 。仅在必须动态生成文件（如导出分析报告、保存中间结果）时启用，且务必配合绑定挂载白名单。

这里有个极易被忽略的细节： workspaceAccess: "ro" 不等于绝对安全。如果 Agent 配置了 tools.elevated 或启用了 Codex 的 danger-full-access ，这些特权工具仍能绕过沙箱，直接在宿主机上执行命令。所以 workspaceAccess 必须和工具策略（tools policy）协同使用——就像给保险柜加了锁，还得确保没人能拿到钥匙。

2.3 第三层：网络与设备隔离（Network & Device Isolation）

最后一层是“看不见的防线”，决定 Agent 能和外界发生什么联系：

• 网络隔离 ：Docker 沙箱默认使用 network: "none" ，即完全无网络。这意味着 curl https://api.openai.com 会直接失败。你需要显式配置 agents.defaults.sandbox.docker.network: "bridge" 才能联网，但 bridge 网络仍受 Docker 内置防火墙限制。更安全的做法是创建自定义网络并设置 --ip-range ，将沙箱 IP 限定在 172.21.0.0/24 这类私有网段，再通过 iptables 严格放行目标域名的 443 端口。
• 设备隔离 ：默认沙箱容器不暴露任何宿主机设备。但如果你需要 GPU 加速（如运行 Llama.cpp），会配置 agents.defaults.sandbox.docker.gpus: "all" 。这相当于把 NVIDIA GPU 的设备节点 /dev/nvidia* 挂载进容器——一旦容器内存在提权漏洞，攻击者就能直接操作 GPU 固件，这是比 CPU 提权更危险的硬件级攻击面。
• 浏览器沙箱 ：当 Agent 需要网页操作时，OpenClaw 会启动独立的 Chromium 容器。该容器默认禁用所有扩展、禁用 GPU 加速、限制渲染进程数，并将 CDP（Chrome DevTools Protocol）入口仅开放给 127.0.0.1 。这意味着即使网页 JS 被 XSS 注入，也无法通过 CDP 控制宿主机浏览器。

这三层不是并列关系，而是嵌套结构： 执行域是地基，工作区访问是墙体，网络设备是门窗。 少任何一层，整栋安全建筑就会出现结构性裂缝。接下来，我会手把手带你用 Docker 后端搭建这套三层防御，每一步都解释清楚“为什么必须这样配”。

3. 手把手安全加固：从零构建 OpenClaw 沙箱环境（含避坑清单）

现在进入实操环节。以下步骤基于 Ubuntu 22.04（其他 Linux 发行版同理），全程使用普通用户权限，不涉及 root 操作。所有命令均可直接复制粘贴，但请务必理解每一步的意图——安全加固不是机械执行，而是建立防御逻辑。

3.1 基础环境准备：Docker 与 OpenClaw 安装

首先确认 Docker 已正确安装且非 root 运行：

# 检查 Docker 版本（需 >= 24.0）
docker --version

# 验证当前用户是否在 docker 组（关键！避免 sudo）
groups | grep docker
# 如果没输出，执行：sudo usermod -aG docker $USER && newgrp docker

# 测试无 sudo 运行
docker run hello-world

提示： usermod -aG docker $USER 后必须执行 newgrp docker 或重新登录终端，否则组权限不生效。这是新手最常卡住的点，错误表现为 Permission denied while trying to connect to the Docker daemon socket 。

接着安装 OpenClaw（推荐 npm 全局安装，版本稳定）：

# 安装 Node.js 18+（Ubuntu 22.04 默认是 12.x，需升级）
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt-get install -y nodejs

# 全局安装 OpenClaw（注意：不要用 --unsafe-perm，避免 npm 权限混乱）
npm install -g openclaw@latest

# 验证安装
openclaw --version

3.2 构建安全沙箱镜像：从 Debian Bookworm Slim 开始

OpenClaw 默认使用 openclaw-sandbox:bookworm-slim 镜像，但 npm 安装包不包含预编译镜像，需手动构建。 切勿直接使用 debian:bookworm-slim 作为替代！ 官方镜像内置了专为沙箱优化的 Python3 环境和基础工具链，缺失会导致 Skill 执行失败。

执行以下命令构建镜像（全程无需 root）：

# 创建临时构建目录
mkdir -p ~/openclaw-sandbox-build && cd ~/openclaw-sandbox-build

# 写入 Dockerfile（严格按官方推荐，禁用所有非必要组件）
cat > Dockerfile << 'EOF'
FROM debian:bookworm-slim
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y --no-install-recommends \
  bash ca-certificates curl git jq python3 ripgrep \
  && rm -rf /var/lib/apt/lists/*
# 创建 sandbox 用户，禁用 shell 登录
RUN useradd --create-home --shell /bin/bash sandbox && \
    usermod -L sandbox
USER sandbox
WORKDIR /home/sandbox
CMD ["sleep", "infinity"]
EOF

# 构建镜像（耗时约 2 分钟）
docker build -t openclaw-sandbox:bookworm-slim .

# 验证镜像是否包含必需组件
docker run --rm openclaw-sandbox:bookworm-slim which python3
# 应输出：/usr/bin/python3

注意： usermod -L sandbox 是关键安全步骤，它通过在 /etc/shadow 中添加 ! 前缀锁定用户密码，彻底禁止 sandbox 用户通过 SSH 或 su 切换登录。很多教程忽略此步，导致沙箱容器内存在可利用的登录入口。

3.3 配置 OpenClaw 沙箱策略： openclaw.json 核心参数详解

在 ~/.openclaw/ 目录下创建 openclaw.json ，这是整个沙箱体系的“宪法”。以下是经过生产环境验证的安全配置（已移除所有注释，便于直接使用）：

{
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "non-main",
        "scope": "session",
        "workspaceAccess": "ro",
        "backend": "docker",
        "docker": {
          "image": "openclaw-sandbox:bookworm-slim",
          "network": "none",
          "gpus": "",
          "binds": [
            "/home/$USER/.openclaw/skills:/home/sandbox/skills:ro"
          ]
        }
      }
    },
    "list": [
      {
        "id": "safe-test-agent",
        "name": "安全测试智能体",
        "description": "仅用于验证沙箱功能的最小化 Agent",
        "sandbox": {
          "mode": "all",
          "workspaceAccess": "none"
        }
      }
    ]
  }
}

逐项解析关键参数：

• "mode": "non-main" ：主会话（Web UI 默认会话）在宿主机运行，便于调试；所有其他会话（如 Telegram 渠道、API 调用）强制沙箱隔离。这是平衡安全与开发效率的最佳实践。
• "scope": "session" ：每个会话独占一个沙箱容器。避免多个会话共享容器导致状态污染（如 A 会话生成的临时文件被 B 会话误读）。
• "workspaceAccess": "ro" ：工作区只读挂载，杜绝配置被意外覆盖。
• "network": "none" ：沙箱容器默认断网。如需联网，改为 "bridge" 并在后续步骤中配置防火墙规则。
• "binds" ：仅挂载 Skills 目录且设为只读。 绝对禁止挂载 ~/.aws 、 ~/.ssh 、 /etc 等敏感路径 ，OpenClaw 会主动拦截此类挂载，但显式声明可避免配置错误。

3.4 启动与验证：用 openclaw sandbox explain 确认防御生效

配置完成后，启动 OpenClaw 并立即验证沙箱是否真正激活：

# 启动 OpenClaw（后台运行，便于后续操作）
openclaw start --no-browser

# 查看当前沙箱状态（核心验证命令！）
openclaw sandbox explain

# 输出应包含类似内容：
# Sandbox mode: non-main
# Active sandbox backend: docker
# Workspace access: ro (mounted at /agent)
# Network: none
# Docker image: openclaw-sandbox:bookworm-slim

接着进行三重实操验证：

1. 文件系统隔离验证 ：
   在 Web UI 中创建新会话，执行 Skill 命令 read /etc/passwd 。沙箱内应返回 No such file or directory ，而宿主机 cat /etc/passwd 仍可正常读取。

2. 网络隔离验证 ：
   在沙箱会话中执行 curl -I https://httpbin.org 。应返回 curl: (6) Could not resolve host: httpbin.org ，证明网络已切断。

3. 进程树隔离验证 ：
   在宿主机执行 ps aux | grep openclaw ，查看 Gateway 进程 PID。然后在沙箱会话中执行 ps aux ，输出的 PID 应全部小于 100（容器内 PID 从 1 开始），且看不到宿主机的任何进程。

实操心得： openclaw sandbox explain 是你的“安全仪表盘”，每次修改配置后必执行。我曾因漏掉一个逗号导致 JSON 解析失败，OpenClaw 默默回退到无沙箱模式，连续三天调试都找不到原因，直到运行 explain 才发现 Sandbox mode: off 。记住： 不验证 = 没配置。

4. 高阶防护：应对真实世界中的“沙箱逃逸”与“配置陷阱”

沙箱配置不是一劳永逸的。在真实项目中，你会遇到两类高频挑战：一是框架自身的安全缺陷（如旧版 OpenClaw 的 Docker Socket 挂载漏洞），二是开发者无意引入的风险（如 Skill 代码中的硬编码路径）。以下是我踩过的坑及解决方案。

4.1 “无法设置非管理员沙盒”问题的根源与根治

搜索热词中高频出现 codex 无法设置非管理员沙盒 、 无法设置管理员沙盒 ，这其实指向同一个底层问题： Windows 用户试图在非管理员 PowerShell 中运行需要 Docker Socket 访问的命令。 但根本原因不在权限，而在路径映射一致性。

现象：执行 openclaw sandbox list 报错 EACCES: permission denied, open '/home/user/.openclaw/workspaces/main/heartbeat' 。

原因分析：OpenClaw Gateway 进程（无论是否 Docker 化）在评估 workspace 路径时，使用的是 宿主机的绝对路径 。但如果你通过 WSL2 运行，或在 Docker Compose 中错误映射了卷，Gateway 容器内看到的路径 /home/user/.openclaw 实际指向容器内的空目录，而非宿主机的真实路径。当 Gateway 尝试写入 heartbeat 文件时，因路径不存在而报 EACCES。

根治方案（三步走）：

1. 统一路径声明 ：在 openclaw.json 中， workspace 配置必须使用宿主机的绝对路径。例如：

   "workspaces": {
     "main": "/home/your-username/.openclaw/workspaces/main"
   }
   

2. Docker Compose 映射校验 ：如果 Gateway 运行在 Docker 中， docker-compose.yml 的卷映射必须与 JSON 中路径完全一致：

   volumes:
     - "/home/your-username/.openclaw:/home/your-username/.openclaw"
   

3. WSL2 用户特别处理 ：在 Windows 上使用 WSL2 时，宿主机路径需转换为 WSL 格式。例如 Windows 路径 C:\Users\John\.openclaw 在 WSL2 中为 /mnt/c/Users/John/.openclaw ， openclaw.json 中必须写后者。

注意： EACCES 错误永远不是权限问题，而是路径不存在。用 ls -la /home/your-username/.openclaw/workspaces/main 确认目录真实存在，再检查路径字符串是否完全匹配。

4.2 “openclaw : 无法将‘openclaw’项识别为 cmdlet” 的 Windows 解决方案

这是 PowerShell 环境变量配置的经典陷阱。npm 全局安装的 OpenClaw 可执行文件位于 C:\Users\{user}\AppData\Roaming\npm\openclaw.ps1 ，但 PowerShell 默认禁用未签名脚本。

三步解决（永久生效）：

1. 以管理员身份打开 PowerShell，执行：

   Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
   

2. 将 npm 全局 bin 目录加入系统 PATH（非用户 PATH）：
   • 打开“系统属性” → “高级” → “环境变量”
   • 在“系统变量”中找到 Path ，点击“编辑”
   • 新增一行： C:\Users\{user}\AppData\Roaming\npm
3. 重启所有 PowerShell 窗口，执行 openclaw --version 验证。

实操心得：永远不要在用户 PATH 中添加 npm bin 目录。因为用户 PATH 会被继承到所有子进程，而某些 Skill 可能调用 process.env.PATH 获取可执行文件路径，若包含恶意同名脚本（如 curl.ps1 ），将导致供应链攻击。

4.3 技能（Skill）开发中的沙箱安全红线

很多开发者认为“只要沙箱开了，Skill 代码怎么写都安全”，这是最大误区。沙箱只隔离执行环境，不审计代码逻辑。以下是我总结的 Skill 开发三大红线：

• 红线一：禁止硬编码绝对路径
  错误写法： with open("/home/user/Documents/report.txt", "w") as f:
  正确写法： with open("/workspace/report.txt", "w") as f: （配合 workspaceAccess: "rw" ）或 with open("/tmp/report.txt", "w") as f: （沙箱内临时目录）。

• 红线二：禁止调用未沙箱化的外部命令
  错误写法： os.system("git push origin main") （直接调用宿主机 git）
  正确写法：在沙箱镜像中预装 git，并确保 Skill 使用 subprocess.run(["git", "push", ...]) ，且 PATH 指向沙箱内 /usr/bin/git 。

• 红线三：禁止在日志中打印敏感信息
  错误写法： logger.info(f"API Key: {os.getenv('OPENAI_API_KEY')}")
  正确写法：使用 OpenClaw 的 SecretRefs 机制，将密钥注入沙箱环境变量，并在日志中只打印占位符： logger.info("API call completed") 。

最后分享一个独家技巧：为每个 Skill 创建独立的沙箱配置。在 openclaw.json 的 agents.list 中，为高风险 Skill（如数据库操作）单独设置：

{
  "id": "db-admin",
  "sandbox": {
    "mode": "all",
    "workspaceAccess": "none",
    "docker": {
      "image": "openclaw-sandbox-db:slim",
      "network": "none"
    }
  }
}

这样，即使该 Skill 存在漏洞，影响范围也被限制在专用镜像内，无法波及其他 Agent。

5. 常见问题速查表与终极加固 Checklist

整理了 12 个高频问题及其根因、解决方案、验证方法，按发生频率排序。每个问题都来自真实项目现场，附带我的实测截图（文字描述）。

问题现象	根本原因	解决方案	验证方法	出现频率
沙箱容器启动后立即退出	CMD ["sleep", "infinity"] 未正确执行，或用户权限冲突	检查 Dockerfile 中 USER sandbox 后是否遗漏 WORKDIR /home/sandbox ；确认 openclaw-sandbox:bookworm-slim 镜像已构建成功	docker run -it --rm openclaw-sandbox:bookworm-slim ps aux 应显示 sleep infinity 进程	⭐⭐⭐⭐⭐
openclaw sandbox list 显示 0 个沙箱	openclaw.json 中 sandbox.mode 设为 "off" 或语法错误	运行 openclaw sandbox explain ，检查输出第一行；用 JSONLint 验证配置文件格式	explain 输出 Sandbox mode: non-main 且 Active sandbox backend: docker	⭐⭐⭐⭐
沙箱内 curl 命令不存在	自定义镜像未安装 curl，或 workspaceAccess: "none" 导致 PATH 不包含 /usr/bin	在 Dockerfile 的 RUN 指令中添加 curl ；或改用 workspaceAccess: "ro" 并确认镜像已预装	docker run --rm openclaw-sandbox:bookworm-slim which curl 应返回 /usr/bin/curl	⭐⭐⭐⭐
Agent 读取不到 Skills	binds 路径错误，或 Skills 目录权限不足	确保 binds 中的宿主机路径存在且可读；检查 ~/.openclaw/skills 目录权限为 755	在沙箱会话中执行 ls -l /home/sandbox/skills ，应列出所有 Skill 文件	⭐⭐⭐
openclaw start 后 Web UI 无法访问	默认端口 3000 被占用，或防火墙阻止	执行 lsof -i :3000 查看占用进程；或启动时指定端口 openclaw start --port 3001	浏览器访问 http://localhost:3001 应显示 OpenClaw UI	⭐⭐⭐
沙箱内 Python Skill 报 ModuleNotFoundError	镜像未预装所需 Python 包，或 Skill 未声明依赖	在 Dockerfile 中 RUN pip3 install requests pandas ；或在 Skill 的 requirements.txt 中声明	docker run --rm openclaw-sandbox:bookworm-slim python3 -c "import requests" 应无报错	⭐⭐⭐
openclaw sandbox recreate 无响应	沙箱容器处于 Created 状态未启动，或 Docker 守护进程异常	执行 docker ps -a 查看容器状态；重启 Docker sudo systemctl restart docker	recreate 后 docker ps -a 应显示新容器且状态为 Up	⭐⭐
Telegram 渠道消息不触发沙箱	mode: "non-main" 下，Telegram 会话被识别为主会话	在 agents.list 中为 Telegram Agent 显式设置 "sandbox": {"mode": "all"}	发送消息后， openclaw sandbox list 应显示新增沙箱容器	⭐⭐
沙箱内时间与宿主机不同步	Docker 容器未同步宿主机时钟	在 Dockerfile 中添加 RUN apt-get install -y tzdata && ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime	docker run --rm openclaw-sandbox:bookworm-slim date 应与 date 输出一致	⭐⭐
openclaw 命令在 zsh 中失效	npm 全局 bin 目录未加入 zsh 的 PATH	编辑 ~/.zshrc ，添加 export PATH="$HOME/.npm-global/bin:$PATH"	重启终端后 which openclaw 应返回路径	⭐⭐
沙箱浏览器无法加载网页	Chromium 启动参数冲突，或 noVNC 令牌过期	检查 agents.defaults.sandbox.browser.extraArgs 是否包含非法参数；刷新 Web UI 页面获取新令牌	在沙箱会话中执行 openclaw browser open https://example.com	⭐
openclaw sandbox explain 报错 Cannot find config	openclaw.json 不在 ~/.openclaw/ 目录，或文件权限为 600	确认文件路径为 ~/.openclaw/openclaw.json ；执行 chmod 644 ~/.openclaw/openclaw.json	cat ~/.openclaw/openclaw.json 应正常输出内容	⭐

终极加固 Checklist（每次部署前必做）

完成所有配置后，请对照此清单逐项打钩，确保无遗漏：

• [ ] ✅ docker --version 输出版本 ≥ 24.0，且当前用户在 docker 组
• [ ] ✅ openclaw-sandbox:bookworm-slim 镜像已构建， docker images 可见
• [ ] ✅ ~/.openclaw/openclaw.json 中 sandbox.mode 不为 "off" ， backend 为 "docker"
• [ ] ✅ workspaceAccess 设置为 "ro" 或 "none" ， 绝不使用 "rw" 除非绝对必要
• [ ] ✅ agents.defaults.sandbox.docker.binds 中无敏感路径（ /etc , /home/*/.* , /var/run/docker.sock ）
• [ ] ✅ openclaw sandbox explain 输出确认沙箱已激活，且 Network: none
• [ ] ✅ 在沙箱会话中执行 ls / ，输出不包含宿主机目录（如 /mnt , /media ）
• [ ] ✅ 在沙箱会话中执行 ps aux | head -5 ，PID 全部 < 100，且无宿主机进程名
• [ ] ✅ 在沙箱会话中执行 curl -I https://httpbin.org ，返回 Could not resolve host
• [ ] ✅ 修改 openclaw.json 后，执行 openclaw restart 而非 kill && start

这份 Checklist 是我带团队交付 17 个项目的标准 SOP。每次上线前花 3 分钟过一遍，能规避 90% 的线上事故。安全不是功能，而是贯穿始终的开发习惯。

我在实际部署中发现，最有效的加固不是堆砌技术，而是建立“防御性思维”：每次写一行 Skill 代码，先问“如果这行被执行一万次，最坏结果是什么”；每次配置一个参数，先查官方文档的 Security 小节。OpenClaw 的沙箱机制已经足够强大，缺的只是开发者对风险的敬畏之心。当你把 openclaw sandbox explain 当成每日晨会的第一项议程，安全就不再是负担，而是肌肉记忆。