接入模型与网络配置
Codex 默认使用 OpenAI 官方 API。如直接访问受限，可通过中转服务或自定义网关实现稳定接入。
两种认证方式任选其一：
codex 后浏览器自动弹出登录页面。Codex 配置文件（用户级配置，项目级的 .codex/config.toml 不能覆盖 API 端点等关键字段）：
Windows：C:\Users\你的用户名\.codex\config.toml | macOS / Linux：~/.codex/config.toml
主要配置项：
# Codex CLI 配置文件
# 模型选择（可选：gpt-4o、o3-mini 等）
model = "gpt-4o"
# 自定义 API 端点（使用中转服务时修改此项）
openai_base_url = "https://api.openai.com/v1"
# 沙箱模式：read-only | workspace-write | danger-full-access
sandbox_mode = "workspace-write"
# 审批策略：on-request | on-failure
approval_policy = "on-request"
# 如遇反复重连（Reconnecting），设为 false
supports_websockets = trueopenai_base_url 是重定向 API 端点的关键字段，配合国内中转服务使用；sandbox_mode 控制文件系统访问权限——workspace-write 可修改工作区文件（推荐），danger-full-access 有全盘清空风险（⚠️ 慎用）；approval_policy 决定操作前是否需要人工确认；supports_websockets 设为 false 可解决反复重连（Reconnecting）问题。也可通过环境变量配置（环境变量优先级高于配置文件）：
read -rs OPENAI_API_KEY && export OPENAI_API_KEYexport OPENAI_BASE_URL="https://你的中转地址/v1"model使用的模型，默认 gpt-4oopenai_base_urlAPI 端点地址，使用中转服务时修改此项sandbox_mode沙箱模式：read-only / workspace-write / danger-full-accessapproval_policy操作审批策略：on-request（推荐）/ on-failuresupports_websockets设为 false 可解决反复重连（Reconnecting）问题export OPENAI_API_KEY=sk-xxx（会记录到 shell 历史）如遇到反复重连（Reconnecting），可在 config.toml 中设置 supports_websockets = false。如网络不稳导致频繁断开，参见下方 §4 接入国内 API 方案。
Codex CLI（v0.131.0 及以上）使用 OpenAI 专属的 Responses API（/v1/responses） 与模型服务通信。而国内主流模型厂商——DeepSeek、智谱 GLM、Kimi、MiniMax 等——对外统一提供的是Chat Completions API（/v1/chat/completions）。 两种协议请求体结构、流式 SSE 事件格式均不相同，直接改 openai_base_url 会导致 404 或 400。
以下列出当前可用的几种配置方式。每种方式的适用场景和前提条件不同——没有通用的最佳方案， 选择取决于你已有的工具链和使用的 API 供应商。
⚠️ 以上信息可能已过时，请以各平台官方网站的最新公告和定价页面为准。以下方案涉及的版本号、功能说明和已知问题验证于 2026-06。工具迭代频繁，建议以各项目的官方文档为准。
CC Switch 通过本地路由——在本机启动 HTTP 代理——将 Codex 的 Responses API 请求 实时转换为供应商的 Chat Completions 格式。操作在 GUI 中完成，不需要手动编辑 Codex 配置文件。 支持 DeepSeek、Kimi、MiniMax、硅基流动等 50+ 内置预设。
按以下步骤配置：
Codex++ 是基于 Rust + Tauri 开发的 Codex App（桌面版，即 Codex App）增强启动器，通过 Chromium DevTools Protocol 注入增强脚本，不修改 Codex 原始安装文件。其中转注入功能可在图形界面中切换 API 供应商——不需要编辑 config.toml。
按以下步骤配置：
除中转注入外，Codex++ 还提供 Codex App 的 UI 增强：
以上功能的详细操作见使用教程。
CCX（GitHub ） 是独立维护的 AI API 代理与协议转换网关，作为本地服务运行（支持 Node.js 或 Docker 部署）。 适合需要同时管理 Claude Code、Codex、Gemini CLI 等多个工具的用户。
按以下步骤配置：
CCX 的配置步骤比 CC Switch 多——需要部署本地服务、管理配置文件。 但它作为独立网关，各工具的配置互不干扰，排查问题时更容易隔离故障点。 如果你已经使用 Docker 且需要多工具统一管理，CCX 提供了更高的透明度。
「中转站」（也称 API 代理/中转服务）是第三方提供的 API 转发服务。 用户的请求先发到中转站，中转站再转发给模型供应商（如 OpenAI、DeepSeek）， 最后把响应返回给用户。对国内用户而言，中转站解决了两个问题： ① 网络——中转站服务器在可直连的网络环境中，用户不需要科学上网； ② 支付——支持支付宝/微信，不需要海外信用卡。
注意：中转站能看到你的请求内容（包括代码）。 选择时优先考虑有隐私承诺、数据加密的服务。使用中转站即表示你信任该服务商。 本站列出的方案均以技术配置为主，不推荐也不评估任何特定中转服务—— 建议在使用前搜索该服务的用户反馈和隐私政策。
前提：部分国内中转服务已在服务端完成 Responses ↔ Chat Completions 协议转换， 直接提供兼容 Codex 的端点。此时无需任何额外工具——只改 openai_base_url 即可。
export OPENAI_BASE_URL="https://你的中转地址/v1"export OPENAI_API_KEY="你的中转Key"openai_base_url 会返回 404 或 400。 配置前向中转服务确认是否支持 Codex（Responses API）。不支持则需用方案 A、B 或 C。Codex CLI 支持 [model_providers] 块自定义供应商，不依赖第三方工具—— 但需要理解字段含义。
wire_api 只能为 "responses"。如看到的教程包含 wire_api = "chat"，已过时。以下为基本结构（具体字段因供应商而异）：
model_provider = "my_provider"[model_providers.my_provider]name = "自定义供应商名称"base_url = "https://你的API端点/v1"env_key = "MY_API_KEY"wire_api = "responses"model_provider指定当前使用的供应商名称（对应 [model_providers.xxx] 中的名称）base_urlAPI 端点地址env_keyAPI Key 从哪个环境变量读取（避免 Key 写死在配置文件）wire_api通信协议，当前只支持 "responses"完整字段说明见 OpenAI 官方 Codex 配置文档 。
| 维度 | CC Switch | Codex++ | CCX | 中转站直连 | 手动配置 |
|---|---|---|---|---|---|
| 配置方式 | GUI 操作 | GUI 操作 | 部署本地服务 + Web UI | 改一行地址 | 手写 TOML |
| 需要额外工具 | CC Switch | Codex++ | Docker 或 Node.js | 无 | 无 |
| 协议转换位置 | CC Switch 本地代理 | Codex++ 本地注入 | CCX 本地网关 | 中转站服务端 | 不转换（需供应商兼容） |
| 覆盖范围 | Claude Code / Codex 等 | 仅 Codex App | Claude Code / Codex 等 | 仅 Codex | 仅 Codex |
| 附加功能 | 权限跳过 | 插件解锁 / 会话管理 | 统一网关管理 | 无 | 可自定义全部参数 |
| 适用场景 | 新手 / 不想碰配置文件 | Codex App + 插件需求 | 多工具统一管理 | 有可信中转服务 | 精确控制 / 最小依赖 |
codex --version，确保 v0.131.0+curl 直接测试供应商端点，排除 Key 本身无效~/.codex/logs/以上步骤未解决问题时，建议到以下渠道以"报错信息 + 工具名"搜索最新讨论：
⚠️ 以上信息可能已过时，请以各平台官方网站的最新公告和定价页面为准。以上方案涉及的版本状态、协议兼容性说明验证于 2026-06。功能更新以各项目官网和 GitHub 为准。
如果对本站内容有疑问，推荐到视频或其他知识性平台寻求解决方法，也可直接向 AI 提问获得参考性回答（注意分辨 AI 回答的正确性）