Antigravity の内蔵ターミナルが起動しない・コマンドが通らないときの診断ガイド

Antigravity を使っていて一番困るのが、内蔵ターミナルが沈黙する瞬間ではないでしょうか。エージェントが npm install を走らせようとしているのに、ターミナルパネルが開かありません。あるいは開いているのに、node -v を叩いても応答がありません。私自身、Next.js 16 のプロジェクトを Antigravity で立ち上げた初日にこの症状に遭遇し、原因の特定に 2 時間溶かしました。

この問題の厄介なところは、症状が似ていても原因がまったく違うことです。「起動しない」と「起動はするが反応しない」と「コマンドが通らない」は、対処すべきレイヤーが別物です。ここでは私が現場で試行錯誤して整理した三層の診断フローを共有します。再起動で直ってしまう運の良いケースから、$PATH を根本から見直すケースまで、段階的に絞り込めるようにしました。

まず症状を三つのパターンに分類する

トラブルシューティングは、症状の取り違えで迷宮入りします。最初の 30 秒で、自分がどの層の問題を抱えているかを見極めるのが近道です。

パターン A — ターミナルパネル自体が開かない: Ctrl+ バッククォートを押しても、メニューから「New Terminal」を選んでも、パネルが現れません。もしくは一瞬現れて即座に閉じます。これは Antigravity のフロントエンド（Electron レンダラー）の問題か、ptyHost プロセスの起動失敗です。
パターン B — パネルは開くがプロンプトが出ない: ターミナルパネルは表示されるものの、シェルのプロンプト（$ や %）が現れず、カーソルだけが点滅しています。これはシェルプロセスの起動には成功したが、ログインプロファイル読み込みでスタックしている状態です。
パターン C — プロンプトは出るがコマンドが見つからない: node: command not found や git: command not found が出ます。シェル自体は動いていますが、環境変数（特に $PATH）が期待通りに伝わっていません。

この三つを混同したまま手を動かすと、効かない対処を延々と繰り返すことになります。パターンを特定したら、該当するセクションだけ読めば十分です。

パターン A：ターミナルが開かない場合の復旧手順

ターミナルパネル自体が開かないときは、まず Antigravity の開発者ツールを開いてログを見るのが最速です。Help → Toggle Developer Tools から Console タブを開き、赤字のエラーを探します。

よく出るのは Unable to start pty host process や spawn /bin/bash ENOENT といったメッセージです。これは、OS 側で期待されているシェルのパスが Antigravity の設定と一致していないときに発生します。

対処の優先順は次の通りです。

Antigravity を完全に終了して再起動する: ウィンドウを閉じるだけでは ptyHost プロセスが残っていることがあります。macOS なら Cmd+Q、Windows ならタスクマネージャで antigravity.exe が残っていないか確認して終了させます。
ユーザー設定のシェルパスを削除する: settings.json に "terminal.integrated.defaultProfile.osx" などの指定があれば、一度削除してデフォルトに戻します。プロファイルの互換性が壊れているケースが意外に多いです。
OS のシェルが実在するか確認する: ターミナルは OS のシェル実行ファイルを起動しているだけです。ls -la /bin/zsh /bin/bash /opt/homebrew/bin/fish のようにエクスプローラまたは別のターミナルで存在確認します。Homebrew でシェルを入れ直したときはパスが /opt/homebrew/bin/ に変わっているので、古い /usr/local/bin/ を指定していると ENOENT になります。
最終手段として拡張機能をセーフモードで起動: コマンドパレットから Developer: Reload With Extensions Disabled を実行します。ターミナル周りに手を入れる拡張機能（例：ShellLauncher 系、Remote Development 拡張）が原因ということもあります。

私の経験上、ここまでで 8 割の「開かない」問題は解消します。残りの 2 割は OS 側のシェル更新に Antigravity が追随できていないケースで、次のパターン B の手順と合わせて対処することになります。

パターン B：パネルは開くがプロンプトが出ない場合

パネルは表示されるのに反応がない状態は、シェルのログインプロファイルが無限ループしている、もしくは外部コマンドを待機したまま固まっているケースがほとんどです。

最初に疑うべきは ~/.zshrc や ~/.bashrc の中身です。具体的には、起動時に外部 API を叩いて応答待ちになる処理（例：nvm use default、pyenv init -、独自の環境変数取得スクリプト）です。ネットワークが不安定な状態でこれらが呼ばれると、30 秒以上応答が返らないことがあります。

ログインプロファイルの健康診断

以下のワンライナーを別のターミナル（OS 標準のターミナルアプリ）で実行すると、どの処理に時間がかかっているかを可視化できます。

# 目的: zsh 起動時に時間を食っている処理を特定する
# 実行前提: zsh が既定シェル、~/.zshrc が存在する
zsh -xvs 2>&1 | ts '[%H:%M:%.S]' | head -100

ts がない環境では brew install moreutils で導入してください。出力のタイムスタンプが数秒以上空いている行が犯人候補です。ほとんどの場合 nvm.sh の読み込みか、rbenv init あたりがボトルネックになっています。

対症療法と根本対応

急場しのぎでよければ、Antigravity の設定で "terminal.integrated.profiles.osx" に "args": ["-l", "-i", "--no-rcs"] を追加し、プロファイル読み込みをスキップしたシェルを起動できます。ただしこれだと PATH が引き継がれないので、あくまで一時的な逃げ道です。

根本的には .zshrc を遅延ロード構成に書き直すのが王道です。zsh-defer や lazy-load を使って、実際に node コマンドを初めて打ったタイミングで nvm.sh を読み込むように変えると、ターミナル起動は 1 秒未満に縮みます。

パターン C：コマンドが見つからない場合の根本対処

「ターミナルは動くが node: command not found」という状況は、多くの場合 GUI アプリ経由で起動した Antigravity が OS のシェル環境と違う $PATH を引き継いでいることが原因です。

特に macOS で Homebrew を使っている方は、Finder やアプリランチャーから起動した Antigravity が /opt/homebrew/bin を認識しないという現象に遭遇しがちです。ターミナルから open -a Antigravity で起動すると直るのに、Dock アイコンから起動すると直らない——この挙動に見覚えはないでしょうか。

現状の PATH を正確に把握する

まず Antigravity のターミナルで次のコマンドを実行し、PATH を正規化して表示します。

# 目的: 現在の PATH を行ごとに表示して差分を見やすくする
# 期待出力: 各パスが 1 行ずつ表示され、/opt/homebrew/bin が含まれているか確認できる
echo "$PATH" | tr ':' '\n'

出力に /opt/homebrew/bin（Apple Silicon）や /usr/local/bin（Intel Mac）が含まれていなければ、Homebrew で入れたツールは見えません。

恒久的に PATH を通す二つのアプローチ

対処方法は二つあります。私は状況に応じて使い分けています。

アプローチ 1：Antigravity の設定ファイルに直接書く: settings.json の "terminal.integrated.env.osx" に "PATH": "/opt/homebrew/bin:/usr/local/bin:${env:PATH}" を追加します。手軽ですが、プロジェクトごとに違う Node バージョンを使う方には向きません。
アプローチ 2：.zprofile を整える: 私はこちらを推奨します。~/.zprofile に eval "$(/opt/homebrew/bin/brew shellenv)" を一行書くだけで、GUI から起動したプロセスでも PATH が通ります。ログインシェルだけが読むファイルなので、ターミナル起動のたびに処理が走らないのも利点です。

Windows で同様の症状が出る方は、ユーザー環境変数ではなくシステム環境変数に PATH を追加してから Antigravity を再起動してください。User レベルだと Antigravity の起動プロセスに伝わらないことがあります。

それでも直らないとき：設定を壊さずにターミナルだけ初期化する

三パターンを試しても改善しないときの最後の手段は、ターミナル関連の設定だけを初期化することです。Antigravity 全体を再インストールする必要はありません。

終了した状態で、設定フォルダの中からターミナル関連ファイルだけを退避させます。macOS の場合は次の通りです。

# 目的: ターミナル関連設定だけをバックアップしてリセットする
# 実行前提: Antigravity を完全終了してから実行
cd ~/Library/Application\ Support/Antigravity/User
cp settings.json settings.json.backup
# settings.json から "terminal.integrated." で始まる行だけを削除
python3 -c "
import json, re
with open('settings.json') as f:
    data = json.load(f)
cleaned = {k: v for k, v in data.items() if not k.startswith('terminal.integrated.')}
with open('settings.json', 'w') as f:
    json.dump(cleaned, f, indent=2)
print(f'removed {len(data) - len(cleaned)} terminal keys')
"

これで Antigravity を起動し直すと、デフォルト設定でターミナルが開きます。動作を確認できたら、バックアップから必要な設定を 1 つずつ戻していき、どの設定が壊れていたかを特定できます。

私はこの「退避して段階的に戻す」手法で、過去に terminal.integrated.persistentSessionReviveProcess の設定が悪さしていたケースを見つけました。Antigravity のアップデートで内部挙動が変わると、以前動いていた設定が突然足を引っ張ることがあります。

次に進むための一歩

ターミナル周りは、一度安定すると意識しなくなる地味なレイヤーですが、不調になった瞬間に開発全体が止まる致命的なポイントです。今日のうちに、自分の .zshrc か .bashrc の起動時間を計測しておくことをおすすめします。先ほど紹介した zsh -xvs を 1 回流して、2 秒を超えている行が 1 つでもあれば、それは未来のあなたを救うヒントです。

環境周りのトラブルで時間を溶かしがちな方には、設定ファイルを Dotfiles としてバージョン管理する習慣が効きます。設定を「工芸品」ではなく「再現可能なコード」として扱えるようになると、この手のトラブルからは確実に距離を取れるようになります。

関連する問題にも取り組んでいる方は、以下の記事もあわせてどうぞ。

Antigravity セットアップ時のエラー FAQ — 初回起動や認証で詰まったときの対処集です
Antigravity のリトライループが止まらないときの診断 — エージェントが無限再試行に陥る症状に焦点を当てています
Antigravity のクレジット・クォータ枯渇トラブル対処 — ターミナル問題と混同されやすい API 呼び出しエラーを扱っています