先看错误信息
无法加载 config.toml，因此此对话串无法继续。
model provider `custom` not found
其他独立错误：TOML parse errorCodex config.toml error 先处理无法解析的行、重复表和字段类型，再核对 model_provider 与对应 Provider 配置。备份原文件并保留已有设置；配置能加载后，才继续检查接口协议和模型请求。
正在打开页面…
正在加载内容，请稍候。
- 保留现场
记录状态码、错误正文和请求时间
- 缩小范围
按下方检查项逐个排除，不同时修改多项
- 最小复测
用同一请求验证，再回到原工具测试
常见表现
- 启动或打开对话时无法读取配置
- 错误提示 provider 名称不存在
- 错误带有配置文件行号或 TOML 解析信息
这个报错是什么意思
资料核对：2026-10-07，依据当前官方 Configuration Reference 与本机 Codex CLI 0.162.0-alpha.2。provider 设置使用用户级配置；该版本可用 codex features list 做本地加载检查。下方保留 2026-09-28 及 2026-10-06 的历史验证，均不等于完成代码任务或后台实扣验证。
先判断是哪一类问题
对照请求链路定位失败阶段
判断 01
TOML parse error / unclosed array：配置还未成功解析。检查指定行及前一行，常见问题是漏引号、漏 ]、重复键或值类型不正确。
判断 02
Model provider `custom` not found：配置中选择了 custom，但生效范围内没有同名 [model_providers.custom]；网址不应写进 model_provider。
判断 03
只在项目目录设置 provider：当前官方参考说明项目级配置不能覆盖 model_provider 与 model_providers；将这些字段放进实际用户级文件。
判断 04
Missing environment variable 或 HTTP 401：进入认证阶段，检查启动环境和令牌；400 / 404 再查准确模型 ID、最终路径与 Responses 支持。
按顺序修复
01
执行 codex --version，按错误指向找到实际 config.toml 并备份；默认用户级位置是 ~/.codex/config.toml，自定义 CODEX_HOME 时用对应目录。
02
有 TOML 行号时先修语法；provider 未找到时，将 model_provider 的值与 [model_providers.名称] 对齐。
03
将 provider 定义合并进用户级配置，不只写在项目的 .codex/config.toml；也核对启动命令的 --profile 与独立 profile 文件。
04
保留其他设置，运行 codex features list 检查加载。通过后重新打开原应用或会话，再处理模型调用。
详细修复步骤
Step 01
配置可加载后，单独核对请求与工具历史
只有配置加载通过才进入网络诊断。Codex 使用 Responses，完整路径应是 /v1/responses；不能用 chat.completions 的 messages 当作 Responses 请求。工具结果用 function_call_output.call_id 对应先前 function_call.call_id，而不是响应 item 的 id。若使用 previous_response_id 或 conversation，局部历史检查无法看到服务器端全部调用，应保留为待核对；不要把缺少的服务端历史补造成新的结果。
Step 02
先修 TOML，不重置整个目录
按报错行号逐行检查。表头 [model_providers.apizt] 必须完整，字符串用配对引号；顶层 model 与 model_provider 放在表头之前，避免被误归入 provider 子表。不要删除 auth.json 或整个 ~/.codex 来修语法。
Step 03
provider 名称两处一致
正确示例使用 apizt。保留 custom 也可以，但 model_provider 的值和 model_providers 子表都要使用 custom。name 是显示名称，不能替代选择字段。
Step 04
确认实际读取的配置
检查报错中的文件路径、自定义 CODEX_HOME 与启动命令的 --profile。Codex 0.134.0 起，profile 读取用户目录的 <name>.config.toml；旧 [profiles.name] 和顶层 profile 已停用。在用户级配置中合并相关字段；终端与桌面应用可能使用不同的启动环境。升级后先核对当前版本的官方参考，不照搬旧 wire_api=chat 写法。
Step 05
确认 Key 与 Responses 分开生效
env_key 填 tokenba_API_KEY 这个变量名，真实 Key 只放启动环境。base_url 填 https://api.apizt.com/v1，wire_api 使用 responses。再从模型广场复制该令牌分组支持 Responses 的准确 ID；聊天成功不能代替这一步。
正确配置
model = "REPLACE_WITH_SUPPORTED_MODEL_ID"
model_provider = "apizt"
[model_providers.apizt]
name = "apizt"
base_url = "https://api.apizt.com/v1"
env_key = "tokenba_API_KEY"
wire_api = "responses"常见原因
- model_provider 指定 custom，但没有 model_providers.custom
- 误写成单数 model_provider 表
- 字符串引号、重复键或表层级错误
- 把 provider 放进了不支持该设置的项目级配置
不要这样填
model_provider = "custom"
[model_providers.apizt]
base_url = "https://api.apizt.com/v1"怎么确认已经修好
- 本地加载：执行 codex features list，应不再出现 TOML 或 provider 错误。这一步不发送推理请求，也不验证 Key 与模型权限。
- 认证环境：终端可执行 python3 -c 'import os; print("已设置" if os.environ.get("tokenba_API_KEY") else "未设置")'，只检查存在，不输出密钥；桌面应用另核对其启动环境。
- 最小请求：确认模型与分组支持 Responses 后再自行发起调用，检查有效文本和同一请求的日志。这一步可能产生费用。
- 实际任务：在测试仓库验证读取、修改及测试结果，人工检查 diff；成功返回文字不等于完成 coding。
- 历史范围：2026-09-28 的 CLI 0.158.0-alpha.2.1 复现了 provider 未找到；2026-10-06 的 CLI 0.159.0-alpha.12.1 通过有效 TOML 并拒绝错误语法。均为隔离配置记录，没有本轮付费任务实测。
避免下次再报错
- 升级前保留配置备份与工具版本，按官方参考合并字段。
- 修改前记录 provider、模型 ID、profile 和启动环境；每次只改必要部分。
- 配置加载、认证、Responses 和完整任务分步验收，保留脱敏错误与请求 ID。
仍未解决？这样提供排查信息
记录报错时间、工具版本、模型 ID 和 HTTP 状态码，附上脱敏后的错误正文。
说明问题是否稳定复现，以及同一配置的最小请求是否成功。
可以提供请求 ID 或控制台日志编号，不要发送完整 API Key、密码或个人业务数据。
先区分配置、权限、额度与上游服务问题；不要通过重复充值或高频重试来排查。
Codex custom provider 错误：真实复现记录
- 验证版本：codex-cli 0.158.0-alpha.2.1，日期 2026-09-28。创建独立临时目录作为 CODEX_HOME，不改现有用户配置。
- 只设置 model_provider=custom，不定义 model_providers.custom；执行 codex exec --skip-git-repo-check --ephemeral hello。
- 要保留 custom 名称，就定义同名表；要改 apizt，就同步修改选择字段和 provider 表名。env_key 写环境变量名，wire_api 使用 responses，所选模型必须支持该端点。
model_provider = "custom"
model = "REPLACE_WITH_SUPPORTED_MODEL_ID"
[model_providers.custom]
name = "apizt"
base_url = "https://api.apizt.com/v1"
env_key = "tokenba_API_KEY"
wire_api = "responses"缺少 provider 表时实测退出码 1，原始输出：Error: Model provider `custom` not found。补充同名 provider 表后，实测已越过 provider 检查，并停在特意留空的测试环境变量 QR_SEO_TEST_MISSING_KEY；使用本地禁用端点，没有生产请求。之后还要验证真实环境变量、模型权限和 Responses 支持。没有完成付费模型会话测试。
Codex 官方配置字段与作用域先修配置加载，再检查 Key 与 Responses
model provider custom not found 的直接修复是让 model_provider 的值与 [model_providers.名称] 一致。TOML parse error 则先修报错行的语法；这些错误发生在模型请求之前，更换 Key 或充值不能解决。
- 报错或症状
- model provider custom not found
- 对应修复
- 保留 custom 时使用 [model_providers.custom]；改为 apizt 时两处一起改
- 通过条件
- 当前 CLI 能加载同名 provider
- 报错或症状
- TOML parse error / unclosed array
- 对应修复
- 修报错行及前一行的引号、方括号与重复键；顶层字段放在 provider 表之前
- 通过条件
- codex features list 不再显示解析错误
- 报错或症状
- 项目配置里的 provider 不生效
- 对应修复
- 把 model_provider 与 model_providers 合并进实际用户级 config.toml
- 通过条件
- 错误指向的文件与自定义 CODEX_HOME 一致
- 报错或症状
- --profile work 没读取旧配置
- 对应修复
- Codex 0.134.0 起改用用户目录的 work.config.toml
- 通过条件
- codex --profile work features list 加载通过
- 报错或症状
- invalid transport in mcp_servers.codex_app
- 对应修复
- 单独核对 MCP 配置；自管服务按官方 command 或 url 格式配置，应用管理的条目由应用重新生成
- 通过条件
- MCP 配置错误消失，保留无关 provider 与登录数据
- 报错或症状
- Missing environment variable / 401 / 404
- 对应修复
- env_key 填变量名；在应用启动环境设置 Key，并选支持 Responses 的模型与分组
- 通过条件
- 实际 /v1/responses 返回有效结果
- 报错或症状
- 配置加载成功，代码任务仍失败
- 对应修复
- 分别记录 TOML 加载、Responses 短请求、function_call 往返与仓库测试
- 通过条件
- 只在实际文件修改和已有测试通过后记录仓库任务通过
- 报错或症状
- 需要核对任务费用
- 对应修复
- 保存模型与分组、全部回合 usage、重试、请求时间及 request ID
- 通过条件
- 估算与实扣分别标注；配置检查器和 API 样本不代表 Codex 客户端费用
合并这段最小配置，不覆盖整个文件
- 按报错中的路径备份配置。默认用户文件是 ~/.codex/config.toml；使用自定义 CODEX_HOME 时以对应目录为准，保留其他已有设置。
- 将下方模型占位符换成令牌分组支持 Responses 的准确 ID。env_key 是环境变量名称，真实 Key 只放 Codex 实际启动环境。
- 运行 codex --version 与 codex features list；使用 profile 时追加对应 --profile。也可先把脱敏配置粘贴到本地检查器，检查器不验证真实认证。
- 加载通过后重新打开原客户端，发一个短请求。随后在测试仓库验证文件读取、修改和测试；仅能启动或返回文字还不能证明完整代码任务通过。
- 修复后保留三个独立结论：配置已加载 / Responses 已返回 / 仓库任务已完成；尚未执行的阶段记待验证。固定任务报告只提供 API 输出检查，不能证明 Codex 的文件权限、工具执行或测试流程已经通过。
配置与验证示例
配置片段本身不发请求。加载检查通过后，再单独验证 Responses 与真实代码任务。
model = "REPLACE_WITH_RESPONSES_MODEL_ID"
model_provider = "apizt"
[model_providers.apizt]
name = "apizt"
base_url = "https://api.apizt.com/v1"
env_key = "tokenba_API_KEY"
wire_api = "responses"先检查 TOML、provider 与 profile按型号生成 Codex 配置参考仓库任务与测试验收官方配置字段与作用域官方 profile 与用户目录说明官方 MCP 配置格式查看固定任务的 API 验收记录与范围整理多回合任务用量与估算费用下载接入包、配置示例与空白任务记录
下载 MIT 接入包与任务记录表核验日期与验证范围见各页记录；历史实测保留原日期，示例和空白记录表不等于真实任务结果。
排查完成后，再开始接入
先按上文检查地址、鉴权与协议，并完成复测。确认要使用 apizt 后，再创建 API Key、选择模型并配置工具；充值不能修复配置错误。
创建 API Key
在控制台创建令牌，选择需要使用的模型权限。
填写接入配置
按工具要求填写 API Key、接口地址与模型 ID。
发起第一次调用
确认收到有效结果，再到控制台查看用量与费用。
FAQ
Codex config.toml error 怎样定位语法错误？
依据错误中的行和列检查引号、表声明、重复键及值类型，使用本页配置检查步骤处理。先备份，只合并所需字段；配置解析失败时更换 Key 没有帮助。
Codex model_provider 与 model_providers 怎么对应？
model_provider 的值应对应自定义 Provider 表的键，再核对 base_url、wire_api 与鉴权字段。不要把展示名称或目标模型 ID 当作 Provider 键。
新版 --profile 的配置放在哪里？
Codex 0.134.0 起，使用用户目录的 <name>.config.toml，例如 ~/.codex/work.config.toml，再用 codex --profile work 启动。config.toml 中旧 [profiles.work] 和顶层 profile 选择字段已停用；检查器可分别粘贴用户配置和 profile 文件。
为什么换 API Key 没用？
provider 未找到或 TOML 解析失败发生在配置加载阶段，先修配置，再处理认证错误。
env_key 是填 sk- 开头的 Key 吗？
不是。这里填环境变量名称 tokenba_API_KEY，Key 放进实际启动环境。只检查变量是否存在，不打印密钥。
项目 .codex/config.toml 为什么不生效？
当前官方配置参考说明项目级配置不能覆盖 provider 等机器本地字段。将 model_provider 与 model_providers 放入实际用户级配置，并核对 CODEX_HOME 和 profile。
codex features list 成功后就修好了吗？
它说明本地配置可加载。还需要核对 Key、准确模型与 Responses；最后回到实际任务验收工具操作和结果。
能保留 custom 这个 provider 名称吗？
可以。model_provider = "custom" 必须对应 [model_providers.custom]。不要求改成 apizt，要求两处一致。
ChatGPT 订阅能代替 apizt API Key 吗？
自定义网关使用它自己签发的 Key。订阅、厂商 API 和 apizt API 的认证与余额分别管理，不能将网页订阅视为网关额度。
2026 年 11 月 5 日补测
Codex config.toml 报错：比较语法错误、Provider 名不匹配与修复
按 GSC 查询复现自定义 provider 缺失和 TOML 错误，再核对修复后的配置解析。
- 本地 TOML 语法与 Provider 对照（未启动 Codex 会话）。
- 准备独立样例。安装文章所用客户端，或用 Python 3.11+ 运行标注为本地 HTTP/TOML 的样例。
- 本例操作：按 GSC 查询复现自定义 provider 缺失和 TOML 错误，再核对修复后的配置解析。
- 解压练习包，执行 python3 lab.py --output ./result u01。完整命令、样例输入和输出保存在回执。
- 打开 result/u01.json，对照实际退出码、请求路径或产物字段。
- 逐项确认下方通过条件。本例的测试范围以运行回执为准。
- 通过：合法 TOML 仍可含未注册 Provider
- 通过：修复后引用指向实际 Provider
先下载样例，再完成自己的首次调用
示例不含密钥。API 按实际用量计费；下载和点击不代表调用成功。
Codex 专题
真实客户端或本地脚本执行记录；测试响应来自本机样例服务。
实测 cc-switch-official not found 与 provider 名不一致
用用户搜索到的 cc-switch-official 报错做最小复现，确认它发生在任何 API 请求之前。
- 保留现有 TOML 和 profile；在练习包里把 model_provider 指向 cc-switch-official，但只定义 qrfixture。
- 观察错误退出且端点零请求；把选择值改成已定义的 qrfixture，再运行同样一句提示。
- 对照真实配置的 [model_providers.名称]、启用的 profile、当前工具实例。provider 找不到时不要先动 Key。
- 通过：失配 provider 在联网前失败
- 通过：修正指向已定义 provider 后有请求
这个样例只复现启动时缺 provider。若仅在恢复升级前的旧会话时遇到错误，另查 CC Switch v3→v4 会话迁移；不要把本机配置通过当作旧会话已修复。