Antigravity unexpected issue setting up your account 无法登录

在 Antigravity App、Antigravity IDE 或 agy CLI 里点 Sign in with Google，浏览器显示授权成功，回到应用却弹出 "There was an unexpected issue setting up your account"，说明 Google 账号本身已经登录，失败的是下一步：应用的后台进程拿着授权，自己去连 Google 的 daily-cloudcode-pa.googleapis.com，确认这个账号能不能用 Antigravity。这一步失败只有三类原因：账号不合格或还有待完成的验证；应用自己的网络连接被代理、杀毒软件或防火墙截断；本地残留的旧会话，或者 Google 那边出了故障。

所以先把 App 升级到最新版（截至 2026 年 11 月 5 日为 v2.29.0），2.4.3 以后的版本会在冒号后写出具体原因，按下面的对照表找到它属于哪一类。拿不准时，在终端里用一条 curl 请求 Google 的 loadCodeAssist 端点：一秒左右返回 401 的 JSON，说明网络是通的，问题在账号，去 Google 服务条款页看账号关联的国家，再在 App 的 Settings → Account 里登出、重新登录并点 Verify；返回超时、EOF 或证书错误，才需要改代理和安全软件的设置。

有几种情况重装多少次都没用：账号关联的国家是中国大陆、香港或澳门（都不在官方可用名单里），未满 18 岁，或者用的是管理员没开通 Antigravity 的 Workspace 账号。Google AI 开发者论坛的管理员在 2026 年 11 月 5 日的回复里说得很直接，资格看的是账号关联的国家，不只是网络，挂别国代理改变不了，反而可能让账号违反服务条款。

冒号后面的英文是什么意思：11 种原文对照

Antigravity App 从 2.4.3 版（更新日志日期 2026 年 7 月 28 日）开始，把登录失败的具体原因接在这句提示的冒号后面，IDE 的新版本也会显示；只有一句 "Please try again later." 的，多半是旧版本，先升级再看。下表左列是 Google AI 开发者论坛里用户贴出的原文，网络类的几行同时在一台 Mac 上复现过同一个 Go 网络库的报错，中间一列是它在网络层或账号层的实际含义。

网络类几行的含义有实际复现做依据。2026 年 11 月 5 日，在一台 macOS 26.1 的 Mac 上用 Go 1.25.6 的 net/http 逐一制造故障：服务器不回应并设 5 秒超时，得到 context deadline exceeded；代理变量指向没在运行的端口 127.0.0.1:1，得到 proxyconnect tcp: dial tcp 127.0.0.1:1: connect: connection refused；用不受信任的根证书模拟代理或杀软的 HTTPS 检查，得到 x509: certificate signed by unknown authority；对端读完请求直接关连接，得到 EOF。Antigravity 的后台语言服务也是 Go 程序，日志里能看到 log_context.go，论坛管理员也称它是 Go 应用，所以这些文字在网络层的含义一致。复现的是同一个 Go 库的报错文字，不是 Antigravity 弹窗本身，这台 Mac 当前也没有安装 Antigravity App；context deadline exceeded 和 socket is not connected 在论坛上都还没有确认过的具体原因。

是账号问题还是网络问题：用 curl 测一次 Google 端点

最快的分辨办法，是不带任何凭证去请求一次应用登录时用的端点。网络通的话，Google 会在一秒左右拒绝你，返回 401 和 UNAUTHENTICATED，这时登录失败就和网络无关，该查账号；如果连这一步都超时、EOF 或报证书错误，应用后台也一样到不了 Google。

2026 年 11 月 5 日在同一台 Mac 上，分别经代理和不经代理请求 accounts.google.com 的 OpenID 配置、oauth2.googleapis.com/token、cloudcode-pa.googleapis.com 和 daily-cloudcode-pa.googleapis.com 的 loadCodeAssist，前者返回 200，后三个返回 401，每次 0.3 到 1.0 秒。下面这条 curl 命令当天得到的也是 401。401 只说明请求到了 Google，不说明账号合格。

1. 在 macOS 或 Linux 的终端里运行：

   bash复制

   curl -sS -m 15 -X POST https://daily-cloudcode-pa.googleapis.com/v1internal:loadCodeAssist \
     -o /dev/null -w 'HTTP %{http_code} %{time_total}s\n'

2. 再清掉代理变量运行一次，模拟从 Dock 或开始菜单打开的应用看到的环境：

   bash复制

   env -u HTTPS_PROXY -u https_proxy -u HTTP_PROXY -u http_proxy -u ALL_PROXY -u all_proxy \
     curl -sS -m 15 -X POST https://daily-cloudcode-pa.googleapis.com/v1internal:loadCodeAssist \
     -o /dev/null -w 'HTTP %{http_code} %{time_total}s\n'

   Windows 10 和 11 自带 curl，在 PowerShell 里把 curl 写成 curl.exe，/dev/null 换成 NUL，一行写完即可。

3. 两次都是 HTTP 401：网络没问题，跳到下文的账号验证和地区两节。

4. 第一次 401、第二次超时或报错：终端能通是因为终端里有代理变量，应用从图标启动时拿不到它，看下一节。

5. 两次都超时、EOF 或 x509：本机或网络在拦截，先看下一节的证书、防火墙和 hosts 部分。

开着代理、VPN 或 TUN：让应用的后台进程走同一条路

这一节只适用于账号关联国家在可用名单里，电脑上又装了代理软件、公司代理或带 HTTPS 扫描的杀毒软件的情况。问题出在浏览器和应用走的不是同一条路：浏览器用系统代理或扩展就能打开 Google 完成授权，应用的后台进程（language_server 和 agy）只认环境变量，或者被 TUN 网卡接管的流量。论坛管理员在 Antigravity 登录 EOF 话题的采纳回复里给的原则是：网络必须经代理才能到 Google 时，要么让代理全局生效，例如 TUN 模式，要么设置 HTTPS_PROXY 和 HTTP_PROXY，让后台进程和浏览器走同一条路。

终端里能通不等于应用能通。2026 年 11 月 5 日在那台 Mac 上，终端里设着 HTTPS_PROXY=http://127.0.0.1:17891，launchctl getenv HTTPS_PROXY 却是空的，scutil --proxy 显示系统的 HTTP、HTTPS 和 SOCKS 代理也都关着。从 Dock 打开的应用读的是 launchd 的环境，看不到终端里的变量；这台 Mac 上登录请求能到 Google，只是因为代理软件的 TUN 网卡把所有流量都接管了。

不想开 TUN 时，可以把代理地址直接交给应用。下面的 7890 是 Clash 一类软件常见的 HTTP 端口，以你的代理软件设置里显示的为准；端口写错或代理没在运行，就会得到上表里的 proxyconnect tcp … connection refused。

• macOS 的 App 或 IDE：写进 launchd 的环境，然后用 Cmd+Q 彻底退出应用再从 Dock 打开。重启电脑后失效，不需要时用 launchctl unsetenv HTTPS_PROXY 删掉。

  bash复制

  launchctl setenv HTTPS_PROXY http://127.0.0.1:7890
  launchctl setenv HTTP_PROXY http://127.0.0.1:7890

• agy CLI：在命令前带上变量，HTTPS_PROXY=http://127.0.0.1:7890 HTTP_PROXY=http://127.0.0.1:7890 agy。

• Windows：在命令提示符里先 set HTTP_PROXY=http://127.0.0.1:7890 和 set HTTPS_PROXY=http://127.0.0.1:7890，再在同一个窗口里用 start Antigravity.exe 启动。这是 Antigravity 换取令牌失败的论坛话题里约 5 位用户确认有效的做法。管理员在同一话题里先建议的是清空这两个变量再启动，适合本来不需要代理、却被残留变量带偏的电脑。

开了 TUN 还报 EOF，先看代理软件自己的连接日志。那台 Mac 的代理用的是 fake-IP 模式，cloudcode-pa.googleapis.com、daily-cloudcode-pa.googleapis.com，连根本不存在的 daily-cloudcode-pa.googleapis.invalid 都被解析到 198.18.x.x，而 Go 请求这个不存在的域名时报的是 EOF，不是 no such host。也就是说在 fake-IP 下，代理连不上上游时，应用只会看到连接被关掉，问题在代理节点或规则，不在 Antigravity。没开任何代理也报 EOF，管理员在同一话题里建议先跑 curl -sv https://daily-cloudcode-pa.googleapis.com -o /dev/null，再用 GODEBUG=tlsmlkem=0 agy 启动 CLI 试一次：后者能连上，说明公司防火墙或深度包检测不认新版 Go 的后量子 TLS 握手，这只用来诊断，应该交给网络管理员放行 *.googleapis.com。发帖人最后查出来的就是本地防火墙规则丢弃了到 *.googleapis.com 的 TLS 连接。

报 x509: certificate signed by unknown authority，说明有程序在中间换掉了 Google 的证书。杀毒软件开着 HTTPS 扫描的，关掉扫描或把 Antigravity 加进白名单；公司代理做 HTTPS 检查的，请管理员放行 *.googleapis.com。Windows 上还要查有没有别的工具设置过 SSL_CERT_FILE 或 SSL_CERT_DIR，在 PowerShell 里运行 Get-ChildItem Env:SSL_CERT* 就能看到。论坛管理员在 Antigravity x509 证书报错话题里解释，Go 程序会用这两个变量完全替代 Windows 的系统证书库，可以清掉它们，或者把 SSL_CERT_FILE 指向从 https://pki.goog/roots.pem 下载的 Google 根证书文件，一位遇到同样问题的用户回复已经解决。网上还流传改应用文件、关掉证书校验的做法，这等于让任何中间人都能读到你的登录令牌，不要用。

报 dial tcp 127.0.0.1:443 … refused 时，打开 hosts 文件（macOS 是 /etc/hosts，Windows 是 C:\Windows\System32\drivers\etc\hosts），找有没有把 cloudcode-pa.googleapis.com 或 daily-cloudcode-pa.googleapis.com 指向 127.0.0.1 的行。论坛和 GitHub 上的案例里，这类记录来自第三方"反代"工具，工具一停，应用就连到一个没人监听的本机端口；删掉这些行后，macOS 运行 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder，Windows 运行 ipconfig /flushdns。论坛上一位 Debian 用户这样恢复了。官方 FAQ 另外写明，用第三方软件借 Antigravity 的登录使用服务违反条款，可能导致账号被暂停或终止。

提示 not eligible 或要求验证账号：按顺序完成 Verify

冒号后是 "Your account is not eligible for Gemini Code Assist for individuals at this time"，或者看到 "Verify your account to continue"，多数是 Google 要求这个账号再验证一次，不是套餐出了问题。2026 年 9 月 24 日到 29 日论坛上集中出现了约 20 个这类话题，用户日志显示后端返回的是 403 PERMISSION_DENIED、原因 VALIDATION_REQUIRED，还带着验证链接，只是 IDE 没把链接显示出来。论坛管理员的说法是："This isn't related to your Google AI Pro plan"，Antigravity 每次登录都会重新检查账号，有时即使什么都没变也会要求验证。

还要知道一点：浏览器里那个 "Authentication successful" 页面只代表登录成功，不是验证步骤。管理员在 2026 年 11 月 5 日针对 Windows App 2.29.0 的账号验证话题里给出的顺序如下：

1. 在默认浏览器里退出其他所有 Google 账号，只留要登录 Antigravity 的那个；或者临时把一个只有这个账号的浏览器配置设成默认浏览器。几个账号同时登录时，验证可能落到别的账号上。
2. 在电脑浏览器里打开 Google 账号安全检查页，处理待完成的安全操作；再到 Google 账号年龄验证页确认年龄。
3. 在 Antigravity App 里进入 Settings → Account → Sign Out，重新登录后点 Verify，在浏览器里完成弹出的提示，通常是扫二维码或收短信。
4. 验证完成后等约 15 分钟，再在 App 里登出、登录一次。
5. 用的是 Antigravity IDE 的：先在独立的 Antigravity App 或 agy CLI 里用同一个账号登录，发一条消息触发验证，完成后回到 IDE 用原账号登录。

第 5 步在 9 月的几个话题里是管理员给出的采纳答案，约 28 位用户确认有效；也有约 8 人照做后仍失败，原因是没出现二维码，或者验证短信发不到，提到的有哈萨克斯坦和中国的运营商号码。IDE 不显示验证链接时，论坛上约 5 位用户的做法是从日志里找到 accounts.google.com/signin/continue 开头的链接，复制到浏览器打开，日志位置见下文。

地区不支持、未满 18、Workspace 账号：客户端修不好

Antigravity 官方 FAQ 对个人账号登不上只列了三项检查：账号关联的国家在可用名单里，年满 18 岁，以及它是个人 Google 账号。任何一项不满足，后端都会拒绝，换版本、删文件夹、换浏览器都改变不了结果，这时该停下来，不要继续重装。

截至 2026 年 11 月 5 日，FAQ 的可用国家和地区名单里没有中国大陆、香港、澳门，也没有俄罗斯、白俄罗斯、伊朗和古巴；台湾、日本、韩国、美国等在名单里。账号关联的国家看 Google 服务条款页顶部显示的国家，不是你此刻的 IP。论坛管理员在一位日志显示 "Detected location: CN" 的用户的话题里回复，资格基于账号关联的国家，经日本等地的代理访问改变不了它，用代理绕开地区限制还可能让账号违反服务条款，对名单外地区的账号他们也无法清除这个状态。只有你确实住在名单内的国家、而条款页显示的国家不对时，才用 Google 国家/地区关联更正表申请更正，改好后在 App 的 Settings → Account 里登出再登录。

未满 18 岁时 Antigravity 不可用；已满 18 岁但年龄没验证过的，在上面的年龄验证页完成即可。Workspace、学校或公司账号不算个人 Google 账号，管理员必须在后台为组织显式开通 Antigravity；用 Gemini Enterprise 的要在登录时选 Business account，而且需要许可证。管理员没开通时，也可以改用个人 Google 账号登录，官方 FAQ 写明个人账号在任何套餐下都能用，包括免费层。Google 帮助社区里那个 318 人点了"我也有同样的问题"的帖子，被采纳的是志愿者 Product Expert 的回答：在 Workspace 账号上，这句提示很可能就是资格拦截，只是显示成了"设置问题"。

如果弹出来的不是这句，而是带 #3501 的 "You do not have a valid license of this product"，那是另一条拒绝，原因和处理见 Antigravity 报错 #3501 无法登录：先查地区和账号，别删 .gemini。

Antigravity 是不是挂了：2026 年两次大面积故障怎么认

有可能，但不是常态。2026 年这句提示有两次明显的集中爆发。第一次在 1 月 22 日约 06:45 到 10:30 UTC（北京时间 14:45 到 18:30），大量用户同时看到只有 "Please try again later." 的版本，论坛上约 13 人在 10:11 到 10:55 UTC 之间报告恢复。第二次在 5 月 19 日至 20 日 App 2.0.0 发布时，提示后缀是 "failed to make code assist backend request"，论坛管理员在 5 月 19 日 19:31 UTC 回复问题已经解决。4 月 13 日还有一波类似的集中报告，约 6 人换成手机热点后恢复。

判断是不是服务端故障，看两件事：同一台电脑换一个个人账号是不是也失败，以及论坛里同一个小时内有没有大量同样的新帖。两者都是，就等服务端修复，重装和清缓存只会浪费时间；另一个账号能登录而这个账号不行，问题就在账号本身。1 月那次的论坛主帖标题被改成了 [RESOLVED]，那是发帖人自己改的，没有管理员宣布修复，之后 2 月、4 月 13 日都有人再次遇到，最后一条回复在 7 月 3 日。

要不要删文件夹重装 Antigravity：先升级，再把会话目录改名

先升级，不要先删。Antigravity 更新日志里有几条修复和这句提示的成因直接相关：2.11.0（8 月 26 日）修复了启动时网络短暂中断或 DNS 查询超时导致的永久失败界面；2.16.0（9 月 22 日）修复了浏览器登录中途断开后可能永久失败、被拒的企业凭证一直被缓存；2.27.0（10 月 26 日）修复了启动时一个无效的已保存会话让之后的登录一直失败；2.29.0（11 月 3 日）修复了内置浏览器里 Sign in with Google 的跳转和弹窗失败。没有哪一条写明修好了这句提示本身，但用旧版本排查，等于在跟已经修掉的问题较劲。论坛管理员也提醒过，应用内更新可能失败，这时从官网下载最新版手动覆盖安装。

升级之后，curl 测试通过、账号也确认合格，仍然失败，再重置本地会话。彻底退出 App 和 IDE，把 ~/Library/Application Support/Antigravity 改名为 Antigravity.bak，这是管理员在 EOF 话题里建议的"先备份再移除"，改名可以随时恢复设置，日志也留在里面；CLI 先运行 agy /logout，重启后再登录。Windows 上 Google 帮助社区流传的做法是删除 AppData 下的 Antigravity 文件夹，同样建议改名而不是删除，而且同一帖里有两人回复照做无效。~/.gemini 里放着对话记录，和这次登录失败无关，不要删，原因见 #3501 那篇里关于 .gemini 的一节。

Antigravity 日志在哪看：macOS 路径和要搜的几行

冒号后的原因不够明确，或者 IDE 根本不显示原因时，日志能说明后台到底卡在哪一步。下面的路径来自一台 2025 年 12 月到 2026 年 1 月用过 Antigravity IDE 的 Mac，应用后来卸载了，日志一直留着；2026 年 11 月 5 日在这台 Mac 上重新翻看了这些日志，路径和下文引用的日志行都出自这次查看。

1. 在 Finder 里按 Shift+Cmd+G，输入 ~/Library/Application Support/Antigravity/logs/，进入时间最新的文件夹。

2. IDE 的后台日志在 window1/exthost/google.antigravity/Antigravity.log，主进程日志是同一层的 main.log；App 2.x 的用户在论坛里贴的是 ls-main.log。

3. 在终端里一次搜出关键行：

   bash复制

   grep -rhE "loadCodeAssist|VALIDATION_REQUIRED|Detected location|signin/continue" \
     ~/Library/Application\ Support/Antigravity/logs | tail -n 20

4. 看最后几行冒号后的文字，按上面的对照表归类。

2026 年 11 月 5 日查看时，那台 Mac 的日志里能找到几种真实的失败行，产生时间都在年初。2026 年 1 月 7 日是 Post "https://daily-cloudcode-pa.googleapis.com/v1internal:loadCodeAssist": EOF，1 月 8 日是 dial tcp: lookup daily-cloudcode-pa.googleapis.com: no such host，1 月 11 日和 20 日的 main.log 里是 TypeError: fetch failed … at async GJe.loadCodeAssist，可见应用确认账号状态时请求的正是 loadCodeAssist。还没登录时，日志里会反复出现 Singleflight refresh failed: You are not logged into Antigravity.，这一行是正常的，不代表故障。日志路径和文件名可能随 App 2.x 版本变化，Windows 上的位置也不同。

验证失败或账号被封：去哪里申诉、找谁支持

自己能做的检查做完仍然失败，就该交给 Google，而不是继续换网络、重装。账号因违反服务条款被暂停时，Antigravity 未必直接告诉你，论坛上有 4 例用户在 Antigravity 里只看到 "failed to make code assist backend request"，换到别的客户端才看到 "This service has been disabled in this account for violation of Terms of Service"。新版本在这方面改进了：agy CLI 从 v1.2.14 起在这类登录错误里附上申诉链接，v1.3.1 起验证或申诉链接总会显示；App 2.28.0 起账号错误通知里的申诉链接可以直接点击。看到申诉链接，就按链接提交申诉。

按顺序完成验证后仍然没有二维码、短信收不到，或者网络检查通过、账号合格、同一台电脑上别的账号能登录而这个不行，就到 Google AI 开发者论坛发帖，附上冒号后的原文、App 或 CLI 版本、curl 测试结果和日志里的关键行；也可以通过 Antigravity 官方支持页联系支持。论坛管理员处理过这类个别账号，有的是要求在应用内提交带服务端日志的反馈，有的是私信后在服务端修复。

Antigravity 无法登录的其他问题

一直卡在 Setting up your account 界面、不报错怎么办？

卡住不动，和冒号后出现 context deadline exceeded 属于同一类：应用一直没等到 Google 的回应。旧版本在启动时遇到 DNS 超时会停在失败界面、不再自动重试，这在 2.11.0（2026 年 8 月 26 日）才修复，所以先确认版本，再用上面的 curl 命令分别测一次带代理和不带代理的结果；第二次不通，就是应用没走代理。

浏览器授权后跳转不回应用怎么办？

App 2.29.0（2026 年 11 月 3 日）修复了内置浏览器里 Sign in with Google 跳转和 OAuth 弹窗失败的问题，旧版本先升级。能跳回来但验证总不生效，按上面验证一节的第 1 步处理，默认浏览器里只留这一个 Google 账号。

Antigravity CLI 登录不了，也是这个原因吗？

是同一个后端。agy 和 App 用的是同样的后台连接，论坛上 CLI 1.3.1 也报过 EOF 和 context deadline exceeded，排查方法相同。CLI 独有的一种情况是 macOS 钥匙串锁住、保存不了登录，官方 CLI 排错页给的解锁命令是 security unlock-keychain ~/Library/Keychains/login.keychain-db。如果你用的其实是 Gemini CLI，它的个人 Google 账号登录在 2026 年 6 月 18 日已经停用，见 Gemini CLI 安装教程：全平台 npm 安装，个人 Google 登录已停用。

登录成功了，模型却一直 Retrying 怎么办？

那是登录之后的另一个问题，和账号设置无关，见 Antigravity Argon 一直 Retrying (1/9)：大文件修改被 60 秒截断。