1. Codex 里 /model 看不到 GPT-5.5 的真实原因Codex CLI 升级到 0.124.0 之后模型列表并不是写死在二进制里的而是由一份本地模型目录文件model catalog驱动。你在终端里敲/model它读的是~/.codex/目录下那份 JSON而不是去问远端「现在有哪些模型」。所以当 GPT-5.5 已经可用、但你的本地目录还是旧版本时/model里就只会列出 gpt-5.4、gpt-5.4-mini 这些老面孔GPT-5.5 压根不会出现。这个设计本身是合理的模型目录本地化之后切换模型不需要联网离线也能列出候选还能给每个模型挂上 reasoning effort、speed tier 这些元信息。代价就是——新模型发布时你的本地目录不会自动刷新得手动补一条记录再告诉 Codex「去读这份新目录」。这就是model_catalog_json这个字段存在的意义它让你把模型目录指向一个自定义文件而不是默认那份。我先把问题场景说清楚方便你对照自己的情况。典型症状有三个第一codex --version显示 0.124.0 或更高但/model列表里没有 GPT-5.5第二你手动在config.toml里写model gpt-5.5启动后报模型不存在或者直接回退到默认模型第三/model里能看到条目但选中后请求失败提示模型未授权或 slug 不匹配。这三种症状根因不同但都指向同一件事本地模型目录和实际可用的模型对不上。适合读这篇的人是已经在本地用 Codex CLI 做日常开发、想第一时间切到 GPT-5.5 的工程师。你不需要改 Codex 源码也不需要等官方发新版目录只要补一份 JSON、改一行配置就能生效。整个过程涉及两个文件~/.codex/config.toml和~/.codex/model-catalog.gpt-5.5.json。下面按顺序来先讲清楚这两个文件各自管什么再给可复制的片段。需要提前说明一点模型目录里的slug必须和请求时实际发送的模型标识完全一致大小写、连字符都不能错。GPT-5.5 的 slug 是gpt-5.5display_name 可以写成GPT-5.5方便肉眼识别但 slug 一旦写错/model里可能显示正常发请求时却 404。这是后面排障章节会重点讲的一个坑。2. TaoToken 统一通道与 Codex 的接入前置Codex CLI 默认走的是官方端点但很多本地开发环境需要把请求收敛到一个统一的 API 通道方便管理 Key、切换模型、看用量。TaoToken 在这里扮演的就是这个统一入口一个 Key、一个 Base URL背后可以路由到包括 GPT-5.5 在内的多个模型。对 Codex 来说你只需要把base_url和env_key指向 TaoToken模型目录里保留gpt-5.5这个 slug请求就会带着这个 slug 发到统一通道。这里要区分两件事模型目录model catalog决定「Codex 界面上能选哪些模型」而config.toml里的 provider 配置决定「请求发到哪里、用什么 Key」。两者是解耦的。你可以目录里列了 GPT-5.5但 provider 还指着旧端点结果就是选得中、调不通。所以配置要成对改目录补 GPT-5.5provider 指向 TaoToken。TaoToken 的接入信息如下先记下来第 3 节会写进配置文件官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Base URLhttps://taotoken.net/apiAPI Key 管理页https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite注意Base URL 用https://taotoken.net/api不要在后面多加/v1或斜杠Codex 会自己拼接路径。多写一层路径是 404 的常见原因。拿到 Key 之后建议先把它写进环境变量而不是硬编码在config.toml里。Codex 的 provider 配置支持env_key字段它会去读同名环境变量。这样你的配置文件可以进 gitKey 留在本地 shell 配置里。设置方式export TAOTOKEN_API_KEYsk-你的key如果你用 zsh把上面这行加到~/.zshrc用 bash 就加到~/.bashrc。加完source一下或者重开终端。验证环境变量是否生效echo $TAOTOKEN_API_KEY能打印出 Key 就说明环境变量就位。这一步看起来简单但后面 401 报错里有一大半是环境变量没生效——比如你在一个终端里 export却在另一个终端里跑 codex。所以先确认这一步再往下走。关于模型标识TaoToken 通道里 GPT-5.5 对应的模型 ID 就是gpt-5.5和 Codex 模型目录里的 slug 保持一致。这种一致性是刻意的Codex 把 slug 原样放进请求体通道按这个 ID 路由。如果两边对不上就会出现「目录里能选、请求报模型不存在」的割裂现象。所以第 3 节的 JSON 里slug 一定写gpt-5.5。3. config.toml 与 model_catalog_json 可复制配置这一节是核心两个文件都给完整片段你直接复制改 Key 就行。先确认 Codex 版本低于 0.124.0 的话model_catalog_json字段可能不被识别codex --version如果版本旧先升级npm install -g openai/codex看到changed packages或added packages就说明升级完成。然后进~/.codex目录确认里面已有config.toml。没有的话新建一个。3.1 写 model-catalog.gpt-5.5.json在~/.codex/下新建model-catalog.gpt-5.5.json内容如下。这份目录保留了 gpt-5.4 作为兜底同时加入 gpt-5.5并把它的 priority 设为 0数值越小越靠前列表里排前面{ fetched_at: 2026-04-23T23:12:40.886423Z, etag: W/\ca788aa83f52c662612522a42107f869\, client_version: 0.124.0, models: [ { slug: gpt-5.5, display_name: GPT-5.5, description: Frontier model for complex coding, research, and real-world work., default_reasoning_level: medium, supported_reasoning_levels: [ { effort: low, description: Fast responses with lighter reasoning }, { effort: medium, description: Balances speed and reasoning depth for everyday tasks }, { effort: high, description: Greater reasoning depth for complex problems }, { effort: xhigh, description: Extra high reasoning depth for complex problems } ], shell_type: shell_command, visibility: list, supported_in_api: true, priority: 0, additional_speed_tiers: [fast], availability_nux: null, upgrade: null }, { slug: gpt-5.4, display_name: gpt-5.4, description: Strong model for everyday coding., default_reasoning_level: medium, supported_reasoning_levels: [ { effort: low, description: Fast responses with lighter reasoning }, { effort: medium, description: Balances speed and reasoning depth for everyday tasks }, { effort: high, description: Greater reasoning depth for complex problems }, { effort: xhigh, description: Extra high reasoning depth for complex problems } ], shell_type: shell_command, visibility: list, supported_in_api: true, priority: -1, additional_speed_tiers: [fast], availability_nux: null, upgrade: null } ] }几个字段值得单独说。visibility设为list才会出现在/model列表里设成hide就只能通过显式指定模型名调用。supported_in_api为 true 表示这个模型允许走 API 通道如果你的 provider 是自定义端点这个字段必须是 true否则 Codex 会拒绝把它发出去。priority控制排序GPT-5.5 给 0、gpt-5.4 给 -1 的话gpt-5.4 反而排前面想让 GPT-5.5 置顶把它的 priority 设成比 -1 更小的值比如 -2。这个细节很多人第一次配会搞反。3.2 改 config.toml打开~/.codex/config.toml加入或修改以下内容。关键是model_catalog_json指向刚写的文件provider 指向 TaoToken# 指向自定义模型目录让 /model 能列出 GPT-5.5 model_catalog_json ./model-catalog.gpt-5.5.json # 默认模型启动即用 GPT-5.5 model gpt-5.5 # 自定义 provider走 TaoToken 统一通道 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chatmodel_catalog_json用相对路径./model-catalog.gpt-5.5.json是相对于~/.codex/解析的所以两个文件放同一目录最省事。如果你习惯绝对路径写成/Users/你的用户名/.codex/model-catalog.gpt-5.5.json也行但换机器时要改不如相对路径省心。wire_api字段决定请求走哪种协议。Codex 支持chat和responses两种TaoToken 通道用chat即可。如果你不确定先按chat配调不通再换responses试。这个字段写错会直接报协议不匹配属于第 5 节排障范围。提示改完config.toml后Codex 需要重启才会重新读配置。已经开着的会话不会热加载退出再进。三件套到这里就齐了Base URL 是https://taotoken.net/apiKey 走TAOTOKEN_API_KEY环境变量Model ID 是gpt-5.5。这三个值在目录 JSON 和 config.toml 里必须一致任何一处写错都会在下一节验证时暴露出来。4. 验证请求确认 GPT-5.5 被正确识别与调用配置写完先做静态检查再做一次真实调用。静态检查是确认 Codex 读到了目录文件真实调用是确认请求能打到通道并返回。先看/model列表。启动 Codexcodex进去后输入/model你应该能看到GPT-5.5出现在列表里且排在前面。如果没看到说明model_catalog_json没生效回到第 3 节检查路径和文件名。看到之后选中它或者直接退出用命令行指定模型跑一次codex exec --model gpt-5.5 用一句话说明这个仓库是做什么的codex exec是非交互模式适合脚本化验证。如果返回了正常回答说明整条链路通了。返回内容里如果带模型标识确认是gpt-5.5而不是回退到别的模型。再补一个更直接的验证用 curl 打一次 TaoToken 的 chat 接口确认 Key 和模型 ID 本身没问题。这一步能把「Codex 配置问题」和「通道/Key 问题」分开curl https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-5.5, messages: [{role: user, content: reply with ok}] }正常返回是一个 JSONchoices[0].message.content里有内容。如果这一步就失败那问题不在 Codex而在 Key 或模型 ID先解决通道侧再回头看 Codex。如果这一步成功、但codex exec失败那问题在 Codex 配置重点查base_url、wire_api和目录文件。成功的结果长这样/model里 GPT-5.5 可选codex exec返回正常回答curl 返回 200 且带 choices。三者都过说明 GPT-5.5 在 Codex 里被正确识别和调用了。我实测下来最容易出问题的是wire_api和base_url这两处前者写错报协议错后者多写路径报 404。验证通过后日常使用就直接codex进去/model切到 GPT-5.5 即可。如果你想让某个项目默认用 GPT-5.5可以在项目根目录放一个.codex/config.toml覆盖全局配置但model_catalog_json建议只在全局配一份避免多份目录文件不同步。5. 常见报错排查401、local proxy failed 与 reading choices配置过程中会撞到几类固定报错逐个拆。先给一张对照表再展开说处理方式。报错关键词大概率原因处理方向401 UnauthorizedKey 未生效或写错查环境变量、Key 有效性local proxy failedBase URL 或网络层问题查 base_url、wire_apierror reading choices响应结构不符预期查 wire_api、通道返回model not foundslug 与通道 ID 不一致对齐 gpt-5.5OAuth / login required走了官方登录态确认 provider 指向自定义401 是最常见的。表现是请求返回401 Unauthorized或者 Codex 提示认证失败。根因通常是TAOTOKEN_API_KEY没被读到。排查顺序先echo $TAOTOKEN_API_KEY确认当前终端有值再确认config.toml里env_key TAOTOKEN_API_KEY拼写一致大小写敏感最后确认你启动 codex 的终端和 export 的终端是同一个。很多人是在 IDE 内置终端里跑 codex而 export 写在系统终端里两者环境不互通。解决方式是在 IDE 终端里也 export 一次或者把 export 写进 shell 启动文件后重启 IDE。local proxy failed通常和base_url有关。Codex 在发请求前会做一次端点可达性检查如果base_url写成了https://taotoken.net/api/v1这种多一层路径的形式检查就会失败报 local proxy failed。正确写法是https://taotoken.net/api不带尾部斜杠。另外确认wire_api和端点匹配chat对应/chat/completionsresponses对应另一套路径写错也会触发这个错。error reading choices是响应解析失败。Codex 期望返回体里有choices数组如果通道返回的是别的结构比如流式格式不对、或者wire_api选错导致请求发到了不兼容的端点解析就会报这个。处理方式先用第 4 节的 curl 确认通道返回的是标准 chat completions 结构如果 curl 正常但 Codex 报这个错把wire_api从chat换成responses再试反之亦然。两个值只有一个对试出来就固定下来。model not found或模型不存在是 slug 和通道 ID 不一致。检查目录 JSON 里的slug是不是gpt-5.5config.toml里的model是不是同一个值curl 里的model字段是不是也一致。三处必须完全相同。注意不要写成gpt-5.5-turbo或GPT-5.5slug 是精确匹配的。OAuth 或 login required 这类提示说明 Codex 还在走官方登录态没切到自定义 provider。检查config.toml里model_provider taotoken是否生效以及[model_providers.taotoken]段落名和引用名是否一致。段落名写错的话Codex 找不到 provider会回退到默认登录流程。如果以上都排查完还是不通把codex exec的完整报错、config.toml内容去掉 Key、以及 curl 的返回贴出来对照。多数情况下问题就出在base_url多写路径、env_key拼写、wire_api选错这三处之一。6. 长期编码与 Agent 场景的通道选择GPT-5.5 在 Codex 里跑通之后接下来要考虑的是长期使用的通道形态。如果你只是偶尔切模型试一下按第 3 节配好就行。但如果你打算把 Codex 当日常编码主力尤其是跑长任务、多轮 Agent 循环那 Key 和额度的管理方式就值得单独规划。TaoToken 的 Coding Plan 适合这种长期编码场景它把额度按周期打包不用每次调用都盯着余额。配置方式不变还是那三件套Base URL 用https://taotoken.net/apiKey 用环境变量注入Model ID 用gpt-5.5。区别只在于 Key 的来源从按量计费换成套餐。入口在这里Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite控制台看用量、管 Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_campaignrewriteAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite如果你还想在接入前先对比一下模型表现可以用模型对话页直接试 GPT-5.5 的回答质量确认符合预期再写进 Codex 配置模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite接入文档里有各客户端的完整配置示例Codex 之外还有 Claude Code、Cline 等配置思路一致都是 Base URL Key Model ID 三件套接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite回到 Codex 本身长期使用有两个小建议。第一把model_catalog_json指向的目录文件纳入版本管理模型更新时改这一份所有机器同步。第二config.toml里的model字段可以留空强制每次用/model显式选避免某次默认模型变更导致行为不一致。这两条不涉及通道但能减少日常切换的摩擦。配置到这一步就完整了目录文件补了 GPT-5.5config.toml 指向了它provider 走 TaoToken 统一通道验证请求通过常见报错有对照。剩下的就是把它用起来。
1. Codex 里 /model 看不到 GPT-5.5 的真实原因Codex CLI 升级到 0.124.0 之后模型列表并不是写死在二进制里的而是由一份本地模型目录文件model catalog驱动。你在终端里敲/model它读的是~/.codex/目录下那份 JSON而不是去问远端「现在有哪些模型」。所以当 GPT-5.5 已经可用、但你的本地目录还是旧版本时/model里就只会列出 gpt-5.4、gpt-5.4-mini 这些老面孔GPT-5.5 压根不会出现。这个设计本身是合理的模型目录本地化之后切换模型不需要联网离线也能列出候选还能给每个模型挂上 reasoning effort、speed tier 这些元信息。代价就是——新模型发布时你的本地目录不会自动刷新得手动补一条记录再告诉 Codex「去读这份新目录」。这就是model_catalog_json这个字段存在的意义它让你把模型目录指向一个自定义文件而不是默认那份。我先把问题场景说清楚方便你对照自己的情况。典型症状有三个第一codex --version显示 0.124.0 或更高但/model列表里没有 GPT-5.5第二你手动在config.toml里写model gpt-5.5启动后报模型不存在或者直接回退到默认模型第三/model里能看到条目但选中后请求失败提示模型未授权或 slug 不匹配。这三种症状根因不同但都指向同一件事本地模型目录和实际可用的模型对不上。适合读这篇的人是已经在本地用 Codex CLI 做日常开发、想第一时间切到 GPT-5.5 的工程师。你不需要改 Codex 源码也不需要等官方发新版目录只要补一份 JSON、改一行配置就能生效。整个过程涉及两个文件~/.codex/config.toml和~/.codex/model-catalog.gpt-5.5.json。下面按顺序来先讲清楚这两个文件各自管什么再给可复制的片段。需要提前说明一点模型目录里的slug必须和请求时实际发送的模型标识完全一致大小写、连字符都不能错。GPT-5.5 的 slug 是gpt-5.5display_name 可以写成GPT-5.5方便肉眼识别但 slug 一旦写错/model里可能显示正常发请求时却 404。这是后面排障章节会重点讲的一个坑。2. TaoToken 统一通道与 Codex 的接入前置Codex CLI 默认走的是官方端点但很多本地开发环境需要把请求收敛到一个统一的 API 通道方便管理 Key、切换模型、看用量。TaoToken 在这里扮演的就是这个统一入口一个 Key、一个 Base URL背后可以路由到包括 GPT-5.5 在内的多个模型。对 Codex 来说你只需要把base_url和env_key指向 TaoToken模型目录里保留gpt-5.5这个 slug请求就会带着这个 slug 发到统一通道。这里要区分两件事模型目录model catalog决定「Codex 界面上能选哪些模型」而config.toml里的 provider 配置决定「请求发到哪里、用什么 Key」。两者是解耦的。你可以目录里列了 GPT-5.5但 provider 还指着旧端点结果就是选得中、调不通。所以配置要成对改目录补 GPT-5.5provider 指向 TaoToken。TaoToken 的接入信息如下先记下来第 3 节会写进配置文件官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Base URLhttps://taotoken.net/apiAPI Key 管理页https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite注意Base URL 用https://taotoken.net/api不要在后面多加/v1或斜杠Codex 会自己拼接路径。多写一层路径是 404 的常见原因。拿到 Key 之后建议先把它写进环境变量而不是硬编码在config.toml里。Codex 的 provider 配置支持env_key字段它会去读同名环境变量。这样你的配置文件可以进 gitKey 留在本地 shell 配置里。设置方式export TAOTOKEN_API_KEYsk-你的key如果你用 zsh把上面这行加到~/.zshrc用 bash 就加到~/.bashrc。加完source一下或者重开终端。验证环境变量是否生效echo $TAOTOKEN_API_KEY能打印出 Key 就说明环境变量就位。这一步看起来简单但后面 401 报错里有一大半是环境变量没生效——比如你在一个终端里 export却在另一个终端里跑 codex。所以先确认这一步再往下走。关于模型标识TaoToken 通道里 GPT-5.5 对应的模型 ID 就是gpt-5.5和 Codex 模型目录里的 slug 保持一致。这种一致性是刻意的Codex 把 slug 原样放进请求体通道按这个 ID 路由。如果两边对不上就会出现「目录里能选、请求报模型不存在」的割裂现象。所以第 3 节的 JSON 里slug 一定写gpt-5.5。3. config.toml 与 model_catalog_json 可复制配置这一节是核心两个文件都给完整片段你直接复制改 Key 就行。先确认 Codex 版本低于 0.124.0 的话model_catalog_json字段可能不被识别codex --version如果版本旧先升级npm install -g openai/codex看到changed packages或added packages就说明升级完成。然后进~/.codex目录确认里面已有config.toml。没有的话新建一个。3.1 写 model-catalog.gpt-5.5.json在~/.codex/下新建model-catalog.gpt-5.5.json内容如下。这份目录保留了 gpt-5.4 作为兜底同时加入 gpt-5.5并把它的 priority 设为 0数值越小越靠前列表里排前面{ fetched_at: 2026-04-23T23:12:40.886423Z, etag: W/\ca788aa83f52c662612522a42107f869\, client_version: 0.124.0, models: [ { slug: gpt-5.5, display_name: GPT-5.5, description: Frontier model for complex coding, research, and real-world work., default_reasoning_level: medium, supported_reasoning_levels: [ { effort: low, description: Fast responses with lighter reasoning }, { effort: medium, description: Balances speed and reasoning depth for everyday tasks }, { effort: high, description: Greater reasoning depth for complex problems }, { effort: xhigh, description: Extra high reasoning depth for complex problems } ], shell_type: shell_command, visibility: list, supported_in_api: true, priority: 0, additional_speed_tiers: [fast], availability_nux: null, upgrade: null }, { slug: gpt-5.4, display_name: gpt-5.4, description: Strong model for everyday coding., default_reasoning_level: medium, supported_reasoning_levels: [ { effort: low, description: Fast responses with lighter reasoning }, { effort: medium, description: Balances speed and reasoning depth for everyday tasks }, { effort: high, description: Greater reasoning depth for complex problems }, { effort: xhigh, description: Extra high reasoning depth for complex problems } ], shell_type: shell_command, visibility: list, supported_in_api: true, priority: -1, additional_speed_tiers: [fast], availability_nux: null, upgrade: null } ] }几个字段值得单独说。visibility设为list才会出现在/model列表里设成hide就只能通过显式指定模型名调用。supported_in_api为 true 表示这个模型允许走 API 通道如果你的 provider 是自定义端点这个字段必须是 true否则 Codex 会拒绝把它发出去。priority控制排序GPT-5.5 给 0、gpt-5.4 给 -1 的话gpt-5.4 反而排前面想让 GPT-5.5 置顶把它的 priority 设成比 -1 更小的值比如 -2。这个细节很多人第一次配会搞反。3.2 改 config.toml打开~/.codex/config.toml加入或修改以下内容。关键是model_catalog_json指向刚写的文件provider 指向 TaoToken# 指向自定义模型目录让 /model 能列出 GPT-5.5 model_catalog_json ./model-catalog.gpt-5.5.json # 默认模型启动即用 GPT-5.5 model gpt-5.5 # 自定义 provider走 TaoToken 统一通道 model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chatmodel_catalog_json用相对路径./model-catalog.gpt-5.5.json是相对于~/.codex/解析的所以两个文件放同一目录最省事。如果你习惯绝对路径写成/Users/你的用户名/.codex/model-catalog.gpt-5.5.json也行但换机器时要改不如相对路径省心。wire_api字段决定请求走哪种协议。Codex 支持chat和responses两种TaoToken 通道用chat即可。如果你不确定先按chat配调不通再换responses试。这个字段写错会直接报协议不匹配属于第 5 节排障范围。提示改完config.toml后Codex 需要重启才会重新读配置。已经开着的会话不会热加载退出再进。三件套到这里就齐了Base URL 是https://taotoken.net/apiKey 走TAOTOKEN_API_KEY环境变量Model ID 是gpt-5.5。这三个值在目录 JSON 和 config.toml 里必须一致任何一处写错都会在下一节验证时暴露出来。4. 验证请求确认 GPT-5.5 被正确识别与调用配置写完先做静态检查再做一次真实调用。静态检查是确认 Codex 读到了目录文件真实调用是确认请求能打到通道并返回。先看/model列表。启动 Codexcodex进去后输入/model你应该能看到GPT-5.5出现在列表里且排在前面。如果没看到说明model_catalog_json没生效回到第 3 节检查路径和文件名。看到之后选中它或者直接退出用命令行指定模型跑一次codex exec --model gpt-5.5 用一句话说明这个仓库是做什么的codex exec是非交互模式适合脚本化验证。如果返回了正常回答说明整条链路通了。返回内容里如果带模型标识确认是gpt-5.5而不是回退到别的模型。再补一个更直接的验证用 curl 打一次 TaoToken 的 chat 接口确认 Key 和模型 ID 本身没问题。这一步能把「Codex 配置问题」和「通道/Key 问题」分开curl https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-5.5, messages: [{role: user, content: reply with ok}] }正常返回是一个 JSONchoices[0].message.content里有内容。如果这一步就失败那问题不在 Codex而在 Key 或模型 ID先解决通道侧再回头看 Codex。如果这一步成功、但codex exec失败那问题在 Codex 配置重点查base_url、wire_api和目录文件。成功的结果长这样/model里 GPT-5.5 可选codex exec返回正常回答curl 返回 200 且带 choices。三者都过说明 GPT-5.5 在 Codex 里被正确识别和调用了。我实测下来最容易出问题的是wire_api和base_url这两处前者写错报协议错后者多写路径报 404。验证通过后日常使用就直接codex进去/model切到 GPT-5.5 即可。如果你想让某个项目默认用 GPT-5.5可以在项目根目录放一个.codex/config.toml覆盖全局配置但model_catalog_json建议只在全局配一份避免多份目录文件不同步。5. 常见报错排查401、local proxy failed 与 reading choices配置过程中会撞到几类固定报错逐个拆。先给一张对照表再展开说处理方式。报错关键词大概率原因处理方向401 UnauthorizedKey 未生效或写错查环境变量、Key 有效性local proxy failedBase URL 或网络层问题查 base_url、wire_apierror reading choices响应结构不符预期查 wire_api、通道返回model not foundslug 与通道 ID 不一致对齐 gpt-5.5OAuth / login required走了官方登录态确认 provider 指向自定义401 是最常见的。表现是请求返回401 Unauthorized或者 Codex 提示认证失败。根因通常是TAOTOKEN_API_KEY没被读到。排查顺序先echo $TAOTOKEN_API_KEY确认当前终端有值再确认config.toml里env_key TAOTOKEN_API_KEY拼写一致大小写敏感最后确认你启动 codex 的终端和 export 的终端是同一个。很多人是在 IDE 内置终端里跑 codex而 export 写在系统终端里两者环境不互通。解决方式是在 IDE 终端里也 export 一次或者把 export 写进 shell 启动文件后重启 IDE。local proxy failed通常和base_url有关。Codex 在发请求前会做一次端点可达性检查如果base_url写成了https://taotoken.net/api/v1这种多一层路径的形式检查就会失败报 local proxy failed。正确写法是https://taotoken.net/api不带尾部斜杠。另外确认wire_api和端点匹配chat对应/chat/completionsresponses对应另一套路径写错也会触发这个错。error reading choices是响应解析失败。Codex 期望返回体里有choices数组如果通道返回的是别的结构比如流式格式不对、或者wire_api选错导致请求发到了不兼容的端点解析就会报这个。处理方式先用第 4 节的 curl 确认通道返回的是标准 chat completions 结构如果 curl 正常但 Codex 报这个错把wire_api从chat换成responses再试反之亦然。两个值只有一个对试出来就固定下来。model not found或模型不存在是 slug 和通道 ID 不一致。检查目录 JSON 里的slug是不是gpt-5.5config.toml里的model是不是同一个值curl 里的model字段是不是也一致。三处必须完全相同。注意不要写成gpt-5.5-turbo或GPT-5.5slug 是精确匹配的。OAuth 或 login required 这类提示说明 Codex 还在走官方登录态没切到自定义 provider。检查config.toml里model_provider taotoken是否生效以及[model_providers.taotoken]段落名和引用名是否一致。段落名写错的话Codex 找不到 provider会回退到默认登录流程。如果以上都排查完还是不通把codex exec的完整报错、config.toml内容去掉 Key、以及 curl 的返回贴出来对照。多数情况下问题就出在base_url多写路径、env_key拼写、wire_api选错这三处之一。6. 长期编码与 Agent 场景的通道选择GPT-5.5 在 Codex 里跑通之后接下来要考虑的是长期使用的通道形态。如果你只是偶尔切模型试一下按第 3 节配好就行。但如果你打算把 Codex 当日常编码主力尤其是跑长任务、多轮 Agent 循环那 Key 和额度的管理方式就值得单独规划。TaoToken 的 Coding Plan 适合这种长期编码场景它把额度按周期打包不用每次调用都盯着余额。配置方式不变还是那三件套Base URL 用https://taotoken.net/apiKey 用环境变量注入Model ID 用gpt-5.5。区别只在于 Key 的来源从按量计费换成套餐。入口在这里Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite控制台看用量、管 Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_campaignrewriteAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite如果你还想在接入前先对比一下模型表现可以用模型对话页直接试 GPT-5.5 的回答质量确认符合预期再写进 Codex 配置模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite接入文档里有各客户端的完整配置示例Codex 之外还有 Claude Code、Cline 等配置思路一致都是 Base URL Key Model ID 三件套接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_campaignrewrite回到 Codex 本身长期使用有两个小建议。第一把model_catalog_json指向的目录文件纳入版本管理模型更新时改这一份所有机器同步。第二config.toml里的model字段可以留空强制每次用/model显式选避免某次默认模型变更导致行为不一致。这两条不涉及通道但能减少日常切换的摩擦。配置到这一步就完整了目录文件补了 GPT-5.5config.toml 指向了它provider 走 TaoToken 统一通道验证请求通过常见报错有对照。剩下的就是把它用起来。
