告别 Copilot?Codex 本地化部署指南:从环境搭建到私有化实践
1. 为什么要把 Codex 搬到本地从 Copilot 到私有化工作流如果你每天在 VS Code 里写代码大概率已经习惯了 Copilot 那种「敲一半自动补全」的节奏。但用久了总会碰到几个绕不开的问题公司内网项目不敢把代码片段发到云端、团队想统一模型和提示词却没法集中管理、按人头订阅的成本随着人数线性上涨。Codex 本地化部署要解决的正是这些事——把代码补全和对话能力收进你自己的环境里数据不出内网模型和 Key 都由你说了算。这里说的 Codex指的是以 OpenAI Codex CLI 为代表的命令行编码代理形态它能读文件、改代码、跑命令配合 VS Code 插件或终端就能当日常编码助手用。本地化部署的核心不是把模型权重下载到本机跑那对显存要求太高而是把 Codex 客户端的请求出口从默认云端改到你自己的服务地址再通过一个稳定的 API 网关转发到目标模型。这样既保留了 Codex 的交互体验又拿到了私有化配置的灵活性。适合谁看一是有内网合规要求、不能直连外部服务的开发团队二是想统一管理多个模型、按项目切换的独立开发者三是已经在用 Copilot 但想试试 Codex CLI 自定义 Base URL 这套组合的人。下面我会从 Docker 环境搭建讲起一路走到 VS Code 集成和连通性验证每一步都给可复制的配置。2. TaoToken 前置准备拿到 Base URL 和 API KeyCodex 本地化部署里最容易卡住的一步其实是「请求往哪发」。Codex CLI 默认走 OpenAI 官方端点但你要做私有化就得把它指向一个你能控制的入口。TaoToken 在这里扮演的是 API 网关角色它提供兼容 OpenAI 协议的接口你拿到 Base URL 和 Key 之后Codex 的 auth.json 和 config 里填上这两个值就能跑通。先做三件事。第一打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 注册账号这一步不赘述。第二进控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 创建 API Key建议按项目命名比如codex-local-dev方便后面轮换。第三记下两个关键值Base URL 用https://taotoken.net/apiModel ID 根据你要用的模型填比如claude-sonnet-4-20250514或gpt-4o这类。这三个东西——Base URL、API Key、Model ID——就是后面所有配置的「三件套」缺一个都跑不起来。注意API Key 只在创建时完整显示一次复制后存到密码管理器或环境变量里别直接写进会提交到 Git 的文件。如果你还没想好用什么模型可以先到模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 试几条代码生成请求确认响应速度和输出质量符合预期再决定写进 Codex 配置里的 Model ID。这一步花五分钟能省掉后面反复改配置的麻烦。3. Docker 环境搭建与 Codex auth.json 配置实战这一节是全文的核心目标是把 Codex CLI 跑在 Docker 里并且把它的请求出口改到 TaoToken。先确认本机环境Docker 24 以上、Python 3.10Codex CLI 依赖、以及一个能访问外网的网络环境用于拉镜像。下面这份docker-compose.yml可以直接复制路径和字段都按 Codex CLI 的实际读取位置来写。version: 3.9 services: codex: image: node:20-bookworm container_name: codex-local working_dir: /workspace volumes: - ./workspace:/workspace - ./codex-home:/root/.codex environment: - OPENAI_BASE_URLhttps://taotoken.net/api - OPENAI_API_KEY${TAOTOKEN_API_KEY} command: bash -c npm install -g openai/codex tail -f /dev/null tty: true stdin_open: true这里有几个点要解释。./codex-home挂到容器里的/root/.codex是因为 Codex CLI 会把认证信息写到~/.codex/auth.json挂出来才能持久化容器重建也不用重新登录。OPENAI_BASE_URL和OPENAI_API_KEY通过环境变量注入避免硬编码。启动前先在宿主机导出 Keyexport TAOTOKEN_API_KEYsk-你的Key docker compose up -d docker exec -it codex-local bash进容器后手动写一份auth.json路径是/root/.codex/auth.json{ OPENAI_API_KEY: sk-你的Key, OPENAI_BASE_URL: https://taotoken.net/api, tokens: { access_token: sk-你的Key, refresh_token: } }这份 JSON 里OPENAI_BASE_URL必须和上面环境变量一致tokens.access_token填同一个 Key。有些版本的 Codex CLI 会优先读 auth.json 而不是环境变量两个都配上最稳。写完用cat /root/.codex/auth.json确认没有多余逗号JSON 格式错误是后面 401 报错的常见原因。如果你用的是 Codex 的 TOML 配置形态部分版本支持~/.codex/config.toml可以再加一份[model] provider openai name claude-sonnet-4-20250514 [provider.openai] base_url https://taotoken.net/api api_key sk-你的KeyModel ID 按你实际要用的填别照抄。配置改完Codex 的请求就会先到 TaoToken再由它转发到目标模型你的代码内容不经过默认云端端点。4. 连通性验证从 curl 到 Codex 实际请求配置写完别急着开 VS Code先在容器里做两层验证。第一层用 curl 直接打 TaoToken 的接口确认 Key 和 Base URL 本身是通的curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 用 Python 写一个快速排序}], max_tokens: 200 }正常返回是一段 JSONchoices[0].message.content里能看到代码。如果这里就报 401说明 Key 或 Base URL 有问题先解决再往下走。第二层验证 Codex CLI 本身codex 解释一下当前目录下的 package.jsonCodex 会读取文件、发起请求、返回解释。如果这一步成功说明 auth.json 和 Base URL 都生效了。实测下来最容易出问题的是 Base URL 末尾多写或少写/v1——TaoToken 的 Base URL 是https://taotoken.net/apiCodex 内部会自己拼/v1/chat/completions你手动加/v1反而会变成/api/v1/v1/...导致 404。验证通过后把容器里的 workspace 目录换成你的真实项目路径重新docker compose up -d即可。VS Code 集成有两种方式一是用 Remote-Containers 插件直接连进这个容器在容器里开终端跑 Codex二是宿主机装 Codex CLI把~/.codex/auth.json配成同样的内容VS Code 的终端里直接调用。前者隔离性更好后者启动更快按团队习惯选。5. 常见报错排查401、local proxy failed 与 reading choices部署过程中有几类报错几乎人人都会碰到这里按真实错误信息对照排查。401 Unauthorized最常见。先确认auth.json里的 Key 和OPENAI_API_KEY环境变量一致再确认 Key 没有过期或被删除。如果 curl 能通但 Codex 报 401多半是 Codex 读的是 auth.json 而不是环境变量检查文件路径是不是/root/.codex/auth.json权限是不是 600。local proxy failed / connection refusedCodex 尝试连本地代理但没起来。检查OPENAI_BASE_URL是不是被其他配置覆盖了比如 shell 里残留的HTTPS_PROXY环境变量。用env | grep -i proxy看一眼有就 unset 掉。reading choices: unexpected end of JSON input接口返回了非 JSON 内容通常是 Base URL 拼错导致打到了 HTML 页面。用 curl 复现一次看返回体开头是不是!DOCTYPE html是的话就是地址错了。OAuth 相关报错Codex 某些版本会尝试走 OAuth 登录流程如果你用的是 API Key 模式在配置里显式指定provider openai并填好api_key避免它去走浏览器授权。Model not foundModel ID 写错了。到模型对话页确认可用的模型名注意大小写和日期后缀。排查顺序建议先 curl 验证 Key 和地址再验证 Codex CLI最后验证 VS Code 集成。每层单独确认别一次改多个地方否则出错不知道是哪层的问题。6. 长期编码与 Agent 场景把 Codex 用成日常主力连通之后Codex 能做的事比补全多得多。日常编码场景里你可以让它读整个目录、批量改文件、跑测试并修复失败用例。比如在项目根目录执行codex 找出所有未处理的 Promise rejection加上 catch 并写单测它会自己规划步骤、改代码、运行测试。这类 Agent 式用法对 API 的调用频率比较高如果你打算长期这么用建议到 Coding Plan 页面 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 看一下配额方案避免按量计费超出预期。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有各语言 SDK 的示例需要写脚本批量调用时可以直接参考。VS Code 里的用法装好 Remote-Containers 后连进 codex-local 容器打开项目目录终端里跑codex就是完整能力。想要更顺手的补全体验可以配合 Continue 这类插件把它的 API Base 也指向https://taotoken.net/apiModel ID 填同一个这样补全和对话走同一套配置管理起来简单。最后给一个实用技巧把auth.json和config.toml做成模板用环境变量替换 Key团队里每人 clone 后只需导出自己的 Key 就能跑。这样既统一了配置又不会把 Key 提交到仓库。踩过的坑基本都在第 5 节列了按那个顺序排查九成问题能自己解决。