许多开发者搜“Codex 接入 Claude”，真正想解决的不是安装哪个工具，而是一个更具体的问题：能不能继续用 Codex CLI 的工作流，但把底层模型换成 Claude？答案是可以，但关键不在 Codex 本身，而在你接入的服务是否提供 OpenAI-compatible 接口。

简单说：Codex 一般不能直接把 Anthropic 官方 API 地址填进去就用。更常见的做法，是通过一个支持 Claude 模型的 OpenAI-compatible 网关，让 Codex 按自己熟悉的接口发请求，再由网关转到 Claude。

下面把场景、坑点和配置方法说清楚。

先分清：你到底想用哪个工具

许多配置问题，最开始就混淆了两个概念：

一个是“操作界面”，也就是你平时敲命令、看输出、让它改代码的工具。

另一个是“底层模型”，也就是实际负责推理和生成答案的大模型。

如果你想要的是：

继续使用 Codex CLI，但让它调用 Claude 模型，这才是本文讨论的“Codex 接入 Claude”。

如果你想要的是：

在 Claude Code 里调用 Codex，或者在 Claude Code 中切换 DeepSeek、GLM 等模型，那是另一类方案，方向并不一样。

常见工具可以这样理解：

• Codex：AI 编程 CLI / Agent，负责本地项目工作流；
• Claude Code：Claude 官方编码助手，使用的是另一套交互方式；
• cc-switch / ccapi：更偏配置管理和 Key 切换；
• CCR：更偏 Claude Code 的路由；
• LiteLLM 或其他 OpenAI-compatible 网关：负责协议转换和模型路由。

这里最容易误会的是 cc-switch。

它可以帮你管理多个 API Key、多个 Provider，也可以让切换配置更方便，但它本身不是协议转换器。能不能让 Codex 用 Claude，关键还是看你的 Provider 是否支持 OpenAI-compatible API，并且是否提供 Claude 模型。

为什么不能直接填 Anthropic API 地址

许多人第一反应是，把 Codex 配置里的 base_url 改成：

https://api.anthropic.com

这样一般不行。

缘由是 Codex 常见的调用方式更接近 OpenAI-compatible API，列如 OpenAI Chat Completions，或者其他兼容 OpenAI 格式的接口。

而 Anthropic 官方 Claude API 使用的是 Anthropic Messages API。

这两套接口都能“调用大模型”，但细节并不一样：

• 请求路径不同；
• 鉴权头不同；
• 消息格式不同；
• 模型字段命名不同；
• tool calling 和 streaming 的实现方式也可能不同。

所以，合理的链路更像这样：

Codex CLI
   ↓ OpenAI-compatible request
OpenAI-compatible Gateway
   ↓ Anthropic Messages API
Claude Model

也就是说，中间需要一层网关。

这层网关可以是第三方兼容服务，也可以是企业内部网关、自建 LiteLLM，或者其他明确支持 Claude 模型的 OpenAI-compatible Provider。

如果某个平台只提供 Anthropic-compatible 接口，它可能更适合 Claude Code，不必定适合 Codex。许多“明明 Claude Code 能用，Codex 却报错”的问题，就是卡在这里。

适合哪些团队和场景

Codex 接入 Claude，不必定适合所有人。

如果你只是偶尔问几句代码问题，直接用现成的网页工具可能更省事。

但如果你已经习惯了 Codex 的终端流程，或者团队内部已经围绕 Codex 建了开发习惯，那么把 Claude 接到 Codex 后面，会比较自然。

比较适合的场景包括：

• 分析大型代码库结构；
• 给重构方案做判断；
• 做 PR Review 和代码审查；
• 定位复杂 Bug；
• 让 Claude 先做架构判断，再让 Codex 执行小步修改；
• 用多个模型交叉验证，减少单一模型误判；
• 结合 Codex 的本地项目上下文、sandbox、MCP 等能力完成工作流。

对于中小团队负责人来说，重点不是“能不能跑通一次”，而是这套链路是否稳定、可控、可审计，以及代码和业务数据会经过哪里。

配置前先准备什么

正式配置前，提议先确认这些东西：

• Codex CLI 已经安装，并且能正常启动；
• 你有一个支持 Claude 模型的 OpenAI-compatible Provider；
• 你拿到了这个 Provider 的 API Key；
• Provider 文档里写清楚了可用的 Claude 模型名；
• 你知道自己当前终端环境是 macOS、Linux、WSL 还是 PowerShell；
• 如果要管理多个配置，再思考 cc-switch 或 ccapi。

这里要特别注意“模型名”。

Codex 配置里的 model，不必定等于 Anthropic 官方模型名。不同 Provider 可能会做自己的映射，列如：

• OpenRouter 类服务可能使用 anthropic/claude-sonnet-4-5；
• 自建 LiteLLM 可能使用 claude-sonnet 或自定义别名；
• 企业网关可能使用 claude-code、sonnet、claude-prod；
• Anthropic 官方 API 一般不能直接当作 Codex 的 OpenAI Provider 使用。

最稳妥的办法，是看 Provider 后台、模型列表接口或官方文档。模型名写错，常见结果就是 404 Model Not Found。

基础配置：在 Codex 里加一个 Claude Provider

Codex 的配置文件一般在：

~/.codex/config.toml

不同系统稍微注意一下：

• macOS / Linux：一般在当前用户目录下的 ~/.codex/config.toml；
• Windows：可能在 Windows 用户目录里的 .codex 目录；
• WSL：配置文件在 WSL 的 Linux 用户目录，不是 Windows 用户目录；
• 文件不存在时，可以手动创建；
• 修改后提议重启终端或重新启动 Codex。

下面是一个通用示例：

model = "anthropic/claude-sonnet-4-5"
model_provider = "claude_via_openai_compatible"

[model_providers.claude_via_openai_compatible]
name = "Claude via OpenAI Compatible API"
base_url = "https://your-openai-compatible-provider.example.com/v1"
env_key = "OPENAI_API_KEY"
wire_api = "chat"

几个字段需要重点看：

• model：Provider 实际支持的 Claude 模型名；
• model_provider：当前 Codex 使用哪个 Provider；
• base_url：OpenAI-compatible 网关地址，一般需要带 /v1；
• env_key：Codex 从哪个环境变量读取 API Key；
• wire_api：请求协议类型，具体以当前 Codex 版本为准。

这里最容易错的是 base_url 和 model。

base_url 不是随意填一个模型官网地址，而是要填 Provider 提供的 OpenAI-compatible 网关地址。

model 也不要直接照搬网上示例，要看你自己的 Provider 怎么命名。

API Key 提议放在环境变量里

不提议把真实 API Key 写进公开文章、截图、GitHub 仓库或项目配置文件。

更稳妥的做法，是用环境变量。

macOS / Linux / WSL 可以临时设置：

export OPENAI_API_KEY="your_provider_api_key"

如果想长期生效，可以写进 shell 配置文件。

zsh 用户：

echo 'export OPENAI_API_KEY="your_provider_api_key"' >> ~/.zshrc
source ~/.zshrc

bash 用户把 .zshrc 换成 .bashrc 即可。

PowerShell 临时设置：

$env:OPENAI_API_KEY="your_provider_api_key"

PowerShell 持久化设置：

[Environment]::SetEnvironmentVariable("OPENAI_API_KEY", "your_provider_api_key", "User")

如果你在 Windows 和 WSL 两边都用 Codex，要分别设置。Windows 的环境变量不会自动等于 WSL 里的环境变量。

怎么确认真的调用到了 Claude

配置完成后，可以先用简单命令测试：

codex "请用一句话说明你适合处理什么类型的代码任务"

更推荐用真实项目上下文测试，列如：

codex "阅读当前项目结构，给出重构提议，但不要修改文件"

但不要只靠模型回答“我是谁”来判断。

更可靠的验证方式，是看 Provider 控制台或网关日志：

• 请求是否打到了你配置的 base_url；
• 实际调用的模型名是不是 Claude；
• 是否发生了模型降级或转发；
• streaming、tool calling 是否正常；
• 请求失败时返回的状态码是什么。

如果 Provider 有多模型路由，尤其要确认没有被自动转到其他模型。

常见坑一：Claude Code 能用，Codex 不能用

这是很典型的情况。

缘由一般是 Claude Code 使用的是 Anthropic 协议，而 Codex 需要的是 OpenAI-compatible 协议。

处理提议：

不要直接把 Claude Code 可用的 Anthropic 地址搬到 Codex 里。先确认服务商是否提供 OpenAI-compatible 接口。如果没有，就需要换支持该接口的网关，或者使用自建 LiteLLM、企业内部网关等方案。

常见坑二：cc-switch 切换了，但 Codex 没变化

cc-switch 或类似工具能帮你切配置，但不保证当前终端必定继承了新的环境变量。

常见缘由包括：

• IDE 内置终端没有重启；
• 当前 Shell 没有加载新的配置；
• Windows 和 WSL 环境变量不一致；
• Codex 读取的配置文件不是你修改的那个；
• Provider 本身不支持 Claude 的 OpenAI-compatible 调用。

处理提议：

先确认当前终端里环境变量是否生效，再确认 ~/.codex/config.toml 路径是否正确，最后看 Provider 请求日志。

不要把 cc-switch 当成协议转换器。它只能切换配置，不能把 Anthropic API 自动变成 OpenAI-compatible API。

常见坑三：报 401、403、404、400

这些报错看起来差不多，但定位方向不一样。

401 Unauthorized 一般是 API Key 错误，或者环境变量没有生效。

处理提议：重新设置 Key，并在当前 Shell 中确认变量是否存在。

403 Forbidden 一般是 Key 没有对应模型权限，或者账户余额、权限状态不满足要求。

处理提议：去 Provider 后台检查账户状态和模型权限。

404 Model Not Found 一般是模型名写错。

处理提议：不要猜模型名，去看 Provider 的模型列表或文档。

400 Bad Request 一般是协议不兼容，或者请求字段不被支持。

处理提议：确认这个 Provider 是否真正支持 OpenAI-compatible API，而不是只支持 Anthropic-compatible API。

排查时抓住三件事：base_url 对不对，model 存不存在，API Key 有没有在当前终端里生效。多数问题都能从这里定位。

常见坑四：请求卡住或工具调用失败

如果请求卡住，可能是流式输出不兼容，也可能是网络或网关问题。

如果 tool calling 失败，一般是 Provider 对工具调用支持不完整。

处理提议：

• 查看网关日志；
• 暂时关闭复杂工具调用，只测试普通对话；
• 换一个简单 prompt 验证基础请求；
• 确认 Provider 是否声明支持 streaming 和 tool calling；
• 必要时换支持更完整的 OpenAI-compatible Provider。

Codex 这类 Agent 工具不只是“发一句话给模型”，还会涉及文件上下文、工具调用、流式输出等能力。网关只支持普通聊天，不代表就能完整支持 Codex 的工作流。

安全和成本要提前想清楚

对个人开发者来说，API Key 泄露是最常见风险。

对团队来说，更大的问题是代码、prompt、项目上下文会经过哪里。

提议至少注意这些点：

• 不要把 API Key 写进公开仓库；
• 如果 .codex/config.toml 包含敏感信息，不要提交到 Git；
• 尽量用环境变量保存 Key；
• 第三方网关可能会接触到 prompt、代码片段和项目上下文；
• 公司代码、客户代码、商业秘密，不提议随意发送到未知中转服务；
• 免费或低价服务可能存在速率限制、排队、日志留存、模型降级等情况；
• 企业场景更适合使用官方 API、企业代理、自建 LiteLLM 或可信的内部网关。

这些不是“额外担心”，而是实际落地时最容易被忽略的部分。

许多团队一开始只关心能不能调用成功，后面才发现权限、日志、数据边界、开票、稳定性才是长期使用的关键。

到底该选哪种方案

如果你想在 Codex 中使用 Claude，优先思考：

OpenAI-compatible 网关 + Codex 配置。

如果你想官方稳定地使用 Claude，并且不介意换工作流：

直接使用 Claude Code 和 Anthropic 官方能力会更清晰。

如果你只是想管理多个 Key 和多个模型配置：

cc-switch / ccapi 可以思考，但不要把它当协议转换器。

如果你想在 Claude Code 里临时调用 Codex 做 Review：

那是 codex-plugin-cc 方向，不是本文讨论的 Codex 接入 Claude。

如果你是企业内部使用：

更提议思考自建 LiteLLM、企业网关或可信内部代理，把数据流、权限和日志管住。

最后总结

Codex 接入 Claude 的核心，不是多装几个工具，而是让 Codex 访问一个真正兼容 OpenAI API、同时支持 Claude 模型的 Provider。

配置时重点看四项：

• base_url 是否是 OpenAI-compatible 网关地址；
• model_provider 是否指向正确 Provider；
• model 是否是 Provider 支持的 Claude 模型名；
• API Key 是否在当前终端里生效。

验证时不要只问模型“你是谁”，更应该看 Provider 请求日志。