用 Codex CLI 写代码写到一半，突然弹出 401 Unauthorized，或者一登录就报 Failed to refresh token，连 ChatGPT 账号都进不去——这是 Codex 用户最常撞到的一类故障。它看着像"账号被封"，但绝大多数情况只是本地凭证（token）状态错乱，自己几分钟就能修好，根本不用慌着找人解封。

这篇按你屏幕上看到的具体报错文案分情况讲，每段对应一个真实触发原因和官方解法，文末附一张速查表。先说结论：先看清报错原文，再对号入座，不要一上来就删账号或重装。

先分清：是"登录态坏了"还是"账号真出事了"

动手前先做一个判断，能省掉大量瞎折腾：

• 登录态坏了（绝大多数）：报错里出现 401 Unauthorized、failed to refresh token、refresh token has already been used 这类字样，或者命令行让你"重新登录（sign in again）"。这是本地缓存的 token 失效，重新登录基本就好。
• 账号真出事了（少数）：你打开 chatgpt.com 网页端登录，直接提示账号被停用（Deactivated / Suspended）、被封（Banned），或要求额外验证。这就不是 Codex 的问题，而是账号层面的事，处理路径完全不同（见文末延伸阅读）。

判断方法很简单：先用浏览器登录一次 ChatGPT 官网。能正常进、能正常对话，说明账号没事，问题在 Codex 本地登录态；如果网页端也进不去或被提示异常，那才是账号问题。

报错一：Failed to refresh token / refresh token has already been used

完整报错通常长这样：

Failed to refresh token: 401 Unauthorized: Your refresh token has already been used to generate a new access token. Please try signing in again.

这是目前 Codex 社区里出现频率最高的一类。根据 openai/codex 官方仓库的多个 issue 反馈，触发原因是 OAuth 的刷新 token（refresh token）是"一次性"的：每次用它换新的访问 token（access token）后，旧的刷新 token 就作废了。一旦本地缓存里那个刷新 token 已经被用过、却又被再次拿去刷新，服务端就会判定"这个 token 已经用过了"，返回 401。

什么情况会触发

• 多端同时登录同一个账号：你在台式机、笔记本、或服务器上用同一个 ChatGPT 账号登录 Codex。一端刷新了 token，另一端缓存的旧 token 就失效了。据社区反馈，部分 OAuth 实现会在签发新 token 时让同账号的旧刷新 token 失效，这正是多端冲突的来源。
• 账号迁移 / 换号之后：你换了登录的账号，或账号会员状态变更，本地却还留着旧账号的凭证。
• 升级 Codex 版本后：社区有反馈称某些版本更新后更容易触发，CLI 会忽略本地仍然有效的访问 token、直接拿已经用过的刷新 token 去刷，从而每次请求都 401。

官方推荐解法

据 openai/codex 社区与多篇排查记录，最稳的修复顺序是：

1. 先退出再重新登录。执行 codex logout，再 codex login，按命令行打印的地址在浏览器完成 ChatGPT 授权。重新登录会重建一份全新的、干净的登录态，大部分情况到这一步就好了。
2. 还不行就清掉本地缓存目录再登录。Codex 把登录凭证缓存在本地，Mac / Linux 下清理：rm -rf ~/.codex 以及 rm -rf ~/.config/codex；Windows（PowerShell）：Remove-Item -Recurse -Force "$env:APPDATA\codex"。删完再 codex login 走一遍。
3. 多端用户：固定一台主力机登录。如果你需要在多台设备上用 Codex，尽量不要同时用同一个账号在多端跑会话，避免互相把对方的刷新 token 顶掉。

关于 ~/.codex/auth.json 的安全提醒：Codex 默认把登录凭证以明文存在 ~/.codex/auth.json，里面含访问 token。据 OpenAI 官方开发者文档说明，要把这个文件当密码看待——不要提交到 Git、不要贴进工单、不要发到聊天里。排查时如果有人让你把 auth.json 内容发出来，直接拒绝。

报错二：401 Unauthorized，但你压根没设过 API key

有一类 401 特别坑：你明明是用 ChatGPT 账号登录的，重新登录也没用，反复报 401。这种情况要怀疑 环境变量 OPENAI_API_KEY 抢了权。

据 openai/codex 仓库 issue 反馈，当你的 shell 里设置了 OPENAI_API_KEY 这个环境变量，同时又用 OAuth（ChatGPT 账号）登录了 Codex CLI，Codex 会优先用环境变量里的那个 API key，而不是你刚登录的 OAuth token。如果那个 key 是旧的、已过期、已被吊销，或根本没有对应权限，就会持续报一个"看起来像账号权限问题"的 401，把人带偏。

怎么判断和解决

• 先查环境变量：Mac / Linux 执行 echo $OPENAI_API_KEY，看是否有值（注意：不要把这个值贴给任何人）。
• 临时绕过：用 unset OPENAI_API_KEY && codex 在当前终端临时清掉它再启动。
• 长期解决：据社区给出的做法，可以加一个别名永久绕过，例如 alias codex='unset OPENAI_API_KEY && command codex'；或者干脆从 .zshrc / .bashrc 里把不再需要的 OPENAI_API_KEY 删掉。

报错三：codex login 走完了，却还是登录不上

少数情况下，codex login 提示成功了，但一跑命令还是 401，或者浏览器授权页一直转圈、回调失败。这类通常是本地凭证写入异常或网络环境问题：

• 凭证没写干净：按报错一里的第 2 步，删掉 ~/.codex 和 ~/.config/codex 后重新登录。这是清掉脏状态最彻底的一招。
• 网络 / 出口不稳：Codex 登录走 OAuth，要把浏览器回调和后续 API 请求都打到 OpenAI 服务端。如果你的网络出口不稳定、频繁切换 IP，或登录授权时的出口和实际跑 Codex 时的出口不一致，授权链路就容易断在中途，表现为授权卡住或登录后立刻掉线。用一条稳定、不频繁跳变的网络环境完成登录，能避开一大半这类问题。
• 重试次数打满：有 issue 反馈 CLI 在多次 401 后会触发重试上限直接失败。这种先把上面两步做干净，再重新登录。

速查表：按报错文案对号入座

你看到的报错	最可能的原因	先这样做
refresh token has already been used / Failed to refresh token	刷新 token 一次性、已被用过（多端或换号触发）	codex logout 后 codex login；不行就删 ~/.codex 再登
401 Unauthorized（没设过 API key 也报）	环境变量 OPENAI_API_KEY 抢权	unset OPENAI_API_KEY 后再启动，或删掉该变量
codex login 成功却仍 401 / 授权页转圈	本地凭证脏 / 网络出口不稳	删 ~/.codex 与 ~/.config/codex；用稳定网络重登
网页端登录也进不去、提示账号停用或被封	账号层面问题，非 Codex 故障	走账号申诉路径，别再折腾 CLI（见延伸阅读）

这些"看着像封号"其实不是

很多人一看到 401 就以为账号被封，急着去找各种"解封服务"。先冷静：上面三类报错本质都是本地登录态问题，账号本身好好的，重新登录就解决，跟封号无关。判断标准还是那一条——浏览器能正常登录 ChatGPT 官网就说明账号没事。

只有当你网页端登录都被挡、明确提示账号被停用或受限时，才是账号问题。这种情况下需要注意：平台风控不是任何人能 100% 控制的，任何渠道都不该向你承诺"账号一定能恢复""保证永久不封"；市面上号称花钱就能"解封"的第三方服务也不可信。正规路径是走官方申诉。

账号真出事了，官方申诉怎么走

如果确认是账号层面的问题，据 OpenAI 官方帮助中心说明，正规入口是 help.openai.com：在页面右下角的对话气泡里发起咨询（先和虚拟助手交互），或点 "Submit a request" 提交工单，选对应分类（账号 / 登录 / 计费等），填上你注册时用的登录邮箱、清晰的主题和详细描述。

几个要点：OpenAI 目前不提供电话客服；账号 / 登录类问题通常在 1–3 个工作日内处理；提交时给出登录邮箱和会员档位有助于定位账号，但绝不要在工单里填写密码。另外，被停用（Deactivated / Suspended）类状态通常还有恢复机会，而被彻底终止（Terminated）则基本不可逆——这条边界要心里有数，别被"包恢复"的话术骗。

想少撞这类问题，从账号稳定性入手

Codex 用的就是 ChatGPT 同一套账号会员（Plus、Pro 等档位通用），所以账号本身稳不稳，直接决定你被 401、被掉线打断的频率。要降低撞这类故障的概率，方向是：

• 账号来源和归属清晰。一个干净、归属明确、没在乱七八糟的多端来回横跳的账号，触发刷新 token 冲突的概率天然更低。
• 登录环境稳定。用一条不频繁跳 IP 的稳定网络完成登录和日常使用，能避开很多授权链路断裂导致的登录失败。
• 固定主力设备。重度跑 Codex 时尽量别多台机器同账号并发，减少 token 互顶。

如果你是重度编程用户、对登录稳定性要求高，选账号时可以重点看归属是否清晰、是否方便绑定稳定的使用环境。具体怎么挑、不同档位有什么差别，见下面的延伸阅读。

延伸阅读

Codex 新手上手：从安装到第一次跑通

Codex 和 ChatGPT 会员是同一套账号吗？一篇讲清