AI 编程工具越来越像一个“能干活的实习工程师”。

它可以读项目文件、改代码、安装依赖、执行命令、启动服务，甚至调用 MCP、浏览器自动化工具和各种第三方脚本。

问题也在这里：它越能干，权限就越大；权限越大，风险就越真实。

最近关于 Claude Code 安全性、账号风控、环境变量检测等讨论很多。这里不把未经充分核验的爆料当成定论。对普通用户更有价值的问题不是“某个工具到底有没有后门”，而是：

当 AI Agent 可以在你的电脑上执行命令时，你是否应该让它直接接触整台电脑？

答案很明确：不应该。

更稳的做法是：把 Claude Code、Codex、OpenCode 这类 AI 编程工具放进一个隔离环境里运行。它可以在里面写代码、装依赖、跑测试，但默认看不到你的桌面、浏览器 Cookie、系统配置、其他项目和敏感文件。

这就是 Docker Sandboxes 要解决的问题。

一句话讲明白：Docker Sandboxes 是什么？

Docker Sandboxes 可以理解成一个专门给 AI 编程 Agent 使用的“安全开发舱”。

你不是把 Claude Code / Codex 直接放在自己的电脑系统里跑，而是让它进入一个隔离出来的小环境：

• 它能看到你授权给它的项目目录；

• 它能在沙盒里安装依赖、运行命令、构建项目；

• 它默认不能随便读取你电脑上的其他文件；

• 它的网络访问可以被规则控制；

• 它产生的大部分内部状态可以随着沙盒删除而清理。

对小白来说，可以先记住这个比喻：

以前是让 AI Agent 直接进你家干活；现在是把项目复印到一间工作室，让它只在工作室里干活。

它不是“绝对安全保险箱”，但它把风险边界变清楚了。

图 1：AI Agent 只在授权项目和沙盒边界内工作，默认不直接接触桌面、浏览器 Cookie、其他项目和系统敏感信息。

为什么 AI 编程工具需要沙盒？

因为 AI 编程工具和普通聊天机器人不一样。

普通聊天机器人主要是“回答问题”；Claude Code、Codex 这类工具则是“拿到工具权限后直接执行”。它们可能做这些事：

1. 读取项目文件；

2. 修改代码；

3. 执行 shell 命令；

4. 安装 npm、pip、brew 等依赖；

5. 访问 GitHub、npm、PyPI、模型 API 等网络服务；

6. 调用 MCP、Playwright、浏览器自动化、数据库工具；

7. 执行第三方仓库里的脚本。

这带来的核心矛盾是：

所以，真正成熟的使用方式不是“完全不用 AI 编程工具”，也不是“无脑给最大权限”，而是：

让 Agent 有足够权限完成项目内工作，但没有权限接触不该接触的东西。

这就是沙盒的价值。

图 2：Agent 的自动执行、自动装依赖、自动联网等能力越强，越需要用沙盒把文件访问、网络访问和项目效率放在同一套边界里管理。

使用前先理解三个概念

小白不用先学完 Docker。用 Docker Sandboxes 之前，只要理解三个词就够了。

1. Sandbox：沙盒

沙盒就是一个隔离环境。Agent 在里面运行，能操作的范围被限制在沙盒内部和你挂载进去的项目目录里。

2. Workspace：工作区

Workspace 就是你给 Agent 处理的项目目录。

例如你有一个项目：

~/Projects/my-app

你在这个目录里启动：

sbx run claude

Claude Code 看到的主要就是这个项目，而不是你的整个电脑。

3. Policy：访问规则

Policy 是网络和文件系统访问规则。

比如：

• 允许访问 api.anthropic.com；

• 允许访问 registry.npmjs.org；

• 禁止访问某些域名；

• 团队管理员统一限制哪些路径可以挂载。

如果你不想让 Agent 随便联网，Policy 很关键。

图 3：Workspace 是项目入口，Sandbox 是隔离运行环境，Policy 决定 Agent 能访问哪些网络和文件资源。

第一步：安装 Docker Sandboxes

Docker Sandboxes 的命令行工具叫 sbx。

不同系统安装方式不一样。

macOS

brew trust docker/tap
brew install docker/tap/sbx
sbx login

如果你已经安装了 Homebrew，直接复制执行即可。

Windows

winget install Docker.sbx
sbx login

Windows 用户建议在 PowerShell 里执行。

Linux / Ubuntu

curl-fsSL https://get.docker.com | sudoREPO_ONLY=1sh
sudo apt-get install docker-sbx
sudo usermod -aG kvm $USER
newgrp kvm
sbx login

Linux 上重点注意 kvm 权限。执行 usermod -aG kvm 后，通常需要重新登录，或者用 newgrp kvm 让当前 shell 立即生效。

第二步：登录并选择网络策略

执行：

sbx login

它会打开浏览器，让你用 Docker 账号登录。

第一次登录时，通常会让你选择默认网络策略：

我的建议：小白直接选 Balanced。

原因很简单：你大概率需要访问 GitHub、npm、PyPI、模型 API、容器 registry 等常见开发服务；但又不希望 Agent 想访问哪里就访问哪里。

Balanced 是效率和安全之间比较合理的起点。

第三步：把 Claude Code 放进沙盒运行

进入你的项目目录：

cd ~/Projects/my-app

启动 Claude Code：

sbx run claude

这条命令的意思是：

在当前项目目录上创建或连接一个 sandbox，并在里面运行 Claude Code。

也可以直接指定项目路径：

sbx run claude ~/Projects/my-app

如果你想给这个沙盒起一个固定名字：

sbx run claude --name my-app-claude ~/Projects/my-app

以后无论你在哪个目录，都可以重新连接：

sbx run --name my-app-claude

第四步：确认它真的在沙盒里

进入 Claude Code 后，你可以问它：

你现在是在 sandbox 里运行吗？能看到我电脑桌面上的文件吗？

更直接一点，可以让它尝试查看桌面路径。

如果沙盒生效，它应该无法直接看到你没有挂载进去的桌面文件、浏览器配置、其他项目目录。

这一步不是形式主义。它能帮你建立一个关键认知：

你授权的是这个项目，不是整台电脑。

第五步：日常最常用命令

先记住这几个就够了。

查看已有沙盒

sbx ls

你会看到当前有哪些 sandbox、对应哪个 agent、状态如何、工作目录在哪里。

停止沙盒

sbx stop <sandbox-name>

停止只是暂停，里面装过的依赖、配置、内部状态还在。

删除沙盒

sbx rm <sandbox-name>

如果提示确认，可以按提示操作。你也可以强制删除：

sbx rm --force <sandbox-name>

删除后，沙盒内部安装的包、内部 Docker images、containers、volumes 等状态会被清理。

但注意：如果你用的是 Direct Mode，Agent 已经写到 host 项目目录里的文件不会因为删除 sandbox 而消失。

进入沙盒里的命令行

sbx exec -it <sandbox-name> bash

这适合你手动检查沙盒内部环境，比如看它装了哪些依赖、项目跑在哪里、端口是否启动。

关键选择：Direct Mode 和 Clone Mode 怎么选？

这是使用 Docker Sandboxes 最重要的分叉。

Direct Mode：默认模式，适合日常开发

你在项目目录里运行：

sbx run claude

默认就是 Direct Mode。

特点是：

• 你的项目目录会被直接挂进沙盒；

• Claude Code 在沙盒里改文件；

• 这些改动会立刻出现在你电脑上的项目目录里。

适合场景：

• 修 bug；

• 写小功能；

• 改文档；

• 跑测试；

• 你希望 IDE / Xcode / Cursor 立刻看到改动。

风险是：

Agent 虽然不能乱读整台电脑，但它可以直接改当前项目目录。

所以 Direct Mode 下，最好先确保项目已经被 Git 管理，并且重要改动已提交。

Clone Mode：更隔离，适合高风险任务

如果你担心 Agent 大规模乱改项目，可以用 Clone Mode：

sbx run --clone claude

它会在沙盒内部创建一个私有 Git clone。你的 host 仓库以只读方式挂进去，Agent 在沙盒内部的 clone 里工作。

适合场景：

• 大重构；

• 多方案实验；

• 让 Agent 并行处理多个 issue；

• 不确定它会不会大面积修改代码。

Clone Mode 的代价是：

• host 工作区不会立刻看到改动；

• 你需要通过 Git 把沙盒里的提交取回来；

• 删除 clone-mode sandbox 前，必须确认提交已经 fetch 或 push，否则沙盒里的改动会丢失。

一句话判断：

日常小改用 Direct Mode；不确定后果的大改用 Clone Mode。

图 4：Direct Mode 适合日常小改，但会直接写回本机项目；Clone Mode 适合高风险重构，改动先留在沙盒内部 clone。

给 Claude Code 传参数：中间一定要加 --

这是新手最容易踩的坑。

sbx run 有自己的参数，Claude Code 也有自己的参数。

如果你要把参数传给沙盒里的 Claude Code，中间必须用 -- 分隔。

格式是：

sbx run claude [sbx自己的参数] -- [传给Claude Code的参数]

例如：

sbx run claude --name my-app-claude -- "帮我检查这个项目的登录流程"

如果你要显式传入 Claude Code 的跳过权限确认参数：

sbx run claude -- --dangerously-skip-permissions

如果少了中间的 --，你可能会看到类似错误：

ERROR: unknown flag: --dangerously-skip-permissions

意思是：sbx 把 Claude Code 的参数误认为自己的参数了。

补一句重要提醒：

--dangerously-skip-permissions 在 host 上裸跑风险很高；放进沙盒后风险明显降低，但不是零风险。Direct Mode 下，它仍然能改你挂载进去的项目文件。

Claude Code 的 Agent View 怎么跑？

Claude Code 的 agents view 可以让多个子任务并行工作。

更建议配合 Clone Mode 使用：

sbx run --clone claude -- agents

如果你希望同时保留跳过权限确认模式，可以显式写成：

sbx run --clone claude -- --dangerously-skip-permissions agents

适合用来处理：

• 多个 issue 分析；

• 多个功能点拆分；

• 大项目探索；

• 多分支方案实验。

但小白第一次上手不必急着用这个。先把普通 sbx run claude 跑通，再用 agents view。

Codex、OpenCode 也能放进沙盒吗？

可以。

Claude Code 只是其中一个常见 agent。Docker Sandboxes 也支持 Codex、OpenCode、Gemini CLI、Copilot CLI 等多种 AI 编程工具。

思路是一样的：

sbx run codex

或：

sbx run opencode

实际命令可能会随着各 agent 模板更新而变化。你可以先查看当前支持的模板和 agent：

sbx template ls

或者查官方文档中对应 agent 的页面。

如何管理 API Key 和登录状态？

很多 AI 编程工具需要模型服务的 API Key，比如 Anthropic、OpenAI、GitHub token 等。

不要把 API Key 直接写在代码里，也不要随便发给 Agent。

更推荐用 sbx secret 管理。

例如设置 Anthropic key：

sbx secret set -g anthropic

它会提示你输入 key。

设置 GitHub token：

echo "$(gh auth token)" | sbx secret set -g github

这里的 -g 表示 global，对后续新建 sandbox 生效。

如果你没有 API Key，而是 Claude 订阅用户，也可以进入 Claude Code 后用：

/login

通过 OAuth 登录。

注意：新设置的 global secret 通常不会自动进入已经存在的旧 sandbox。遇到认证异常时，最简单的办法是新建一个 sandbox，或者对具体 sandbox 单独配置。

网络策略：不要让 Agent 想去哪就去哪

沙盒不仅限制文件，还能限制网络。

查看当前策略：

sbx policy ls

查看哪些请求被允许或拦截：

sbx policy log

允许访问某个域名：

sbx policy allow network api.anthropic.com

允许常见 Python / Node 依赖源：

sbx policy allow network "*.npmjs.org,*.pypi.org,files.pythonhosted.org"

拒绝某个域名：

sbx policy deny network ads.example.com

只对某个 sandbox 生效：

sbx policy allow network --sandbox my-app-claude api.example.com

如果你在公司环境里使用，还要注意：

如果组织开启了集中治理，管理员规则会覆盖本机 sbx policy。这时你本地 allow / deny 可能没有效果，需要找管理员改组织策略。

前端项目怎么在浏览器里预览？

沙盒里的服务，host 浏览器默认访问不到。

比如 Agent 在沙盒里启动了一个前端服务，监听端口 3000。

你需要把沙盒端口转发到本机：

sbx ports my-app-claude --publish 8080:3000

然后在浏览器打开：

http://localhost:8080

如果你不想指定 host 端口，可以让系统自动分配：

sbx ports my-app-claude --publish 3000
sbx ports my-app-claude

停止转发：

sbx ports my-app-claude --unpublish 8080:3000

常见坑：前端服务必须在沙盒里监听 0.0.0.0，不能只监听 127.0.0.1。

例如很多 dev server 需要这样启动：

npm run dev -- --host 0.0.0.0

如果你转发了端口还是打不开，优先检查这一点。

Playwright MCP：调试网页，但别碰真实浏览器 Cookie

很多人用 Claude Code 调试前端页面，会接入 Playwright MCP。

放进沙盒后，一个明显好处是：

Agent 可以使用沙盒里的浏览器自动化能力调试页面，但默认不会直接读取你真实 Chrome 浏览器里的 Cookie 和登录态。

这很关键。

因为真实浏览器里可能有：

• 微信公众号后台登录态；

• GitHub 登录态；

• 公司系统 Cookie；

• 邮箱、云盘、支付、管理后台等敏感会话。

建议：

1. 不要把 host 的 Chrome Profile 挂进沙盒；

2. 需要浏览器调试时，用沙盒内的 Playwright 环境；

3. 只给测试账号，不给真实高权限账号；

4. MCP 来源不明时，不要直接安装。

沙盒不是为了让你冒险，而是为了让必要的自动化工作有边界。

更新 Claude Code：更新的是沙盒里的版本

很多人会误解：

我电脑上的 Claude Code 更新了，沙盒里的 Claude Code 就自动更新了吗？

不一定。

沙盒里的 agent 使用的是自己的模板和内部环境。

查看沙盒内 Claude Code 版本：

sbx exec <sandbox-name> claude --version

更新沙盒内 Claude Code：

sbx exec <sandbox-name> claude update

再查看版本：

sbx exec <sandbox-name> claude --version

如果你想让新建 sandbox 使用更新后的模板，可以查看模板：

sbx template ls

小白不建议一上来就乱删 template 或执行 reset。先把当前项目跑通，确实遇到版本问题再处理。

关闭 Docker Sandboxes 的遥测

Docker 官方说明，sbx CLI 会收集基础使用数据，比如运行了什么命令、成功还是失败、耗时等；同时也说明不会监控 session、不会读取 prompts、不会访问代码。

如果你希望关闭 analytics，可以设置环境变量：

export SBX_NO_TELEMETRY=1

macOS / Linux 想长期生效，可以写入 shell 配置：

echo 'export SBX_NO_TELEMETRY=1' >> ~/.zshrc
source ~/.zshrc

验证：

echo $SBX_NO_TELEMETRY

如果输出：

1

说明已经生效。

如果 daemon 之前已经启动，可以重启一次：

sbx daemon stop
SBX_NO_TELEMETRY=1 sbx daemon start-d

新手最容易踩的 8 个坑

图 5：这些坑本质上都指向同一个问题：沙盒能降低风险，但不能替代 Git、最小权限、网络策略和人工审查。

坑 1：把整个 home 目录挂进去

不要这样：

sbx run claude ~

这等于把你的家底都给它看。

更好的做法是：

cd ~/Projects/my-app
sbx run claude

只给它当前项目。

坑 2：Direct Mode 下忘记先提交 Git

Direct Mode 会直接改 host 项目文件。

启动前建议：

git status
git add .
git commit -m "before ai agent changes"

至少要确保当前修改可回滚。

坑 3：传参数忘了 --

错误写法：

sbx run claude --dangerously-skip-permissions

正确写法：

sbx run claude -- --dangerously-skip-permissions

坑 4：Agent 装不了依赖，以为工具坏了

可能只是网络策略拦截。

先查日志：

sbx policy log

再按需放行：

sbx policy allow network "*.npmjs.org,*.pypi.org,files.pythonhosted.org"

坑 5：浏览器打不开沙盒里的服务

通常是两个原因：

1. 没有发布端口；

2. 服务只监听 127.0.0.1，没有监听 0.0.0.0。

处理方式：

sbx ports my-app-claude --publish 8080:3000
npm run dev -- --host 0.0.0.0

坑 6：以为删除 sandbox 会撤销项目改动

不会。

如果是 Direct Mode，Agent 对项目文件的修改已经写到 host 目录里。删除 sandbox 只能清理沙盒内部状态，不能自动恢复项目。

恢复项目请用 Git：

git status
git diff
git restore .

坑 7：Clone Mode 删除前没 fetch

Clone Mode 下，Agent 的提交在沙盒内部 clone 里。

删除 sandbox 前，先确认已经取回：

git fetch sandbox-<sandbox-name>

否则未取回的提交可能丢失。

坑 8：以为沙盒等于绝对安全

沙盒是边界，不是魔法。

它能降低：

• 误读 host 敏感文件的风险；

• 误用 host Docker daemon 的风险；

• 直接访问真实浏览器资料的风险；

• 乱联网的风险；

• 恶意脚本影响整机的风险。

但它不能替你判断：

• 某个依赖是否可信；

• 某个 MCP 是否安全；

• 某段代码是否有后门；

• Agent 对当前项目的修改是否正确。

最终仍然要靠 Git、代码审查、最小权限和可回滚流程。

给普通用户的一套推荐工作流

图 6：先进入项目、查看 Git 状态，再启动沙盒；Agent 做完后检查 diff/status，最后提交、取回或清理。

如果你只是想安全使用 Claude Code / Codex，直接照这个流程来。

日常小改

cd ~/Projects/my-app
git status
sbx run claude --name my-app-claude

让 Agent 做完后：

gitdiff
git status

确认没问题再提交：

git add .
git commit -m "update with ai agent"

高风险重构

cd ~/Projects/my-app
sbx run --clone claude --name my-app-refactor

让 Agent 在 clone 里改。

完成后取回：

git fetch sandbox-my-app-refactor

再审查差异：

git diff main..sandbox-my-app-refactor/<branch>

前端调试

启动沙盒：

sbx run claude --name my-app-frontend

沙盒里启动服务，并确保监听 0.0.0.0。

host 上发布端口：

sbx ports my-app-frontend --publish8080:3000

浏览器访问：

http://localhost:8080

用完清理

sbx ls
sbx stop my-app-claude
sbx rm my-app-claude

长期不用的 sandbox 及时删，避免占用磁盘空间。

最后：真正的问题不是“信不信 AI”，而是“边界有没有设计”

AI 编程工具会越来越强。

未来的 Agent 不只是补全代码，而是会自己拉仓库、读 issue、改架构、跑测试、装依赖、调用浏览器、连接数据库、部署服务。

这时候，继续让它直接裸跑在个人电脑上，本质上就是把一个高权限自动化系统放进你的日常工作环境。

这不是信任问题，而是工程问题。

成熟的工程习惯不是“永远不冒险”，而是把风险限制在可观察、可回滚、可删除的范围里。

Docker Sandboxes 的价值正在这里：

让 AI Agent 继续高效干活，但不要让它默认拥有整台电脑。

对个人开发者来说，记住一句话就够了：

cd 你的项目目录
sbx run claude

从这一步开始，你就不是在“裸奔式使用 AI 编程工具”，而是在给 Agent 建立一个基本安全边界。

本文参考资料

• Docker Sandboxes 官方文档：https://docs.docker.com/ai/sandboxes/

• Docker Sandboxes Get Started：https://docs.docker.com/ai/sandboxes/get-started/

• Docker Sandboxes Usage：https://docs.docker.com/ai/sandboxes/usage/

• Docker Sandboxes Claude Code Agent 文档：https://docs.docker.com/ai/sandboxes/agents/claude-code/

• Docker Sandboxes FAQ：https://docs.docker.com/ai/sandboxes/faq/

• Docker Sandboxes Local Policy：https://docs.docker.com/ai/sandboxes/governance/local/