凭据来源不唯一会让客户端反复刷新

更新于 2026-10-03

**同一份凭据文件里并存两套认证来源时（如 ChatGPT 的 OAuth 登录态 + 第三方工具注入的中转 `OPENAI_API_KEY`），客户端的刷新逻辑会在两套凭据之间互相触发，表现为「一打开就反复刷新」。判据：先看 `auth_mode` 声明的是哪一套，再看文件里实际有哪几套凭据——两者对不上，就是来源不唯一。**

判据：字段声明的和文件里有的对不上

以 Codex 的 ~/.codex/auth.json 为例：

  • auth_mode: "chatgpt" → 声明走 OAuth，靠 tokens.refresh_token 定期刷新；
  • 同一文件里却出现 OPENAI_API_KEY: "sk-..." → 另一套 key 认证。

auth_mode 只声明了一套，文件里实际躺着两套。谁都不确定该用哪个，刷新就会来回打架。

定位动作（按顺序）

  1. 看 auth_mode 声明的是哪一套认证。
  2. 列出文件里实际存在的凭据字段（tokens.* vs *_API_KEY），确认是不是只有一套。
  3. 看 config.toml 期望哪一套：model_provider + base_url + requires_openai_auth 决定客户端打算用登录态还是 key。配置期望 key、auth 里却是登录态（或反之）= 冲突。
  4. 有历史副本时比对 last_refresh 与 token 的 exp：旧副本的 token 已过期却仍被读，是反复刷新的直接线索。

处理：让来源唯一

  • 二选一，不要并存：要么纯登录态（登出后重新登录，清掉被注入的 key），要么纯 key（换成 key 认证的 provider）。
  • key 若曾写进会被外发的文件（聊天/网盘/同步目录），按泄漏处理并轮换。
  • 第三方配置切换工具（如 cc-switch）往 auth 里写过 key 后，即使工具已卸载，残留也不会自动清除。

相关