Codex 提示 GPT-5.5 不存在或无权限？404 报错怎么排查

Codex 提示 gpt-5.5 不存在或没有访问权限时，先核对模型 ID、provider 和认证方式是否匹配，再考虑换账号或套餐。ChatGPT 能正常登录，不代表另一个 API key 也有同样的模型权限；渠道的 key 有效，也不代表它接受配置里填写的模型 ID。

本文针对 Codex CLI 中类似下面的报错：

unexpected status 404 Not Found: The model `gpt-5.5` does not exist or you do not have access to it.

报错告诉你请求了哪个模型，没有直接说明原因，也不能据此判断 GPT-5.5 已下线。以下步骤依据 2026 年 9 月 8 日核查的 Codex 官方配置与认证文档整理，不代表所有账号或渠道都能调用 GPT-5.5。

先查请求走哪条路，不急着重装

在发生报错的同一个终端里运行：

codex --version
codex login status
codex --help

记下版本和认证方式，同时记录启动目录、是否用了 --model、--profile 或 -c 参数，以及会话是不是从 IDE 启动的。不要分享 API key、访问令牌或 auth.json 的内容。

codex login status 用来检查认证状态，不能单独说明自定义 provider 最终使用了哪个接口。需要和 provider 配置一起看。

OpenAI 官方将 ChatGPT 订阅访问与 API key 按量访问分开说明。后续排查也要沿着各自的方式进行。

找到真正生效的配置

一种容易漏掉的情况：你改了用户配置，启动命令却还在指定另一个模型。在本机检查相关配置文件，记录这些字段即可：

model
model_provider
openai_base_url
model_providers.<provider>.base_url
model_providers.<provider>.env_key
model_providers.<provider>.requires_openai_auth

当前官方基础配置文档列出的优先级，从高到低为：

1. 命令行参数和 --config 覆盖项。
2. 已信任项目的配置，越靠近当前工作目录的文件越优先。
3. 通过 --profile 选中的 profile 文件。
4. 用户配置 ~/.codex/config.toml。
5. 系统配置，最后是内置默认值。

这里还有一项限制：高级配置文档说明，当前项目级配置会忽略 model_provider、model_providers、openai_base_url 等 provider 相关字段，并在启动时发出警告。这些配置应放在用户级文件中。项目配置仍可覆盖允许的字段，例如模型，因此只检查一个文件可能发现不了两者不匹配。

当前文档中的 profile 文件路径是 ~/.codex/profile-name.config.toml。旧教程可能使用另一种组织方式，照抄前应先确认适用于你安装的版本。

按你想用的方式修正

原本想通过 ChatGPT 登录

确认账号和工作区，然后选择当前会话实际提供的模型。如果启动命令或配置仍固定了旧模型，应修改产生该覆盖项的位置。模型列表没有提供的模型，不会因为手动填入 gpt-5.5 就获得访问权限。

只有账号不对或认证确实失败时，才需要重新登录。模型查找失败不意味着必须先重装 Codex 或删除凭据。

原本想使用 OpenAI API key

确认请求指向预期的 OpenAI 接口，使用的是正确的 API 账号和项目，再对照该账号当前可用的模型 ID。尤其要检查 openai_base_url 是否还保留着旧代理地址，避免把代理返回的错误当成 OpenAI 的响应。

API 权限和费用与 ChatGPT 套餐内额度分开。同一个 key 能调用另一个模型，有助于判断连接情况，但不能证明它有 GPT-5.5 权限。

原本想使用第三方渠道

渠道 URL、模型 ID 和 key 必须配套。某些渠道会给模型 ID 加命名空间前缀，应以渠道文档为准，不要凭经验随意增删。

下面是配置模板，其中的地址不是可直接使用的服务，也不表示渠道已经提供 GPT-5.5。请把模型和地址两个占位值替换为渠道提供的值，放进用户级配置，并与已有段落合并，避免重复定义：

model = "REPLACE_WITH_PROVIDER_MODEL_ID"
model_provider = "diagnostic_provider"

[model_providers.diagnostic_provider]
name = "My provider"
base_url = "https://api.example.com/v1"
env_key = "PROVIDER_API_KEY"
wire_api = "responses"
requires_openai_auth = false

当前 Codex 的 wire_api 只支持 responses，因此渠道需要支持对应的 Responses API。只提供 Chat Completions 的渠道无法使用这份配置。通过你平时的本地密钥管理方式设置 PROVIDER_API_KEY，不要把密钥写进共享 TOML 文件。

还要检查已有配置是否把 requires_openai_auth 设成了 true：官方文档说明，这时会使用 OpenAI 认证并忽略 env_key。它的默认值是 false，模板中仍明确写出，确保使用这里的第三方 key 认证方式。

修改前保存一份受影响的配置，保留其他设置。修改后从同一目录启动新会话，用一个不要求修改文件的小请求验证；API 调用可能产生费用。如果改动破坏了原本正常的连接，恢复保存的配置。

需要完整接入说明时，可以参考 Codex 自定义 provider 教程（英文）。如果使用 Ofox，先在当前模型目录确认准确 ID 和支持的接入方式。

看下一条响应，缩小排查范围

若要用直接 API 请求与 Codex 对照，两边必须使用相同的主机、key、模型和 Responses 接口。另一个主机上的 Chat Completions 请求成功，不能用来定位 Codex 的问题。同一连接方式直接调用成功，可以把注意力转向 Codex 配置或请求差异，但还不能证明究竟是哪一项导致报错。

本地 model metadata ... not found 警告也与 HTTP 404 不同。应记录最后的服务端响应，不要默认两条消息有相同原因。非 Codex 的 SDK 和 Azure 场景，可查看通用 OpenAI 模型不存在排查（英文）。

仍未解决时，提供哪些信息

整理一份脱敏信息：Codex 版本、操作系统、认证类型、选中的模型和 provider、接口主机和路径、启动目录情况、相关启动警告、最后的完整报错。如果渠道返回 request ID，也一起提供。不要包含密钥或私人提示词。

这些信息能帮助支持人员区分账号可用性、旧配置覆盖和渠道不匹配。一次只调整一个相关因素，才能保留判断依据；同时更换账号、模型和接口，反而更难确认原因。

参考来源

• OpenAI Codex 认证
• OpenAI Codex 基础配置
• OpenAI Codex 高级配置
• OpenAI Codex 配置参考
• OpenAI Codex CLI 参考