Antigravity の Google サインインが認証画面から戻らないときの原因と対処

Antigravity を新しいマシンに入れた直後や、Google アカウントを切り替えたあとに、「Sign in with Google」を押す → ブラウザでアカウント選択が出る → 同意した瞬間にブラウザ側もエディタ側も無反応、という状態に陥ることがあります。私自身、2014年から続けている個人開発のアプリ群（Dolice 名義の壁紙・癒し系アプリで AdMob による広告収益を回しています）では複数の Google アカウントを使い分けているため、サブ機にセットアップするたびに何回かこの症状で足止めされてきました。

困るのは、エラーメッセージらしいエラーメッセージが出ないことです。ブラウザのタブは「読み込み中」のまま静止し、エディタの右下には「Waiting for sign-in...」のローダーがゆっくり回り続けます。原因は1つではなく、ローカルのコールバックポート・ブラウザのプライバシー設定・古いセッションキャッシュ・ネットワーク経路のいずれか（または複数）が同時に絡んでいます。順番に切り分けていけば、ほとんどのケースで数分以内に復帰できます。

どの段階で止まっているのかを最初に切り分ける

サインインのフローは大きく3段階に分けて考えます。(A) Antigravity がブラウザを起動して Google のページを開く段階、(B) ユーザーが同意したあとブラウザがローカルのコールバック URL（http://127.0.0.1:54321/callback のようなループバックアドレス）に戻る段階、(C) Antigravity 本体がコールバックを受け取り「Signed in」と判定する段階です。

トラブルのほとんどは (B) と (C) で起きます。(A) で止まる場合は単純にプロキシや DNS の問題なので別の対処になります。判別のために、Antigravity を起動した状態でターミナルから次のコマンドを実行してみてください。macOS と Linux なら、

lsof -nP -iTCP -sTCP:LISTEN | grep -i antigravity

Windows（PowerShell）なら、

Get-NetTCPConnection -State Listen | Where-Object OwningProcess -in (Get-Process antigravity).Id

このどちらかで 127.0.0.1:54321 付近の番号が listening 状態になっていれば、エディタはコールバックを待ち受けている状態だとわかります。listening していないのに「Waiting for sign-in...」が出ているなら (C) 側、つまりエディタ内部のサインインモジュールが壊れているケースを疑います。

ローカルコールバックポートが奪われているケース

Antigravity は OAuth コールバック用にループバックポートを開きます。バージョンによりますが、私が触ってきた範囲では 54321 から 54328 あたりの番号を順に試す挙動です。Docker Desktop、別の Electron アプリ、ローカルで起動しっぱなしの Next.js dev サーバなどがこのレンジを先に押さえていると、コールバックの取り合いになって戻れません。

最短の確認手順は次のとおりです。

# macOS / Linux
for port in 54321 54322 54323 54324 54325; do
  lsof -nP -iTCP:${port} -sTCP:LISTEN 2>/dev/null \
    | awk 'NR>1 {print $1, $2, $9}'
done

ここで Antigravity 以外のプロセスが出てきたら、それが原因です。Docker のヘルスチェック用エンドポイントや、過去に kill しきれなかった next dev の幽霊プロセスが残っているパターンを何度か踏みました。kill -9 <PID> で落としたあと Antigravity をいったん終了し、再起動してからもう一度サインインを試します。

ポートを動的に拒否しているのが企業 PC の場合は、IT 管理者に「54321〜54328 番のローカルバインドを許可してほしい」とお願いするのが正攻法です。会社の WAF/EDR が「未承認のリスナー」と判断して即座にプロセスを kill していたケースもありました。

サードパーティ Cookie とブラウザ拡張の割り込みを外す

意外な伏兵がブラウザ側です。Safari の「サイト越えトラッキングを防ぐ」、Brave の「Shields」、Firefox の「強化型トラッキング防止」が有効だと、accounts.google.com → ループバック URL へのリダイレクトが Cookie 同伴で通らず、Google 側のセッションが切れた状態でローカルに戻ってきます。結果、Antigravity は「ユーザー情報が空のコールバック」を受け取って判定に失敗します。

切り分けの定番は、ブラウザの シークレットウィンドウ / プライベートウィンドウで認証をやり直す ことです。シークレットウィンドウでは拡張機能が原則オフになるため、1Password、Bitwarden、uBlock Origin、Cookie 自動削除系の拡張機能がフローを横取りしている可能性を一度に潰せます。サインインだけシークレットで通し、そのあと普段使いのウィンドウに戻る運用で問題ないので、まずここを試すと早いです。

それでもダメなら、accounts.google.com と 127.0.0.1 をブラウザの「サードパーティ Cookie を許可するサイト」に追加します。Chrome の場合は chrome://settings/cookies から例外を追加できます。サードパーティ Cookie をブロックしたまま OAuth を通す方法はもう用意されていない、と割り切るのが現実的です。

古いセッションファイルを掃除する

サインインに一度成功したあと、トークンが壊れた状態のまま再ログインを試すと「読み込み中」のままになる、というケースがあります。Antigravity は内部に Chromium のセッションプロファイルを抱えているため、Cookies/Local Storage/IndexedDB のどれかが破損するとログインフローが進めません。

各 OS でのプロファイルパスは次の場所です。

macOS:   ~/Library/Application Support/Antigravity/
Windows: %APPDATA%\Antigravity\
Linux:   ~/.config/Antigravity/

この配下の Network/Cookies・Local Storage/・Session Storage/・IndexedDB/ を削除する前に、Antigravity を完全終了させておいてください（macOS なら killall Antigravity で念入りに）。終了せずに消すと再生成のタイミングで別の壊れ方をします。

私が最終的に落ち着いた手順は、サインインに使うサブアカウント切り替え時だけ Network フォルダ配下のみリネームしてバックアップする方法です。具体的には、

# macOS の例。Windows / Linux は前述のパスに置き換え
APP_SUPPORT="$HOME/Library/Application Support/Antigravity"
mv "$APP_SUPPORT/Network" "$APP_SUPPORT/Network.bak.$(date +%Y%m%d%H%M)"

としてフォルダごと退避します。これでサインインフローが「初めて起動した状態」とほぼ同等になりつつ、エディタ設定や拡張機能のキャッシュは残るので、復旧コストが小さくて済みます。

VPN・プロキシ・ファイアウォールが経路を断っているケース

会社支給のマシンや、VPN を常時オンにしている開発環境では、accounts.google.com の証明書チェック（OCSP）やトークンエンドポイント oauth2.googleapis.com への接続が遅延・遮断されることがあります。アクセスログを見ない限り「通っているはず」と思い込みやすい部分です。

切り分けの最短ルートは、いったん VPN をオフにし、自宅回線や個人スマホのテザリングからサインインを試すことです。それで通るなら確定で経路問題、通らないならローカル側の問題です。VPN がどうしても外せない環境では、最低限 *.google.com・*.googleapis.com・127.0.0.1 を split tunnel で除外する設定を IT に依頼します。

macOS の場合はもう1つ落とし穴があります。アプリケーションファイアウォール（システム設定 → ネットワーク → ファイアウォール）が有効で、かつ「ステルスモード」が有効だと、ローカル 127.0.0.1 へのコールバックが届かない事例を経験しました。ステルスモードを一時的にオフにすると復帰します。原因がここだと気づくのに半日かかった経験があるので、企業 PC ではここも候補に入れておくと早いです。

再発を防ぐためのセットアップチェックリスト

ここまでの切り分けをふまえて、私がサブ機の初期セットアップ時に走らせている「サインインで詰まらないためのチェック」を共有します。

Docker Desktop と next dev を Antigravity 起動前にいったん停止しておく
ブラウザのプライバシー設定でサードパーティ Cookie を accounts.google.com 向けに例外許可しておく
1Password / Bitwarden のオートフィルを「サインインボタンを押すまで起動しない」に設定しておく
企業 PC では 127.0.0.1 ループバックと *.google.com を VPN の split tunnel に登録しておく
macOS のファイアウォールで Antigravity に明示的に「アウトバウンド許可」を与えておく

このチェックリストを通しておくと、サインイン関連の戻りが90秒以内に収束する確率が体感で大きく上がります。Antigravity 自体は安定してきたぶん、周辺環境（ブラウザ・VPN・ファイアウォール）の組み合わせのほうがトラブルの主役になりやすいので、最初の1回だけ丁寧に環境を揃えておくと、その後の開発速度がずいぶん変わります。

同じ症状に詰まっている方の参考になれば幸いです。お読みいただきありがとうございました。