Codex CLI 认证：ChatGPT 登录、API Key 与兼容网关

ChatGPT 登录、OpenAI API Key 和兼容网关 Key 是不同的凭据来源。model_provider 与 base_url 决定请求目标，认证配置只提供该目标要求的凭据。

API Key 登录不自动获得 ChatGPT 订阅能力，兼容网关配置也不应被描述为 OpenAI 官方账号登录。CodeNodex 使用自己的 Key 和 OpenAI Responses 兼容端点。

直接运行 codex 并选择 Sign in with ChatGPT，是官方文档推荐给支持计划用户的路径。登录后用 status 检查当前状态，不要通过读取凭据文件判断是否有效。

共享服务器不适合让多人共用一个用户主目录和登录状态；应为每个用户隔离系统账号或使用组织认可的 API 凭据流程。

官方 CLI 支持从标准输入读取 OPENAI_API_KEY。把密钥放入当前进程环境，并通过 printenv 管道传入，能够避免它作为命令参数留在 shell 历史中。

环境变量仍可能被同一用户的其他进程或调试工具看到。使用后应 unset，并遵循操作系统与团队的 Secret 管理要求。

CodeNodex CLI 将 OPENAI_API_KEY 写入用户目录下的 Codex 认证文件，并把 provider 配置合并到 config.toml。它会先验证 Key，再备份和写入，避免手工编辑两个文件产生不一致。

登录 CodeNodex 账号与 Codex 的 ChatGPT 登录互不等价。使用 CodeNodex provider 时，应以 CodeNodex CLI 的验证结果和 Codex doctor 为准。

认证文件应位于用户主目录，不要复制到项目、镜像或制品。排查问题时不要直接粘贴 auth.json；优先分享 doctor 的脱敏报告与不含凭据的 provider 片段。

轮换密钥时先创建新 Key、完成验证，再撤销旧 Key。这样能够减少切换期间的不可用窗口，也方便确认错误来自新配置还是服务状态。

先检查请求目标，再检查凭据来源，最后检查 Key 状态。provider 指向 CodeNodex 却使用 OpenAI Key，或 provider 指向官方端点却只配置 CodeNodex Key，都会表现为认证失败。

不要反复覆盖配置。保存诊断结果和当前 provider 名称，确认 base_url 后再重新登录或运行 setup。