1. 为什么要把 Codex 的鉴权文件改到统一通道

GLM-4.6 是智谱新一代旗舰大模型，总参数量 355B、激活参数 32B，上下文窗口从 128K 提升到 200K，在真实编程、跨文件调试、长文档阅读这些场景里表现很能打。如果你平时用 Codex 这类命令行编码助手，默认它走的是 OpenAI 的鉴权链路，想换成 GLM-4.6 就得动auth.json这个文件。问题在于，很多人第一次改的时候不知道字段该填什么、Base URL 写哪个、Model ID 用哪个名字，改完一跑就报 401 或者local proxy failed，然后卡在那里。

我自己在把 Codex 接到 GLM-4.6 的过程中，踩过几个典型的坑：一是auth.json里OPENAI_API_KEY和base_url的对应关系没搞清，二是 Model ID 写成了展示名而不是接口名，三是环境变量和文件配置打架。这篇就按「改文件 → 校验 → 发请求 → 排错」的顺序，把每一步都拆开讲，你照着做就能跑通。

适合谁看：已经在用 Codex CLI 或者类似编码助手、想切到 GLM-4.6 的开发者；对auth.json结构不熟、被 401 卡住的新手；以及想把多个模型的鉴权收敛到一个统一入口、方便切换的人。核心检索词就三个：GLM-4.6 接入、Codex auth.json 配置、TaoToken 统一通道。下面所有配置都以 TaoToken 作为统一入口来演示，Base URL 用https://taotoken.net/api，Key 在控制台生成。

先说清楚一个概念，避免后面混淆。Codex 的auth.json本质是一个本地鉴权描述文件，它告诉 CLI「去哪个地址、用哪个 Key、请求哪个模型」。默认它指向 OpenAI 官方，你要做的就是把这三个值替换掉。替换本身不难，难的是三个值必须互相匹配：Base URL 要能被 Codex 识别为兼容 OpenAI 的接口，Key 要在这个地址下有效，Model ID 要在这个通道里真实存在。任何一项对不上，报错就来了。所以下面的步骤里，我会把「改哪一行、为什么这么改、改完怎么验证」绑在一起讲，而不是只丢一个模板给你。

2. TaoToken 前置准备：Key、Base URL 与模型名三件套

在动auth.json之前，先把三件套准备好，否则你改完文件还得回头找参数，来回折腾。这三件套是：Base URL、API Key、Model ID。它们分别对应auth.json里的地址字段、密钥字段、模型字段。

Base URL 用https://taotoken.net/api。注意这里不要加多余的路径后缀，Codex 会自己在后面拼/v1/chat/completions之类的端点。如果你手滑写成https://taotoken.net/api/v1，有些版本会拼成/v1/v1/...，直接 404。API Key 去控制台生成，地址是https://taotoken.net/console，生成后复制那一串以sk-开头的字符串，先存到记事本里，等下要粘进 JSON。Model ID 这块最容易出错：GLM-4.6 在接口里调用的名字，要以你所用通道的模型列表为准，不要想当然写glm-4.6就一定能通。稳妥的做法是先拉一次模型列表确认。

拉模型列表的命令很简单，把 Key 换成你自己的：

curl https://taotoken.net/api/v1/models \ -H "Authorization: Bearer sk-你的Key"

返回的 JSON 里会有一个data数组，每个元素有id字段。找到包含glm的那一项，把它的id原样记下来，这就是你要填进auth.json的 Model ID。我实测下来，这一步能省掉后面 80% 的「模型不存在」报错。如果你懒得记，直接把返回结果里glm相关的id复制出来就行。

三件套齐了之后，建议先单独用 curl 打一次对话接口，确认通道本身是通的，再去改 Codex 的配置文件。这样能把「通道问题」和「配置文件问题」分开，排错时不会互相干扰。对话接口的测试命令：

curl https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer sk-你的Key" \ -H "Content-Type: application/json" \ -d '{ "model": "你查到的GLM模型ID", "messages": [{"role": "user", "content": "用一句话说明快速排序的思路"}] }'

如果这条命令返回了正常的choices内容，说明 Key、Base URL、Model ID 三件套没问题，可以进入下一步改auth.json。如果这里就报 401，那是 Key 的问题；报模型不存在，那是 Model ID 的问题；报连接失败，那是 Base URL 或网络的问题。先把这一层过了，后面会顺很多。

3. 可复制的 auth.json 配置模板与逐项校验

Codex 的auth.json一般放在用户目录下的.codex文件夹里，Linux/macOS 是~/.codex/auth.json，Windows 是C:\Users\你的用户名\.codex\auth.json。如果文件不存在，手动建一个。下面是可以直接复制的模板，把三个占位符替换成你上一步准备好的值：

{ "OPENAI_API_KEY": "sk-你的Key", "tokens": { "access_token": "sk-你的Key", "refresh_token": "" }, "base_url": "https://taotoken.net/api", "model": "你查到的GLM模型ID", "preferred_auth_method": "apikey" }

逐项说一下为什么这么填。OPENAI_API_KEY和tokens.access_token都填同一个 Key，是因为不同版本的 Codex 读取鉴权的字段不一样，有的读顶层，有的读tokens里的access_token，两个都填上能兼容大多数版本。refresh_token留空字符串，因为我们用的是静态 Key，不需要刷新流程。base_url填https://taotoken.net/api，这是统一入口地址。model填你从模型列表里查到的 GLM-4.6 对应 ID。preferred_auth_method设为apikey，明确告诉 Codex 用 Key 鉴权，而不是走 OAuth 那套。

如果你用的是 TOML 格式的配置（部分工具链用config.toml），等价写法是这样：

[auth] api_key = "sk-你的Key" base_url = "https://taotoken.net/api" model = "你查到的GLM模型ID" preferred_auth_method = "apikey"

改完之后，别急着跑，先做三项校验。第一项，确认 JSON 语法没写错，用python -m json.tool ~/.codex/auth.json跑一下，能正常输出格式化结果就说明语法没问题。第二项，确认文件权限，Linux/macOS 下建议chmod 600 ~/.codex/auth.json，避免 Key 被其他用户读到。第三项，确认没有环境变量覆盖，检查一下OPENAI_API_KEY和OPENAI_BASE_URL这两个环境变量有没有被设置，如果设了，它们会优先于文件配置，导致你改了文件却不生效。用env | grep OPENAI看一眼，有的话先unset掉。

这里有个细节值得单独提醒：有些工具链会同时读auth.json和config.toml，两者冲突时以哪个为准取决于版本。稳妥做法是只保留一份配置，要么全放auth.json，要么全放config.toml，不要两边都写不同的值。我试过两边都写、值还不一样，结果排查了半天才发现是配置文件打架。

4. 验证请求：从连通性测试到真实编码任务

配置改完，先做最小连通性验证。Codex 一般有个非交互模式，可以直接发一条 prompt 看返回。命令大致是这样：

codex exec "用 Python 写一个读取 CSV 并统计每列空值数量的函数"

如果配置正确，你会看到 Codex 把请求发到https://taotoken.net/api，然后返回 GLM-4.6 生成的代码。第一次跑可能会慢几秒，因为要建立连接。返回内容里如果包含完整的函数定义和注释，说明链路通了。

连通性过了之后，建议用一个稍微真实点的编码任务再验一次，比如让它处理一个跨文件的小需求。GLM-4.6 的 200K 上下文在这个场景下优势明显，你可以把两三个相关文件的内容一起喂进去，看它能不能正确理解文件间的调用关系。测试 prompt 可以这样写：

codex exec "读取当前目录下的 utils.py 和 main.py，说明 main.py 里调用了 utils.py 的哪些函数，并指出有没有参数不匹配的地方"

这个测试能同时验证三件事：模型能不能读到多文件内容、能不能做跨文件推理、返回结果是不是结构化的。如果它准确列出了函数名和参数对比，说明 GLM-4.6 在你的通道里工作正常。

验证成功后，返回结果的结构大致是这样的：choices[0].message.content里是模型输出，usage字段里能看到prompt_tokens和completion_tokens。你可以留意一下 token 消耗，GLM-4.6 相比上一代在同等任务下平均能省 30% 以上的 tokens，长任务里这个差距会更明显。如果usage字段缺失或者为 0，可能是通道没有正确透传计费信息，但不影响功能使用。

还有一点，如果你在 Codex 里配了多个模型想切换，可以在auth.json里改model字段，或者用命令行参数临时覆盖。临时覆盖的写法是codex exec --model 你的模型ID "prompt"，这样不用改文件就能试不同模型。验证阶段建议多用临时覆盖，确认没问题了再写死到文件里。

5. 常见报错排查：401、local proxy failed 与模型不存在

排错这块我按真实遇到的报错来列，每个都给定位思路和修法。

401 Unauthorized。这个最常见，原因通常是 Key 无效、Key 前后有空格、或者auth.json里的 Key 和环境变量里的 Key 不一致。先检查 Key 有没有复制完整，sk-开头后面那一长串不能少字符。然后确认auth.json里OPENAI_API_KEY和tokens.access_token两个值完全一样。最后env | grep OPENAI看有没有环境变量在捣乱，有就 unset。如果都排除了还报 401，去控制台重新生成一个 Key 再试，排除 Key 本身被禁用的情况。

local proxy failed。这个报错通常出现在 Codex 尝试走本地代理但代理没起来的时候。检查你的配置里有没有残留的proxy或http_proxy字段，有的话删掉。另外确认base_url写的是https://taotoken.net/api而不是http://localhost:xxxx之类的本地地址。如果你之前配过本地转发，把那段配置清干净。这个报错和网络环境无关，纯粹是配置指向了不存在的本地服务。

reading choices 相关报错。典型的是cannot read property 'choices' of undefined或者reading 'choices'。这说明请求发出去了，但返回的 JSON 结构里没有choices字段。原因一般是 Base URL 拼错了，比如多加了/v1导致请求打到了错误端点，返回了一个错误页而不是标准响应。把base_url改回https://taotoken.net/api，不要带任何后缀。另一个可能是 Model ID 写错，通道返回了错误对象，同样没有choices。用第 2 节的模型列表命令重新确认 ID。

OAuth 相关报错。如果看到提示要走 OAuth 登录或者refresh_token无效，说明 Codex 没走 Key 鉴权，而是尝试了 OAuth 流程。检查preferred_auth_method是不是设成了apikey，以及refresh_token是不是空字符串。有些版本还需要在配置里显式关闭 OAuth，加一行"force_apikey": true之类的字段，具体看你的 Codex 版本文档。核心思路就是明确告诉它「用 Key，别走 OAuth」。

模型不存在 / model not found。这个直接对应 Model ID 写错。回到第 2 节，重新拉一次模型列表，把glm相关的id原样复制。注意大小写和连字符，GLM-4.6和glm-4.6在某些通道里是两个不同的标识。不要用展示名，要用接口名。

排查顺序建议固定下来：先 curl 测通道，再查auth.json语法，再看环境变量，最后看 Model ID。按这个顺序走，基本能在五分钟内定位到问题。

6. 把 GLM-4.6 接入日常编码流的几个实用建议

跑通之后，有几个习惯能让这套配置更稳。第一，把auth.json备份一份，改坏了直接还原，不用重新配。第二，如果你同时用多个编码工具，尽量让它们共用同一个 Base URL 和 Key，这样切换工具时不用重新找参数。第三，长任务前先用小 prompt 探一下通道，确认没报错再跑大任务，避免跑到一半断掉。

GLM-4.6 在编码场景里比较适合的任务类型：跨文件重构、长文档里的代码提取、多轮调试。它的 200K 上下文意味着你可以把整个模块的文件一起喂进去，让它做整体分析，而不是一个文件一个文件地问。实测下来，跨文件任务里它的表现比单文件问答更能体现优势。

如果你想把鉴权收敛得更彻底，可以在控制台里管理 Key 的权限和用量，地址是https://taotoken.net/api-keys。需要查接口细节的时候看文档https://taotoken.net/doc。想直接对话验证模型效果的，用https://taotoken.net/chat。长期跑编码任务、需要稳定额度的，可以看 Coding Plan 的说明https://taotoken.net/coding-plan。这几个入口按需取用，配置本身不变，还是那三件套：Base URL、Key、Model ID。

最后留一个我踩过的坑：改完auth.json后，有些工具会缓存旧的鉴权信息，需要重启终端或者清一下缓存目录才生效。如果你确认配置没错但行为还是旧的，先重启再排查，能省不少时间。