客户端被踢出后无法重新登录、网页提示 Sign-in could not be completed，是服务端故障、出口 IP 校验和本地凭据缓存损坏三类原因交织的结果。本文把排查顺序理清：先确认官方状态，再验证网络出口是否稳定，最后处理本地凭据与 OAuth 回调，并给出可复用的命令与检查清单。
使用 OpenAI 桌面客户端或命令行工具时，偶尔会遇到这样一种状态：正在用着，客户端突然被踢回登录页；重新登录时浏览器里跳出 Sign-in could not be completed，网页端也进不去。既不像密码错误，也不像账号被封，重试几次依旧原地打转。
这类故障的麻烦之处在于，同一个报错背后可能对应完全不同的原因：有时是服务端短时故障，等一会儿自己就好了；有时是登录流程中的网络出口被判定异常；还有时是本地保存的登录凭据已经损坏，无论怎么点登录都会失败。本文按"先排除外部、再处理本地"的顺序把排查路径理一遍，并说明各种做法适用于什么场景。
第一步：先确认是不是服务端的问题
在动本地任何配置之前，先花一分钟确认平台自身是否正常。官方状态页会列出各服务的运行状态与历史事故，出现大面积故障时通常会有记录。
判断依据可以看这几点：
- 状态页上有正在进行的事故（Incident），且时间与你的故障时间吻合；
- 多个互不相干的账号在同一时间段出现相同症状；
- 换个网络、换台设备、换浏览器，现象完全一致。
如果符合上述特征，最合理的做法是等待，而不是反复清缓存、重装客户端。此时任何本地操作都不会有帮助，反而可能把原本正常的登录状态弄丢。
反过来，如果状态页一切正常，身边其他人也能正常登录，那问题大概率出在本地到服务端这一段链路上——继续往下看。
常见原因拆解
服务端短时故障或灰度发布
登录服务、鉴权服务与模型服务是相互独立的部分，登录接口出问题不代表模型不可用，反之亦然。表现是"能进去的人一直能进，进不去的人怎么都进不去"。这类情况通常以小时计恢复，没有可操作的本地解法。
出口 IP 变化触发登录校验
这是最容易被误判为"账号出问题"的一类。完整的登录流程是：客户端唤起浏览器 → 在浏览器完成身份验证 → 携带回调跳回客户端换取令牌。如果这两步走了不同的网络出口（比如浏览器走了代理、客户端直连，或者中途节点切换），服务端会看到两个地理位置相距甚远的请求，风控系统就可能中断这次登录，前端只呈现一句笼统的失败提示。
典型特征是：网页端单独能登，但"从网页跳回客户端"这一步必失败；或者同一台机器上换一个网络环境立刻就好。
需要强调的是，这里涉及的是账号安全策略。频繁切换出口、多地区同时登录、使用来路不明的共享账号，都可能触发更严格的验证甚至临时限制，风险由使用者自己承担。稳妥的做法是让整条链路使用同一个稳定、合规的出口——例如公司专线、固定的家庭宽带，或者一台位置固定的远程主机。关于账号的合规使用边界，请以官方服务条款的最新说明为准。
本地凭据缓存损坏
如果错误发生在"点击登录"之前，或者点击后瞬间就报错，甚至根本没弹出浏览器，那更可能是本地保存的凭据文件已经失效。令牌过期、上次登录被中断、磁盘写入异常，都会留下一个半损坏的状态文件，客户端读到它就直接判定登录失败。
命令行工具通常把凭据放在用户目录下的隐藏文件中；图形界面的桌面客户端则放在系统的应用数据目录里，具体位置随版本变化，需要自己确认。
OAuth 回调被拦截
回调依赖浏览器把控制权交还给客户端，这一步会被以下因素打断：
- 默认浏览器被换成了屏蔽重定向的浏览器或隐私模式；
- 广告拦截、隐私保护类扩展拦截了跳转；
- 系统里存在多个浏览器，登录在一个浏览器完成，回调却指向另一个；
- 企业网络或安全软件拦截了本机回环地址上的回调请求。
系统时间偏差过大
令牌签发与校验依赖时间戳。系统时间与标准时间相差过多时，签名校验会失败，表现同样是登录不成功。开启自动同步时间即可排除。
可执行的排查清单
按顺序做，每一步之后重试一次登录，避免同时改动多个变量导致无法判断是哪一步生效的。
| 顺序 | 操作 | 观察点 |
|---|---|---|
| 1 | 查看官方状态页 | 是否有正在进行的事故 |
| 2 | 完全退出客户端后重开 | 是否仍停在登录页 |
| 3 | 用浏览器无痕窗口登录网页版 | 网页端能否进入 |
| 4 | 让浏览器与客户端走同一出口 | 从网页跳回客户端是否成功 |
| 5 | 清理客户端凭据文件 | 是否能重新走完整登录流程 |
| 6 | 检查系统时间同步 | 时间偏差是否在秒级 |
| 7 | 卸载重装客户端 | 是否为版本自身的缺陷 |
关于删除凭据文件
删除本地凭据是社区里流传最广、也最容易见效的一招，但有几个前提必须先说清楚：
- 先退出客户端，包括托盘图标和后台进程，否则文件会被重写；
- 先备份再删除，否则一旦不是这个原因，你还得重新配置；
- 删除后必须能完整走通一次浏览器登录，否则问题不在凭据文件；
- 只对把凭据存放在该路径的工具生效，不要照搬到其他客户端。
以常见的命令行工具为例：
# 先确认客户端进程已退出
# 备份
cp ~/.codex/auth.json ~/.codex/auth.json.bak
# 删除后重新执行登录命令
rm ~/.codex/auth.json
Windows 下对应路径在用户目录中，形如 %USERPROFILE%\.codex\auth.json。操作前先把该目录整体复制一份更保险。
图形客户端的数据目录因版本而异，建议先在应用设置里找"退出登录"，效果等同且更安全；只有退出登录也无效时，再去手动清理数据目录。
观点分歧：个例还是普遍
围绕这个报错，常见的分歧有两类，其实并不矛盾，只是描述的是不同层面的现象。
"我这边正常"与"我完全登不上"并存。 这通常说明不是全局故障，而是与账号、网络出口或客户端状态相关的局部问题。看到别人说"未复现"不必怀疑自己，因为触发条件本来就不一样。
"换网络就好"与"删文件就好"。 前者解决问题发生在登录链路层，后者解决的是本地状态不一致。判断方法很简单：如果报错出现在浏览器页面跳转阶段（能看到浏览器窗口，随后失败），优先查网络出口；如果根本唤不起浏览器，或者一点登录就秒失败，优先查本地凭据。
还有一类反馈是登录成功后提示"部分功能不可用"。这可能是账号本身的套餐与权限范围、地区可用性差异，也可能是请求链路不稳导致的临时降级，需要结合官方文档核对，不能一概归因于网络。
如果问题与本地环境长期纠缠
有些人的场景是：本地网络需要频繁切换，或者机器经常休眠、断网，导致长连接的登录状态反复失效。如果只是偶尔发生，按上面的清单处理即可；如果是常态化困扰，可以考虑把需要长时间在线的任务放到一台位置固定、网络环境稳定的远程主机上运行，本地只做连接和编辑。这类方案适合长期挂着命令行 AI 工具跑任务的用法，成本与适用性需要自己评估，不是所有场景都值得。
注意事项
- 不要购买、租用或与他人共享账号，这类账号随时可能被限制，且出问题时无法申诉；
- 不要为了登录去尝试来路不明的"解锁"脚本或第三方登录代理，凭据泄露的代价远高于一次登录失败；
- 排查时一次只改一个变量，改完记录结果，否则会陷入"好像好了又好像没好"的循环；
- 涉及账号安全策略、可用地区与套餐权限的内容变化较快，请以官方最新说明为准。
小结
Sign-in could not be completed 是一个笼统的前端提示，本身不指向具体原因。合理的排查顺序是：先看官方状态页确认是否服务端故障，再用无痕窗口和统一网络出口验证登录链路，最后处理本地凭据文件与 OAuth 回调。多数情况下，问题会落在这三步中的某一步，而不是账号本身出了问题。