先说结论：GLM-5.3 完全可以直接接入 Codex 使用，而且配置起来没有想象中那么复杂。前阵子我一直在折腾 Codex CLI 和 Codex++ 这套组合，试过 DeepSeek，也试过智谱的 GLM 系列，最后把 GLM-5.3 和 GLM-5.3-Flash 都稳定跑起来了。整个过程踩了不少坑，尤其是 config.toml 反复被回写覆盖、Codex++ 切换配置时报 local proxy failed 这类问题，网上资料零散，官方文档也没写明白。这篇就把我的完整配置流程、参数含义、排错记录一次性整理出来，给同样在折腾的朋友一个能直接照着抄的参考。
这套配置方案适合谁？如果你在用 Codex CLI 做 AI 编程，但不想局限于官方模型，想换成国产模型降低成本或提升响应速度；或者你已经装了 Codex++，但对多模型配置、config.toml 的格式一知半解，甚至被“cc switch local proxy failed”这类报错卡住过，那这篇文章就是给你准备的。我会从环境准备讲起，逐步到 config.toml 参数解读、Codex++ 图形化接入，再到常见问题的完整排查思路，尽量让零基础的朋友也能一次跑通。
1. 接入思路与方案选型
1.1 为什么把 GLM-5.3 接入 Codex
Codex 本身是 OpenAI 出的编程智能体工具，核心价值在于它不是一个简单的聊天框，而是能读取你的代码仓库、执行命令、自动修改文件，像是把“AI 结对编程”真正落地到终端里。但问题是，要用 Codex 就得先解决模型来源，官方模型不仅贵，而且访问链路在很多场景下并不顺畅。
这时候国产模型就有优势了。GLM-5.3 是智谱清言旗下的新一代大模型，综合能力在代码生成、逻辑推理、中文理解这几个维度上表现都非常能打，尤其是长上下文窗口和函数调用能力，跟 Codex 这种 agent 型工具天然匹配。GLM-5.3-Flash 则是轻量版，速度快、成本极低，适合日常简单任务、代码补全这类高频低难度的场景。
把 GLM-5.3 接入 Codex，本质上就是给 Codex 换一个“大脑”。Codex 本身的工程能力——文件操作、命令行执行、上下文管理——完全保留，只是把背后的模型从 OpenAI 系切换到智谱系。这样你既能用上 Codex 好用的 agent 工作流，又能享受国产模型的价格优势和国内直连的便利性。
1.2 两条技术路线的对比
我在实操过程中发现，接入路线主要分两种：直接改 config.toml 文件，或者用 Codex++ 这类图形化工具来托管配置。
直接改 config.toml 是最底层、最透明的方案。Codex CLI 启动时会读取~/.codex/config.toml这个文件，里面定义了模型、接口地址、认证方式等关键参数。你只需要按照 TOML 语法手动编辑，保存后重启 Codex 就能生效。优点是灵活，想怎么改就怎么改，适合喜欢掌控每个细节的用户；缺点是对新手不友好，一个标点符号错了整个配置就废了，而且 Codex 在某些操作下会回写覆盖这个文件，容易把自定义配置冲掉。
Codex++ 则是一个社区开发者做的增强工具，本质上是对 Codex CLI 的封装和扩展，提供了一个图形界面来管理多个模型提供方（provider），比如 OpenAI、DeepSeek、GLM、Kimi 这些。它会在后台生成和维护配置文件，你只需要在界面上选一选、填一填 API Key 就行。优点是省心，切换模型不用再手动改文件；缺点是引入了额外一层，一旦 Codex++ 自身出问题，排查起来会多一道工序。
我的建议是：先用 Codex++ 把整个链路跑通，再回头理解 config.toml 里每行参数的含义。这样做的好处是，即使 Codex++ 出问题，你也能手动改配置来兜底，而不是被工具卡死。
1.3 我最终选定的方案组合
折腾了一圈之后，我的最终方案是：Codex CLI + Codex++ + config.toml 手动配置，三管齐下。
具体分工是这样的：Codex CLI 是主体，负责跑实际的编程任务；config.toml 是我手动维护的核心配置，保证 GLM-5.3 的接入参数准确无误；Codex++ 作为辅助管理工具，用于快速切换 GLM-5.3 和 GLM-5.3-Flash 这两个模型，以及查看配置状态。
我不建议完全依赖 Codex++ 自动生成的配置，因为它对智谱这种第三方模型的支持有时候不够及时，自动生成的 base_url 或者模型名可能过时。但把它当成一个“配置预览器”和“快速切换器”非常好用。两者的配合关系，就像用 IDE 写代码和用命令行编译的关系——IDE 方便日常操作，但关键配置还得自己知道怎么改。
2. 环境准备：工具链安装与验证
2.1 基础依赖安装（Node.js 和 Git）
Codex CLI 本身是 Node.js 写的，所以 Node.js 是必须的。我建议装 LTS 版本，不要追最新版，稳定性优先。安装完成后在终端里验证：
node -v npm -v能看到版本号输出就说明 Node.js 环境没问题。如果提示找不到命令，大概率是 PATH 环境变量没配好，把 Node.js 的安装目录加进 PATH 就行。
Git 也是强烈建议装的，因为 Codex 在读取仓库上下文、执行 git 操作时会用到它。Windows 用户直接装 Git for Windows，macOS 用户可以用 Homebrew 装：
brew install git装完后同样验证一下git --version。
2.2 安装 Codex CLI 与 Codex++
Codex CLI 的安装方式有两种：npm 全局安装，或者用官方脚本安装。我习惯用 npm：
npm install -g @openai/codex装完后运行codex --version，能输出版本号就行。Codex++ 的安装稍微特殊一点，它除了 npm 包之外还需要一个桌面客户端。npm 包负责 CLI 增强，桌面客户端负责可视化配置管理。
Codex++ 装好后，第一次启动会让你选择配置目录，默认会读取~/.codex/下的配置文件。如果你之前已经用过 Codex CLI，它应该能自动识别已有的 config.toml。
2.3 验证 Codex 基础功能
在接入 GLM 之前，建议先跑一遍 Codex 的默认配置，确认工具本身没毛病。执行codex进入交互模式，随便问一个问题，如果它能正常回复，说明基础链路是通的。如果这一步就报错，先别急着接 GLM，优先排查 Codex 本身的安装问题。
有个小细节：Codex 首次启动会要求登录 OpenAI 账号，如果你没有官方账号，可以直接跳过登录步骤——因为我们后面接入 GLM 根本不需要 OpenAI 的认证，用的是自己的 API Key。这一步卡住的人很多，但其实不影响后续操作。
3. config.toml 核心配置详解
3.1 配置文件位置与加载逻辑
config.toml 是 Codex 的核心配置文件，默认位置在用户目录下的.codex文件夹里。Linux/macOS 是~/.codex/config.toml，Windows 是C:\Users\你的用户名\.codex\config.toml。
Codex 启动时加载配置的优先级是：命令行参数 > 环境变量 > config.toml > 默认配置。这意味着你可以在不修改文件的情况下，通过环境变量临时覆盖某些配置项。这个特性在排查问题的时候特别有用。
还有个关键点：Codex 的配置文件可能不是只有 config.toml 一个，同目录下通常还会有auth.json存放认证信息。这两个文件的分工要搞清楚——config.toml 管模型和接口，auth.json 管密钥和登录凭证。很多人把这两个搞混，导致配置了 API Key 但 Codex 还是报认证失败。
3.2 完整配置结构逐行拆解
下面是我在用的完整 config.toml，接入的是 GLM-5.3：
model = "glm-5.3" model_provider = "zhipu" [model_providers.zhipu] name = "Zhipu GLM" base_url = "https://open.bigmodel.cn/api/paas/v4" env_key = "ZHIPU_API_KEY" wire_api = "responses"这几行配置的含义我来逐行解释：
model = "glm-5.3"：核心模型名称，也就是 Codex 实际调用时传给 GLM 接口的模型标识。智谱这边接受的名字就是glm-5.3，注意别拼错。model_provider = "zhipu"：指定使用下面哪个 provider 配置块。这个名字是你自己定义的，可以取任意名字，但必须和后面的[model_providers.zhipu]块名一致。[model_providers.zhipu]：provider 定义块的开始标记。TOML 语法里方括号表示一个表格（table），这个表格里可以放很多个 provider，每个用不同的名字区分。name = "Zhipu GLM"：provider 的显示名字，主要是给人看的，Codex 日志里会用到，不影响实际功能。base_url = "https://open.bigmodel.cn/api/paas/v4"：API 接口地址。这个是最关键的参数，Codex 会往这个地址发请求。智谱的兼容接口就是这个，注意路径末尾的/v4不能少。env_key = "ZHIPU_API_KEY"：指定从哪个环境变量读取 API Key。Codex 不会直接在 config.toml 里存密钥（虽然可以，但不推荐），而是通过环境变量的方式引用。wire_api = "responses"：底层 API 协议类型。Codex 原生支持两种协议，responses和chat。这里必须设置成responses，因为 Codex 的 agent 工作流依赖 responses 协议的函数调用能力。如果设置成chat，虽然也能跑，但很多高级功能会失效。
如果要用 GLM-5.3-Flash，只需要把第一行的model改成glm-5.3-flash即可，其他配置完全不用动。我甚至专门建了两个 provider 块，一个叫 zhipu，一个叫 zhipu-flash，这样切换的时候只需要改model_provider这一行就行。
3.3 认证配置：auth.json 与环境变量
接下来说说认证。Codex 读取 API Key 的优先级是：环境变量 > auth.json > 配置文件内嵌。既然我们在 config.toml 里已经指定了env_key = "ZHIPU_API_KEY"，那最稳妥的方式就是设置环境变量。
在 macOS/Linux 下，编辑~/.bashrc或~/.zshrc，加入：
export ZHIPU_API_KEY="你的智谱API密钥"Windows 用户在系统环境变量里新建一个ZHIPU_API_KEY变量，值填你的密钥。
这里有个坑要提醒你：改了环境变量之后，一定要重新打开终端窗口，或者执行source ~/.zshrc，否则新开的终端里变量不生效。我一开始就是没刷新环境变量，Codex 一直报认证失败，排查了半天才发现是这个问题。
auth.json 的格式大致是：
{ "OPENAI_API_KEY": "sk-xxx", "ZHIPU_API_KEY": "你的密钥" }如果你用 Codex++ 添加过 provider，它通常会帮你写入 auth.json。但说实话，我更推荐环境变量方案，因为 auth.json 在某些操作下会被 Codex 回写，导致你手动填的密钥被清理掉。
注意：不要直接在 config.toml 里明文写 API Key。虽然语法上允许，但这个文件有时候会被 Codex 自动重写，密钥容易丢，而且明文存储本身也不安全。
4. Codex++ 接入 GLM 实操记录
4.1 通过 Codex++ 添加 GLM provider
打开 Codex++ 的图形界面，找到 Providers（模型提供方）设置页。这里通常会有一个“添加自定义 Provider”的入口，点击后需要填这几项：
- Provider 名称：填
zhipu，和 config.toml 里的保持一致。 - Base URL：填
https://open.bigmodel.cn/api/paas/v4。 - API Key：填你的智谱密钥。
- 模型列表：填
glm-5.3,glm-5.3-flash，两个模型用英文逗号分隔。
填完之后保存，Codex++ 会自动把这些信息写入 config.toml 和 auth.json。这时候你可以切到配置预览页，看看它生成的 config.toml 长什么样，一般和我上面手动写的差不多。
4.2 在 Codex++ 中切换模型
Codex++ 最方便的地方就是模型切换。界面上通常会有一个下拉选择框，列出所有 provider 下的模型，点一下就能切换。
切换 GLM-5.3 和 GLM-5.3-Flash 的体验，简单说就是：复杂任务用 GLM-5.3，量大管饱的任务用 Flash。比如让 Codex 重构一个模块、设计数据表结构，我用 GLM-5.3；让 Codex 写单元测试、补注释、批量改格式这种重复性工作，直接用 Flash，速度快到几乎无感。
这里有个小技巧：在 Codex++ 里可以给每个模型设置不同的 system prompt 模板。我实测下来，GLM-5.3 对中文指令的理解能力很强，所以我的 system prompt 是“你是资深全栈工程师，代码风格简洁规范”，效果比默认英文 prompt 好不少。
4.3 Codex++ 与 config.toml 的同步机制
理解 Codex++ 和 config.toml 的同步关系，是避免配置冲突的关键。
Codex++ 本质上是一个配置生成器和管理器。你在图形界面上的任何操作，最终都会落盘到 config.toml。也就是说，Codex++ 不是一座孤岛，它和手动编辑 config.toml 是双向互通的。
但正因为如此，如果你既用 Codex++ 又手动改配置，就可能出现互相覆盖的情况。比如你在 Codex++ 里添加了一个 provider，保存后它会把你手动加的一些自定义配置项覆盖掉。我的做法是：习惯用界面操作的人，就尽量全程用 Codex++ 来管理，不要频繁手动改文件；反过来，如果你是手动党，就少用 Codex++ 的“保存/应用”功能，只把它当只读查看器用。
5. 常见问题与排查技巧实录
5.1can't load config.toml或模型列表为空
这个报错基本可以锁定为配置文件格式错误。TOML 格式非常严格，错一个标点、多一个空格、少一个引号都会导致解析失败。
排查步骤：
- 用编辑器打开 config.toml，检查方括号
[ ]是否成对出现，表头是否在正确的位置。 - 确保
model_providers.zhipu块中的所有键值对都缩进一致，TOML 对缩进不强制但必须统一。 - 如果文件里有像“today”这样的日期或特殊字符串，需要用双引号包起来。
- 在终端执行
codex --debug查看详细日志，定位到具体是哪一行报错。
处理小技巧：如果实在找不到问题，直接备份这个文件然后删掉，让 Codex 重新生成一个默认配置，再逐项把你需要的参数加回去。
5.2 报错model provider list is empty
这个问题的典型场景是：你指定了model_provider = "zhipu"，但 config.toml 里根本没有[model_providers.zhipu]这个块。Codex 找不到对应的 provider，自然就报列表为空。
解决办法很简单：检查model_provider的值和[model_providers.xxx]的 xxx 是否完全一致，包括大小写。比如我把 provider 定义为[model_providers.zhipu]，那model_provider就必须是zhipu，写成Zhipu或者zhipu-flash都会报错。
5.3cc switch local proxy failed while handling codex endpoint /responses
这是我踩过最深的一个坑。用 Codex++ 切换配置的时候，有时候会弹这个错，字面意思是“Codex++ 在处理 /responses 端点时本地转发失败”。
经过排查，我确认了问题根源：Codex++ 为了兼容某些特殊场景，会启动一个本地转发端口，把请求先发到本地再转给目标 API。某些条件下这个本地转发进程没有正常启动，或者端口被占用，就会报 local proxy failed。问题的关键不在于目标 API 是否正常，而是本地转发那一层挂了。
我的解决方案是：绕开本地转发，直接让 Codex CLI 使用最终的 API 地址。在 Codex++ 的 provider 配置里把“启用本地转发”之类的选项关掉，或者在 config.toml 里把 base_url 直接写成智谱的真实地址而不是http://127.0.0.1:端口。这样请求就不经过中间层了，问题自然解决。
如果你仍然遇到这个报错，另一种处理方式是彻底重启 Codex++，让它重新拉起本地转发服务。但以我的经验，直接关掉转发选项是最干净的方案，反正接智谱这种直连 API 根本不需要本地转发。
5.4 配置 GLM 后 Codex 无法读取历史对话
有段时间我遇到这个问题：config.toml 配好了，新对话没问题，但历史对话打不开，日志里提示“此对话串无法继续，请修复 config.toml:model”。
这个坑挺隐蔽的。原因是 Codex 的每个历史会话都会记录当时使用的模型和 provider 信息。如果你在会话创建之后，修改了 config.toml 里的model或model_provider，Codex 在恢复这个会话时需要确认原来的模型配置仍然存在。如果原来的 provider 已经被你删掉或者改了名字，它就恢复不了。
解决方案是我之前提到的多 provider 方法：
[model_providers.zhipu] name = "Zhipu GLM" base_url = "https://open.bigmodel.cn/api/paas/v4" env_key = "ZHIPU_API_KEY" wire_api = "responses" [model_providers.zhipu-flash] name = "Zhipu GLM Flash" base_url = "https://open.bigmodel.cn/api/paas/v4" env_key = "ZHIPU_API_KEY" wire_api = "responses"只要历史会话用到的 provider 配置块还在，Codex 就能正常恢复对话。另外，尽量不要频繁改名或者删配置块，保持历史配置的连续性。
5.5 认证失败：401 或 403 错误
这类错误的排查思路最直接：Codex 没有拿到有效的 API Key。
先确认环境变量是否设置成功：
echo $ZHIPU_API_KEY如果输出为空，说明环境变量没生效，检查你是不是在正确的 shell 配置文件里写的，写完后有没有重新加载。
再确认密钥本身是否有效。智谱开放平台的后台可以看到你的 API Key 余额和调用记录，去那里检查一下有没有被限流或者过期。
最后确认 base_url 拼写是否正确。智谱的兼容接口地址是https://open.bigmodel.cn/api/paas/v4，少个/v4就会 404，拼错域名就会 401。
5.6 Codex 回写覆盖 config.toml 问题
这是手动党的噩梦：你辛苦配好的 config.toml，在某次 Codex 操作之后被重置了，自定义的 provider 全部消失。
我目前的解决思路有两个。一是把配置文件设置为只读，用chmod 444或者 Windows 属性里的只读选项，这样 Codex 想回写也写不进去。缺点是你自己后续想改配置的时候要先去掉只读。
二是用 Codex 的另一个配置文件机制，把自定义配置放到它不会动的位置。虽然 config.toml 是主配置，但 Codex 支持通过环境变量指定配置文件路径：
CODEX_HOME=/path/to/my/config codex这样可以把自定义配置放在独立目录，避免和默认配置冲突。这个方法比较优雅，适合深度用户。不过要注意环境变量对 Codex++ 不一定生效，因为 Codex++ 写的是默认路径，除非你也给它配置相同的环境变量。
6. 实测效果与使用建议
接入完成之后，我最常用的场景是让 Codex 在现有项目里改 Bug 和加功能。把问题描述清楚，Codex 会自动读取相关文件，定位问题，修改代码，然后跑测试。GLM-5.3 在这个流程里表现得相当稳定，代码修改的位置准，逻辑也清楚，偶尔需要人工调整一下边界情况，但整体可用性已经相当高。
GLM-5.3-Flash 的响应速度确实快，几乎感觉不到延迟，适合那种“来回多轮、琐碎但量大”的对话。Codex 在一个大任务里可能需要调用模型十几次甚至几十次，如果用旗舰模型，Token 消耗会非常夸张。这时候把模型临时切成 Flash，成本直接降一个数量级。
最后再分享一个实用技巧：在 config.toml 里可以配置多个 GLM 模型，然后用 Codex++ 做热切换。日常小任务用 Flash，深度重构用 5.3，两边互补，体验比单一模型舒服得多。我建议你把 API Key 放到环境变量里而不是配置文件里，这样即使 config.toml 被回写，密钥也不会丢。折腾配置的过程中，最怕的是不知道怎么排查，希望这篇能帮你少走些弯路。
