最近我把 Claude Code、Codex 和 OpenCode 这三款 AI 编程助手装进了同一个 Docker 容器里用下来最大的感觉是以前那种“装一个新工具就要折腾一次环境”的日子总算结束了。如果你也经常在几个 AI 编程助手之间来回切换或者被不同运行时的依赖冲突、登录态丢失、配置互踩折腾得够呛这篇文章应该能帮你省下不少时间。我先把这套方案说清楚它不是一个复杂的平台只是一个基于 Docker 的开发容器把三个主流的终端 AI 编程工具预装好、登录态目录单独挂载出来、网络与权限配置统一管理。你可以在任意一台装了 Docker 的机器上把它跑起来Windows、macOS、Linux 都行进容器就是一套干净的、开箱即用的 AI 编程环境。适合谁看想系统搭一套可复用的 AI 辅助开发环境的同学、被“装完 A 工具就破坏了 B 工具”折磨过的老手以及刚入坑想少踩坑的新手都可以直接参考。1. 为什么要把三个 AI 编程助手装进同一个 Docker 环境1.1 三个工具到底分别擅长什么先说清楚这三个工具是什么因为在很多讨论里它们经常被混为一谈。Claude Code 是 Anthropic 官方的终端编程助手核心优势是长上下文理解能力适合面对复杂代码库做分析和多文件改动Codex 是 OpenAI 的 CLI 编程工具跟 ChatGPT 生态绑定得比较紧也支持通过 OpenAI 兼容接口接入其他模型服务OpenCode 是一个开源终端 AI 编码助手最大特点是“聚合”可以在同一个界面里切换多家模型供应商。它们的关系不是谁替代谁而是互补。我日常的使用习惯是大范围重构优先开 Claude Code需要跟 OpenAI 生态的东西打交道时用 Codex想快速对比多个模型在同一任务上的表现时用 OpenCode。三个工具都是 Node.js 生态的安装方式高度相似这反而是容易出问题的地方。全局 npm 包互相之间的版本依赖、不同工具对 Node 版本的要求、登录态的存放路径这些在裸机环境里很容易互相干扰。比如我早期在 macOS 上直接装Claude Code 用得好好的某次升级完 Codex 之后Claude Code 竟然报 Node 版本不兼容。这种问题维护成本很高也是我下定决心用 Docker 隔离的直接原因。1.2 Docker 一站式方案的出发点这套方案的核心思路是把工具链和环境彻底隔离把状态数据挂载出来。工具装在容器里容器坏了直接删掉重建登录态放在宿主机目录里容器销毁也不丢。这样既避免了多个 CLI 工具在宿主机上抢占全局资源又保证了换机器、换系统之后的迁移成本几乎为零。另外一个很实际的收益是网络出口的统一。多个 AI 编程工具都要调用各自的远程 API如果每个工具单独配置网络环境出错的时候很难判断是哪一层的问题。放进同一个容器之后所有工具走同一个网络出口排查问题的范围一下子小了很多。对于经常需要同时调试多个工具的人来说这一点比想象中更重要。2. 环境准备Docker Desktop 与基础镜像选择2.1 安装 Docker Desktop 并启用 WSL2如果你在 Windows 上操作第一步是把 Docker Desktop 装好并且确认后端用的是 WSL2。安装本身不复杂但很多人卡在一个报错上Docker Desktop failed to start because virtualization support is not detected。这个错误的意思是 Windows 的虚拟化能力没有打开或者没有被 Docker 识别。我的处理顺序是先重启进 BIOS 确认虚拟化技术已开启Intel 的 VT-x 或 AMD 的 SVM然后在 Windows“启用或关闭 Windows 功能”里勾选“虚拟机平台”和“适用于 Linux 的 Windows 子系统”重启之后打开管理员 PowerShell 执行wsl --update拉取最新内核最后再启动 Docker Desktop。实测下来90% 的虚拟化报错都能通过这三步解决。如果你用的是老电脑还要留意 BIOS 里虚拟化开关的位置可能藏得比较深不同主板叫法不太一样搜一下主板型号对应的方法比较快。Docker Desktop 启动成功之后在设置里把 WSL2 作为默认后端。这里有个容易被忽略的点WSL2 的发行版如果长时间没更新Docker 的启动速度会明显变慢而且偶尔会出现文件同步异常。建议装完 Docker Desktop 之后顺手wsl --update一劳永逸。2.2 基础镜像选择与目录结构设计三个 AI 编程工具都是 Node 生态所以基础镜像选官方 Node LTS 版本最省心。我建议用node:22-slim这个镜像体积小自带 npm装完工具之后整体镜像也就几百 MB比装满桌面环境的镜像清爽得多。镜像里还需要git和ca-certificates前者是 AI 编程助手读取代码库信息的依赖后者解决 HTTPS 证书验证的问题。如果你要跑一些 Python 脚本也可以顺手装一个python3不装也不影响三个工具的正常使用。目录结构上我强烈建议把“代码”和“状态”分开。代码目录就是一个普通的工作区挂载进去用来读写项目文件状态目录则是三个工具的配置和登录缓存单独挂载出去。我的目录设计大概是这样services: ai-dev: image: node:22-slim container_name: ai-coding-box working_dir: /workspace volumes: - ./workspace:/workspace - ./data/claude:/root/.claude - ./data/codex:/root/.codex - ./data/opencode:/root/.opencode - ./data/ssh:/root/.ssh:ro - ./data/gitconfig:/root/.gitconfig:ro tty: true stdin_open: true extra_hosts: - host.docker.internal:host-gateway command: tail -f /dev/null把.claude、.codex、.opencode这些登录态目录挂载出来是最值得做的一件事。我第一次搭这套环境的时候没这么做后来容器删掉重建三个工具全部需要重新登录每个工具都要重新过一遍认证流程非常浪费时间。挂载之后哪怕容器被销毁重新docker compose up -d再进容器登录态全部还在。host.docker.internal这条配置也不可少后面让容器里的 Claude Code 调用宿主机上的 LM Studio 本地模型时全靠这个地址访问宿主服务。Docker Desktop 的 Windows 和 macOS 版本默认支持这个域名Linux 上则需要通过extra_hosts显式声明这也是我在这份配置文件里加上它的原因。3. 三个编程助手的安装与配置全流程3.1 安装 Claude Code 并处理登录认证进入容器之后先更新基础环境再安装三个工具。命令如下apt-get update apt-get install -y git ca-certificates npm install -g anthropic-ai/claude-code安装完直接运行claude就会进入交互式登录流程。个人账号一般选 Subscription 方式登录也就是用 Claude 账号授权如果你拿到的是 API Key也可以走 API 方式。这里有个常见的坑如果你所在的账号是被某个组织托管的而组织管理员关闭了 Claude Code 的使用权限登录或者使用时就会看到类似 your organization has disabled claude subscription access for claude code 的提示。这个不是安装问题是账号权限问题排查方向应该是联系组织管理员确认是否开放了 Claude Code 权限而不是反复重装。Claude Code 登录成功之后终端会提示初始化项目目录建议在一个已初始化的 Git 仓库里跑因为它非常依赖 Git 历史来理解代码变更。你要是在一个没有 Git 仓库的目录里启动它很多能力会受限体验会大打折扣。3.2 安装 Codex 并把它接入 DeepSeekCodex 的安装同样是 npm 一把梭npm install -g openai/codex运行codex进入登录流程选择 ChatGPT 账号登录或者 API Key 方式。有一点要注意Codex 的配置文件路径在不同版本里有过调整目前新版稳定在~/.codex/config.toml。如果你之前用过旧版本升级之后发现配置不生效先看看是不是config.yaml换成了config.toml旧文件不会自动迁移。Codex 的一大好处是支持 OpenAI 兼容接口所以接入 DeepSeek 这类第三方模型服务是可以直接落地的。我的配置是这样model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api responses然后把DEEPSEEK_API_KEY写进容器的环境变量重启终端后运行codex它就会用 DeepSeek 的模型来干活。这里有个细节wire_api字段在部分版本里只支持responses协议如果你在调用/responses接口时遇到 404 或者 unsupported 的错误可以把wire_api改成chat也就是走传统的 chat completions 接口。不同模型服务商对这两种协议的兼容程度不一样遇到问题先检查这一项是我排查下来最高频的解决方案。3.3 安装 OpenCode 与免费额度限制的处理OpenCode 的安装方式官方提供了 npm 包npm install -g opencode-ailatest装完直接运行opencode它会让你选择要接入的模型供应商登录之后就能在终端里对话了。OpenCode 的定位是聚合入口所以它的模型供应商列表非常长我一般只添加自己真正在用的那两三个避免每次启动都要去遍历所有 provider。很多人第一次用 OpenCode 会碰到一个提示opencodes free tier can only be used from within opencode。直白说就是免费额度只能在 OpenCode 官方终端应用内部使用你不能绕过它的应用界面直接把它的后端接口拿去做别的集成。解决办法有两个如果你只是个人在终端里用确认自己是通过opencode命令启动的而不是通过某些第三方包装方式调起如果你确实需要把它作为底层服务集成到自己写的工具里那就得订阅它的付费计划也就是它针对高用量和开发者集成推出的 GO 套餐。这类套餐本质是给你独立可用的 API 额度跟界面内免费试用是两个通道。3.4 让 Claude Code 调用 LM Studio 的本地模型这个玩法我很喜欢因为本地模型的好处是免费、私密、不用等网络。想用宿主机上的 LM Studio 给容器里的 Claude Code 提供推理能力需要做两件事第一在宿主机上把 LM Studio 的本地服务器打开端口默认是 1234注意要开启 Anthropic API 兼容端点因为 Claude Code 默认走的是 Anthropic 的协议第二在容器里设置两个环境变量告诉 Claude Code 不要连官方 API而是连宿主机。export ANTHROPIC_BASE_URLhttp://host.docker.internal:1234/v1 export ANTHROPIC_AUTH_TOKENlm-studio claude这样启动之后Claude Code 的请求就会全部发到宿主机上的本地模型。实测下来性能好的本地模型写代码和做简单重构是够用的但跟官方模型比还有差距。比较明显的短板是工具调用能力很多本地模型在多步骤任务里会卡住表现为“思考了半天但不执行命令”。如果你也遇到类似情况建议在 LM Studio 里换一个明确支持 function calling 的模型比如 Qwen 系列的 Coder 版本或者干脆给 Claude Code 关闭一些依赖工具调用的自动化功能让它少做需要连续决策的长链路任务。4. 实操中的常见问题与排查实录4.1 Docker Desktop 启动失败的虚拟化问题前面提到过 virtualization support not detected 这个报错我再补充一个排查思路。Docker Desktop 启动时需要 Windows 的虚拟化能力报错信息虽然只有一句话但背后的原因可能有三种BIOS 未开启虚拟化、Windows 功能组件缺失、WSL2 内核版本太旧。我遇到过一个很隐蔽的情况BIOS 里虚拟化明明是开的Windows 功能也正常但 Docker 就是起不来最后发现是电脑上一次 Windows 大版本更新之后WSL2 的内核需要重新更新。执行wsl --update之后立刻就好了。所以这个问题的常规排查顺序是先检查硬件虚拟化再检查 Windows 功能最后更新 WSL2不要一上来就重装 Docker Desktop那样大概率疗效为零。4.2 Docker 里跑 MySQL 失败的常见原因既然你已经有了 Docker 环境大概率也会顺手在里面跑数据库。网上关于 docker 安装 mysql 失败的求助特别多我把最常见的失败原因列一下。用下面的命令是我最常用的 MySQL 8 启动方式docker run -d \ --name mysql8 \ -e MYSQL_ROOT_PASSWORDyour_password \ -p 3306:3306 \ -v mysql_data:/var/lib/mysql \ mysql:8.0如果启动后立即退出第一件事看日志docker logs mysql8。我遇过的失败情况绝大多数是这三类宿主机 3306 端口已经被本地 MySQL 或 MariaDB 占用了映射端口改成 3307 即可容器内存不足导致初始化失败Docker Desktop 的设置里调大内存配额数据目录权限不对挂载本地目录到/var/lib/mysql时Windows 文件系统的权限模型跟容器不一致改用 Docker volume 而不是 bind mount 就能避开。MySQL 初始化本身需要一点时间刚启动时端口是通的但连接会被拒绝等日志里出现 ready for connections 再连这个判断尤其新手容易慌。4.3 Codex 组织设置加载失败与配置文件残留问题Codex 用企业或组织账号登录时偶尔会遇到无法加载组织设置的提示。这种问题多半是服务端组织配置和本地 token 缓存不同步造成的。我的处理步骤是先退出登录重新执行codex login如果还不行就删掉~/.codex下的认证缓存文件再登录一次同时确认该组织账号确实开通了 Codex 的使用权限。还有一种情况是组织里开了单点登录这种在 CLI 环境里更容易出问题可以先用个人账号确认工具本身是否正常再切回组织账号两步一对比就能定位是不是账号侧的权限问题。另外网络上流传的一个典型报错片段是 cc switch local proxy failed while handling codex endpoint /responses。我在实际使用中也遇到过类似的变体核心原因基本都不是 Codex 本身坏了而是切换工具时旧工具留下的部分配置还残留在本地导致新工具启动时拿着旧配置去请求/responses接口自然就失败。处理办法很朴素把~/.codex下的配置备份后重置再重新登录同时确保在运行codex之前没有其他编程工具修改过它的配置文件。如果你使用 cc switch 这类多工具切换脚本来管理几个 CLI切换完之后最好开一个新的终端会话而不是在当前会话里直接运行这样可以避免会话级环境变量串台。4.4 OpenCode 免费额度限制与登录态丢失OpenCode 的 free tier 提示我们已经解释过了这里再说一个登录态相关的坑。如果你把它装好登录了一个供应商第二天打开发现又要重新登录大概率不是因为服务端把你登出了而是因为你用的终端环境或者容器重建导致~/.opencode目录没有持久化。我在这套 Docker 方案里单独挂载了这个目录就是防这个。另外如果你在 VSCode 的集成终端里用 OpenCode它的登录态默认跟随用户目录VSCode 远程连接和本地连接的环境变量不同也可能导致登录态看起来“丢失”。尽量固定使用同一种终端入口不要今天在 Windows 终端里用明天在 VSCode 远程窗口里用否则会觉得它的登录特别不稳定。4.5 容器内命令行工具的通用毛病与对策AI 编程助手这类 CLI 工具在容器里跑还有一个高频问题容易被忽略终端不是真正的 TTY。拿 OpenCode 来说非交互模式下很多输出格式、颜色渲染甚至是登录流程都会异常。我在 Docker Compose 里特意加了tty: true和stdin_open: true进容器之后再用opencode就能保证它拿到完整的终端能力。如果你平时喜欢用docker exec -it进容器记得必须带-it少一个-t都会出现莫名其妙的 UI 渲染问题。这不是工具的问题是容器环境没有把 TTY 传给进程。5. 把整套环境接入日常开发工作流5.1 用 VSCode 的 Dev Containers 插件直连容器装好容器之后如果你还在用 VSCode 写代码我建议不要只把它当一个 SSH 环境用而是安装 Dev Containers 插件直接“附加”到运行中的容器。这样打开 VSCode 窗口就是容器内的代码环境左侧文件树直接映射到/workspace底部集成终端里claude、codex、opencode三个命令都能直接用。这种体验比在宿主机上给每个工具单独配置 VSCode 拓展要干净得多因为你不用再去处理 Node 版本、全局包这些乱七八糟的差异。很多人问 VSCode 怎么和 OpenCode 协同工作其实不需要特殊插件OpenCode 本身是终端应用在 VSCode 集成终端里运行它它就能识别当前打开的文件夹作为工作目录。如果你的 VSCode 连的是容器那它看到的就是容器里的项目路径AI 助手读代码、改文件都是在这个环境里完成的非常顺。5.2 谨慎处理 AI 助手的自动执行权限三个工具都支持让 AI 直接执行终端命令。Claude Code 有跳过权限确认的模式Codex 也有全自动模式OpenCode 类似。我的态度很明确在你的个人项目里可以适当放开但在公司仓库或者生产相关的代码里千万不要无脑跳过确认。一个很小的疏忽一个 rm 命令就够你后悔半天。我的习惯是在本地个人项目里对 Claude Code 用白名单式的权限配置只允许它在当前项目目录内读写文件执行命令前仍然需要我确认。Codex 我一般不开全自动宁可慢一点也要确保每一步的执行内容是我能看懂的。AI 编程助手的自动化能力确实强但它对命令后果的理解还停留在统计层面代码被删了它不会心疼你得替它心疼。5.3 多项目复用的目录挂载技巧这套 Docker 环境最大的价值在于可复用。我平常会准备多个项目目录需要做哪个项目就把对应的宿主机目录挂载到容器里的/workspace。如果你不想修改 Compose 文件里的挂载路径可以在宿主机上做一个软链接把某个项目目录链接到固定的./workspace这样 Compose 文件永远不用动。再说一个权限细节在 Windows 上用 bind mount 挂载代码目录到容器可能会出现文件权限错乱的问题比如容器里创建的文件在 Windows 上只读、或者反过来。我的解决办法是尽量把项目代码的读写目录用 Docker volume 管理而不是 bind mount 宿主机目录。如果必须用 bind mount那就把容器用户固定下来别一会儿 root 一会儿普通用户乱切换权限错乱大部分都是用户 ID 不一致导致的。等你习惯了这套流程在任意一台装了 Docker 的机器上一条docker compose up -d就能获得完全一致的 AI 编程助手环境这种确定性带来的安心感远不是手动装三遍工具能比的。我个人在这套环境上踩过几次坑之后最大的体会是真正值得花时间维护的不是工具的安装过程而是登录态、配置和权限这些容易被忽视的状态层。把这些状态从容器里剥离出来你就不再害怕容器被删、电脑被重置。如果你现在也被多个 AI 编程助手的安装和切换问题困扰建议你今天就按这个方案把环境搭起来跑一遍三个工具的登录流程然后把代码目录挂进来看一次实际生成的效果这套一次性投入能省下来的时间远超你的预期。