Antigravity 更新公告里写着“新增 Claude Opus 5.5 / Sonnet 5.5”，我几乎是看到消息就点了升级。版本跑起来之后，客户端倒是正常识别了模型列表，可重启之后登录态直接归零，跳转浏览器、完成授权、回到客户端，界面又停在登录页。反复试了几次，不是“授权成功但客户端不刷新”，就是干脆卡在验证页转圈。

后来我把这个情况丢到群里，发现遇到的人不止我一个，而且大家的卡点不完全一样：有人卡在浏览器授权，有人卡在滑块验证之后，还有人连登录按钮都点不动。结合我自己的排查过程和群里朋友的反馈，基本可以确定：这不是账号被封，也不是密码输错，而是版本更新之后，客户端本地的登录链路里某个环节失效了。

这篇文章把我整个排查过程整理了出来，包括三种典型卡点、一套从低风险到高风险的排查顺序，以及几个平时根本注意不到的细节。如果你现在的状态是“登录不进去、验证过不去、公告说更新了模型但我用不上”，那这篇文章应该能帮你把问题定位到具体环节。

1. 先别急着重装，搞清“卡登录”的三种典型场景

很多人都是一通操作猛如虎，最后直接卸载重装——其实没必要，至少别在没搞清症状之前就重装。因为登录验证这套流程本身是分段的，卡在哪一段，对应的处理方式完全不同。

1.1 症状一：浏览器授权成功，客户端却始终不认账

这是我在群里看到最多的反馈：浏览器里账号密码、二次验证全过了，网页也提示“可以返回应用”，但切回客户端，依然停在登录页。有的客户端还会弹一个“登录失败”或“会话已过期”之类的提示。

这个症状指向的问题通常是客户端本地保存的会话信息和服务端下发的令牌对不上。更新版本时，新版客户端可能更换了令牌的存储位置，或者改变了本地加密算法，导致旧会话变成“半失效”状态。客户端尝试用旧令牌换取新接口的访问权限，被服务端拒绝，于是表现就是“怎么都登不进去”。

处理思路是清理本地会话后再走一次完整登录。清理哪里的数据、怎么清理，我在第二节详细说。

1.2 症状二：验证码或滑块过了，又被退回登录页

这类情况在更新后也常见。你完成了滑块验证，页面短暂跳转，然后又被弹回登录入口，反复循环。

从技术上解释，验证码/滑块只是第一道关卡，真正决定登录成败的是后续的授权回调：浏览器拿到授权码，需要通过本地回调地址（通常是 localhost 上的一个临时端口）交给客户端，客户端再带着授权码去向服务端换令牌。如果这个回调环节中断，服务端会认为授权会话异常终止，自然就把你踢回登录页。

所以别盯着滑块较劲，真正要查的是“授权之后那一跳”到底有没有成功落回客户端。

1.3 症状三：登录按钮点了没反应，一直转圈

还有一部分人更新后打开客户端，界面加载出来了，但点“登录”按钮没有反应，或者点击后一直转圈。

这种情况多半不是登录链路本身的问题，而是客户端根本没建立起和登录服务之间的连接。常见的原因有三个：旧版本的客户端进程还残留在后台，把端口或锁文件占住了；本地安全软件把客户端的出网请求拦了；更新包没解压完整，新版本的登录模块压根没正常工作。

这类问题靠反复点按钮是解决不了的，需要先处理残留进程和更新完整性。

2. 一套稳妥的排查流程：按风险从低到高逐个过

我把排查顺序固定成“账号本体 → 本地会话 → 更新完整性 → 授权回调链路”四步。每一步都不破坏原有环境，越往后动的东西越多、风险越高。建议按顺序来，不要一上来就卸载。

2.1 第一关：确认账号本体的可用性

先说结论：大部分时候账号没问题，但这一步不能跳过，因为它能帮你快速区分是“客户端问题”还是“服务端问题”。

具体做法是：在浏览器里单独打开账号对应的网页登录入口，用同一套账号密码走一次完整登录。如果网页端也登不进去，或者能登进去但提示“账号异常”，那就不是本地客户端的事，直接找官方支持，继续排查本地环境纯属浪费时间。

如果网页端登录完全正常，说明账号和服务端状态都是好的，问题就锁定在客户端本地。同时留意一下邮箱和账号安全中心有没有收到异常登录通知，有的话按提示做一次确认，防止是安全策略把当前设备标记成了高风险。

这一步大概五分钟，能帮后面省下大量时间。

2.2 第二关：清理客户端残留会话与缓存

网页端确认正常后，接下来清理本地会话。这是很多人不敢动的地方，担心删了配置文件丢了项目数据。实际大可不必，登录态缓存和项目数据是两套东西。

具体分三步：

• 第一步，在客户端里如果能找到“退出登录”，先正常退出一次，把当前的会话文件关闭，再重新登录一次试试。有些场景下，退出登录会触发客户端重新获取新会话，问题就自动解决了。
• 第二步，如果退出重登无效，手动清理本地的认证缓存。不同系统的路径不一样，Windows 一般在用户目录下的 AppData 里，macOS 在 Library/Application Support 下，Linux 在 ~/.config 下。找到客户端对应的目录，里面通常有一个类似 auth、session、credential 或 token 的子目录或文件，删除它们。
• 第三步，清理系统凭证管理器里对应的条目。Windows 的“凭据管理器”、macOS 的“钥匙串”里都可能保存了旧版本的授权凭据，这些旧凭据同样会干扰新版客户端的校验。

清理完之后重启客户端，重新登录。这是我实测成功率最高的一步。

2.3 第三关：检查更新是不是卡在半途

清完缓存还不行，就要怀疑更新本身。这类客户端多数采用增量更新，更新包下载中断、解压失败、权限不足，都会导致文件停留在“新旧混合”状态。

判断方法很直接：去安装目录看版本号对应的文件结构是不是完整。比如更新公告说版本号到了新版本，但安装目录里同时存在大量旧版文件，或者某个核心模块目录缺失，基本就是更新中断了。

处理办法是彻底卸载、清理干净安装目录和上文说到的缓存目录，然后重新下载最新完整版安装包，做一次全新安装。

这里有个注意事项：卸载前先把有用的配置文件备份出来，特别是密钥配置、自定义的服务器地址、插件列表这类东西。如果你不记得自己改过什么，就别备份配置文件了，直接全清，避免把损坏的配置又带回去。

2.4 第四关：处理浏览器授权弹窗挂起

前面几步都过了还卡在授权验证，那就是授权回调链路的问题了。这也是最需要耐心的一关。

先检查回调端口。客户端在本地会监听一个临时端口等浏览器跳回，如果这个端口被其他程序占用了，回调就会失败。Windows 下可以用netstat -ano | findstr 端口号查，macOS/Linux 用lsof -i:端口号。看到端口被占用，找到占用进程结束掉，或者换一个时间再试。

再检查浏览器端。第三方浏览器的广告拦截插件、隐私模式、以及“阻止弹窗”设置，都可能导致授权页无法正常完成跳转。建议用系统的默认浏览器、开一个无痕窗口、暂时停用全部插件，再走一次授权流程。

还有一个很隐蔽的点：当你手动把授权链接从弹窗里复制到其他浏览器打开时，回调地址会变成那个浏览器的地址，客户端就收不到授权结果了。所以尽量让授权一直停留在客户端拉起的默认浏览器里完成，不要手动切换。

3. 决定登录成败的几个关键细节

很多人排查一圈没有效果，是因为忽略了一些看似无关紧要的系统级因素。换版本之后登录不了，未必是客户端的问题，也可能是你本机环境在这个时间点上恰好出了状况。

3.1 模型版本切换为什么会触发重新授权

先解释一个很多人困惑的点：我好好地在用客户端，为什么要重新登录？原因在于，切换到 Claude Opus 5.5 / Sonnet 5.5 这类新模型时，平台需要重新校验当前账号是否有对应的访问权限，这个过程会发起一次新的授权请求。

授权请求里包含了新的权限范围，旧令牌里没有声明这个范围，服务端就会拒绝使用旧令牌直接访问新能力，于是强制要求走一次新的登录流程。说得直白一点，更新模型版本和触发登录重新校验，本质上是一回事。所以在更新完看到登录页，先不用怀疑自己是不是被“清退”了，这很可能是正常设计。

理解了这一点，你就知道为什么“退出重登”这种基础操作有时候反而有效——它强制客户端拿到一个包含新权限范围的令牌。也能解释为什么有些人一直停留在旧版本没有这个问题：旧版本没有触发新的授权请求，旧令牌仍然有效。

3.2 本地系统时间漂移：最隐蔽的登录杀手

这个坑我踩过一次之后长记性了。本地系统时间和真实时间偏差过大时，登录认证里的令牌签发时间、有效期校验会全部失准，服务端认为你手里的令牌是伪造的或者已经过期，登录就会被拒绝。

最典型的场景是电脑长期不关机、休眠恢复后时间出现了偏差，或者主板电池没电，每次开机时间都回到以前。这种情况下客户端登录必挂，但错误提示往往只是笼统的“登录失败”或“验证不通过”，很容易让人误判成账号问题。

排查方式也很简单：看系统时间是不是自动同步的。Windows 在“设置—时间与语言—日期和时间”里检查“自动设置时间”，macOS 在“系统设置—通用—日期与时间”里检查。如果时间差超过几分钟，先手动同步，再重启客户端登录。我遇到的那次误差大概在十几分钟，折腾了半天，时间一同步马上就好了。

3.3 安全软件与网络策略对本地回调的影响

第三个容易被忽略的因素是本地安全软件。更新版本后，客户端的可执行文件变化，之前你在杀毒软件里添加的白名单可能失效了，新的版本被当成未知程序拦截。

具体表现有两类：一类是客户端的出网请求被拦，导致登录请求根本发不出去；另一类是客户端在本地监听回调端口时被拦，导致浏览器授权完成后无法把令牌交给客户端。后者的表现和“症状一”高度相似，容易误判成会话缓存问题。

处理方式是把客户端主程序目录加入杀毒软件或防火墙的信任列表，然后重新登录。注意不要关掉系统防火墙去裸奔，只加白名单就够了。如果是在企业办公网络环境下，统一出口策略拦截了本地回环地址，需要找网络管理员申请放行本地到 localhost 的通信。

4. 三个真实排查案例与问题速查表

前面讲的是方法论，这节给几个实际案例，都是我本人或者群友在一线排查时真实遇到的情况，按“症状—排查—结果”的方式还原出来，方便你对号入座。

4.1 案例一：授权页反复横跳，最后是端口被占

有群友反馈：浏览器授权页打开正常，滑块也过了，但页面一直跳回登录入口，偶尔提示“无法完成授权”。前后折腾了快一个小时。

排查时我让他先看本地监听端口的占用情况，一查发现客户端默认回调端口被一个仍在运行的旧版更新进程占住了。旧进程是新版本更新时残留的，一直没退出，把端口死死占着。

处理方式：任务管理器里结束旧版进程，重启客户端，重新登录，一次通过。这个案例告诉我们，更新完之后最好检查一下后台进程列表，如果同时存在两个版本号的客户端进程，一定要把旧的彻底关掉。

4.2 案例二：更新中断导致登录入口彻底失灵

另一个群友更惨，更新完点登录完全没反应，按钮点上去像是被冻结了。日志里记录了“模块加载失败”的报错，指向更新目录下的某个组件。

他的更新包是下载过程中网络中断过、客户端自动续传完成的，表面上看版本号已经变成了新版，实际上部分组件没有写完整。后来让他卸载，手动删除安装目录和 AppData 下的缓存目录，再下载完整安装包重装，登录就恢复了。

这里要强调一个经验：客户端自动更新的可靠性受网络环境影响很大，尤其是增量更新，一旦中断容易出现文件不完整的情况。如果发现更新后行为异常，不要反复“检查更新”，直接全量重装反而更快。

4.3 案例三：时间不对，所有验证都白搭

这个案例就是我自己的。那次也是更新完登录不上，授权流程全程正常，浏览器里显示登录成功，但客户端总是提示令牌无效。我按照第一、第二、第三关全查了一遍，最后无意中看了一眼系统时间，发现比实际时间慢了十几分钟，原因是不久前主板时间被重置过。

我同步时间后重新登录，问题立刻消失。这个经历让我养成了一个习惯：遇到任何和令牌、验证、授权相关的登录问题，先看系统时间，这个排查成本几乎为零，但收益极高。

4.4 常见登录问题速查表

用这张表时守住一个原则：优先选对系统影响最小的操作。先用时间同步、清理缓存这类手段，实在不行才考虑卸载重装，千万别一上来就删文件。

这套流程我后来整理成了自己的固定处理模板，每次遇到客户端升级后登录异常，基本在半小时内就能定位。最后再分享一个预防性小习惯：每次大版本更新前，先看一眼更新公告，把有印象的本地配置备份一份；更新完不要立刻重启进关键工作流，先退出登录重新登一次，确认新版本会话正常再开工。这样就算出问题，也有个明确的回退起点，而不是像我第一次那样，两眼一抹黑地把所有环节都拆一遍。