Codex API 配置自检：Provider、Base URL 与 Responses 怎么确认

当你已经有一个自定义 Provider 或服务入口，却发现 Codex 连不上、返回格式不对或报错难以判断时，问题通常不在“再复制一遍配置”。这篇只处理实际连接自检：当前客户端读到了哪个 Provider、Base URL 和协议，以及有效凭据是否只留在本机受控位置。关于 config.toml 的用户级、项目级作用域和覆盖顺序，请先阅读 Codex config.toml 配置指南。

先确认当前客户端正在使用哪个 Provider

记录 codex --version 和实际启动方式，再检查客户端显示或日志中已脱敏的 Provider 名称、Base URL 与协议。Provider 名称只是本地识别标签，不是模型名称；若同一台机器存在多份配置，先确认当前进程到底读到哪一份，不要同时改多个文件。

连接自检只看四个字段

1. Provider：确认它对应当前想使用的服务入口，而不是遗留的本地标签。
2. Base URL：Shana 的服务入口为 https://shana.baby/v1。字段是否要求保留 /v1，以当前客户端说明为准。
3. 协议：Codex 当前按 Responses 形态工作。协议边界不清楚时，查看 Responses API 与 Chat Completions 的区别，不要把端点路径手工叠加进地址。
4. API Key：用已授权的有效凭据完成验证，但只通过环境变量、系统凭据或客户端私有配置提供；网页、截图、仓库和日志只保留占位符或脱敏结果。

按一次连接验证定位问题

1. 只输出脱敏后的 Provider 和 Base URL，确认当前值而非模板值。
2. 在本地受控配置中保留有效 Key，发起一个不含业务资料或个人信息的短请求。
3. 检查客户端是否按预期协议解析响应，不把完整请求头或 Key 写入终端记录。
4. 若失败，只保留状态码和已脱敏报错；按 状态码排错指南判断是鉴权、权限、限流还是上游错误。

什么时候应回到配置文件检查

如果同一 Provider 在不同工作目录表现不一致，或重启后配置回退，再回到 Codex 配置参考和 config.toml 作用域说明排查覆盖关系。连接参数确认后，再核对 Shana Codex 接入说明中的实时服务信息；本站不会收集、保存或代发你的 API Key。

相关：Claude Code 侧或其他中转的通用接入步骤，见 Shana KB 通用接入指南。