为什么我要在 Docker 容器里跑 AI 编程助手（以及你为什么也应该这么做）

说实话，AI 编程助手这东西，大家的使用方式基本就两种。要么把安全限制全关了，让它在你的机器上随便造；要么就守在旁边，每隔三十秒点一次"允许"，跟拆炸弹似的。两种都挺遭罪的。

我以前就是那个一直点"允许"的人。说实话，这算是负责任的表现。但说实话，真的太影响效率了。每次 Claude Code 想跑个命令、安装个包、改个文件，我就会被从心流状态里硬拽出来，像个监工一样盯着它。

后来看到朋友走另一个极端——完全放飞模式，什么限制都没有，全靠意念和玄学。说实话，这更吓人。这些 agent 确实很强，但它们也很自主，一旦出问题，真的能搞出大事情。

后来找到的中间路线彻底改变了我的工作方式：把编程 agent 本身容器化。

核心思路

其实很简单——别直接在宿主机上跑 AI 编程助手，而是在 Docker 容器里启动它，把工作目录挂载进去。Agent 在容器里折腾，它的破坏能力就被关在笼子里了。就算它想删库跑路？删的也是容器里的文件系统，跟你真实的机器八竿子打不着。

这样你就能真正用 --dangerously-skip-permissions 这种 YOLO 模式了，不用担心自己的 home 目录突然人间蒸发。

来，手把手教你怎么做。

给 Claude Code 配 Docker 环境

最基础的方案就是一个 Dockerfile，大致长这样：

FROM node:20-bookworm-slim

RUN apt-get update && apt-get install -y --no-install-recommends git curl ca-certificates && rm -rf /var/lib/apt/lists/*

RUN curl -fsSL https://claude.ai/install.sh | bash

ENV PATH="/root/.local/bin:${PATH}"

WORKDIR /workspace

ENTRYPOINT ["claude", "--dangerously-skip-permissions"]

构建一次镜像：

docker build -t claude-code .

然后把当前目录挂载进去运行：

docker run -it -v "$PWD:/workspace" claude-code

就这样，Claude Code 跑起来了，能读写你的项目文件。容器在工作目录里可以随便折腾，但跟你的真实系统是隔离的。

认证这事儿得单独处理

问题来了。Mac 上 Claude Code 把凭证存在 Keychain 里，但 Linux 容器不认识 Keychain。所以得换种方式处理认证。

方案是——把 API token 通过环境变量传进去。先拿到 setup token：

claude setup-token

然后写个入口脚本，让它读取 token 并配置容器的凭证文件：

#!/bin/bash
echo "${ANTHROPIC_TOKEN}" > /root/.claude/credentials.json
exec claude --dangerously-skip-permissions

现在跑容器的时候直接传 token：

docker run -it -v "$PWD:/workspace" -e ANTHROPIC_TOKEN="$(claude setup-token)" claude-code

整方便点

说真的，每次都敲这么一大串谁受得了。搞个别名或者 shell 函数：

cc() {
    docker run -it \
        -v "$PWD:/workspace" \
        -v "$HOME/.claude:/root/.claude" \
        -v "$HOME/.claude/skills:/root/.claude/skills" \
        -v "$HOME/.claude/settings.json:/root/.claude/settings.json:ro" \
        -e ANTHROPIC_TOKEN="$(claude setup-token 2>/dev/null)" \
        --env-file ~/.claude/env \
        claude-code "$@"
}

这个配置的好处：

• 当前目录映射成容器的 /workspace
• 你的 Claude 配置和 skills 直接复用
• 环境变量也能传进去（agent 可能需要用到的 API key 就靠这个）
• 随便在哪个目录敲 cc，马上就能召唤出一个完整的编程助手

这个方案保不了什么

这个我得说清楚。容器化保护的是你的宿主机不受 agent 胡搞，但它保不了：

• Prompt injection 攻击：如果攻击者能影响 agent 看到的内容，可能会骗它把你的代码或密钥偷出去
• API key 泄露：agent 该读到还是能读到工作目录和环境变量里的密钥
• 网络攻击：容器还是有网络访问权限的
• 供应链问题：agent 在容器里装的恶意包，该恶意还是恶意

容器化能防的是"agent 手滑删了我整个 home 目录"或者"它跑了 rm -rf / 我系统直接报废"这种情况。对我来说，光是这点就值回投入了。

是不是杀鸡用牛刀？

说实话，看情况。写点小脚本、处理临时任务的时候，我还是会直接用正常模式、正常弹窗点允许。但要是做正经的功能开发、大规模重构，或者在很重要的仓库里干活？这套容器化方案真的帮我省了大量点"允许"的时间，也让我能安心让它跑。

最爽的是，理解了这个思路之后，你可以举一反三。不同的编程 agent 肯定有不同的坑——凭证存在哪、配置文件什么格式、入口点怎么配——但底层逻辑是一样的：把 agent 隔离起来，给它受控的工作目录访问权限，然后放飞自我不用盯着。

总结

现在 AI 编程工具正处于一个有意思的过渡期。安全默认设置保守是有原因的——这些 agent 确实强，确实自主。但保守的默认设置更多是"给试用者设计的"，而不是"给日常专业使用设计的"。

容器化就是弥合这个差距的一种方式。它不是完美的安全方案，但它是实用的保护措施——让你能真正享受到这些工具带来的效率提升，不用在那玩权限弹窗打地鼠。

试试看吧。一旦 alias 配好了，在终端里敲两下 cc 就能在几秒内召唤出一个完整的编程助手，你回不去了的。

你跑 AI 编程 agent 用的是什么配置？还是在那点"允许"？完全放飞？还是有什么容器化技巧我没提到的？欢迎分享，大家交流一下怎么平衡安全性和效率。