Antigravity CLI（agy）で作業が止まったときに出るエラーを、意味と直し方の順にまとめました。
| エラー | 意味 | まずやること |
|---|---|---|
| headless mode cannot prompt for, so it was auto-denied | -p で動かしたので、許可の確認が出せずに止めた | 許可の設定を足す（Windowsでは効かないことがある） |
| agy: command not found | シェルが実行ファイルを見つけられない | 導入済みかと実際の保存先を確認 |
| failed to retrieve token: secret keyring is locked | ログイン情報の保管場所が開けない | キーチェーンなどを開いてからやり直す |
| another background updater process is already active (update.lock) | 別の更新処理、残存ロック、権限不足など | 更新処理が動いているか先に確認 |
| モデルが使えない | 利用制限を使い切った | /usage で残りと戻る時刻を見る |
この記事は、2026年9月29日時点の公式ドキュメントと、Windows上の Antigravity CLI 1.2.12 で確かめた結果にもとづいています。
headless mode cannot prompt for, so it was auto-denied
jetski: no output produced — a tool required the "command" permission that headless mode cannot prompt for, so it was auto-denied. Add an allow-rule under permissions.allow in settings.json (e.g. command(<target>)). Alternatively, re-run with --dangerously-skip-permissions to auto-approve all tools.画面の無い実行（agy -p）で、Antigravityがコマンドを実行しようとしたときに出ます。
ふだんなら「実行してよいか」を聞かれるところですが、-p では聞けないので、実行せずに止めたという意味です。
公式ドキュメントによると、作業フォルダの中のファイルの読み書きは自動で許可されますが、コマンドの実行は許可を決めておく必要があります。
止められても終了コードは0なので、スクリプトから動かしていると失敗に気づきにくい点に注意します。
公式の直し方：permissions.allow
ホームフォルダの .gemini/antigravity-cli/settings.json に、許可するコマンドを書きます。
{
"permissions": {
"allow": [
"command(git)",
"command(regex:npm run (build|lint|test))"
]
}
}command(git) は、git で始まるコマンドを許可する書き方です。
deny（止める）と ask（聞く）も書け、deny、ask、allow の順に優先されます。
Windowsで試したら効かなかった
echo hello を実行させる指示で、許可の書き方を変えて試しました。
| settings.json の permissions.allow | 結果 |
|---|---|
| （なし） | 上のエラーで止まった |
| command(echo hello) | 止まった |
| command(echo) | 止まった |
| command(*)（すべて許可） | 止まった |
すべてを許可する command(*) でも止まったので、この版のWindowsでは設定が効いていないか、置き場所や書き方が違う可能性があります。
Windowsでは、コマンドがPowerShellなどを通して実行されるため、先頭の語が違っていることも考えられますが、確かめられていません。
–dangerously-skip-permissionsなら通る
agy -p "シェルで echo hello を実行して" --dangerously-skip-permissionsこのフラグを付けると、許可の確認をすべて省いて実行され、hello が返ってきました。
ただし、ファイルの書き込みもコマンドの実行もすべて許可されるので、中身を信頼できる指示と環境でだけ使います。
画面のある Antigravity で確認を止める設定は、Antigravityの確認を止めて自動実行する方法で紹介しています。
agy: command not found
シェルが agy を見つけられないという意味です。未インストールの場合もあるため、PATHを変更する前にCLIを導入済みか確認します。導入済みなら、実行ファイルがあるフォルダーと、現在のシェルのPATHを照合してください。
Mac・Linuxでは command -v agy、PowerShellでは Get-Command agy -All で現在見つかる実行ファイルを確認します。何も見つからなければ、導入時の保存先に実体があるか確認し、そのフォルダーをPATHへ追加します。複数見つかった場合は、使う版のパスを確認してください。次の読み込み直しはzsh向けです。Bashなら実際に編集した設定ファイルに合わせます。
source ~/.zshrcWindowsなら、PATHを足したあとPowerShellを開き直します。
当方のWindowsでは、agy.exe が Codex のアプリのフォルダの中（AppData の Packages 以下）に入っていました。
これは当方で見つかった配置の記録で、公式インストーラーの標準配置を示すものではありません。見つかったファイルを無条件に使わず、公式の導入手順とインストール元を確認してください。
failed to retrieve token: secret keyring is locked
ログイン情報を保管しているOSの仕組み（Macのキーチェーン、Linuxのsecret-service、Windowsの資格情報マネージャー）が開けないときに出ます。
画面の無い環境やSSHで接続したときに起きやすいエラーです。
- Mac：security unlock-keychain でキーチェーンを開く
- Linux：export $(dbus-launch) でD-Busのセッションを始める
another background updater process is already active (update.lock)
別の更新処理が動いている可能性を示す警告です。公式資料では、更新プロセスの停止・異常終了によるロック残存だけでなく、インストール先の書き込み権限不足も原因に挙げられています。警告が出ただけでロックファイルを削除しないでください。
次の削除例は、更新処理が動いていないことを確認でき、異常終了後のロックだけが残っている場合に限ります。動作中や状態不明なら実行せず、下記の確認順に従ってください。
rm -f ~/.gemini/antigravity-cli/updater/update.lock上の削除例はMac・Linuxなどのシェル向けです。先にタスクマネージャーやアクティビティモニタなどで更新処理の状態を確認し、動作中なら完了を待ちます。更新が動いていないのに警告が続く場合だけ、残存ロックの対処を検討します。状態を判断できなければ削除せず、警告全文とCLIの版を添えてサポートへ確認してください。削除後も再発する場合は、インストール先の所有者・書き込み権限を確認します。自動更新を停止する AGY_CLI_DISABLE_AUTO_UPDATE=true は別の設定であり、原因確認の代わりにはなりません。
モデルが使えないとき
Antigravityには、モデルの組ごとに5時間と週の利用制限があります。
残りが0%になると、その組のモデルは戻る時刻まで使えません。
/usage で残りと戻る時刻を確かめ、別の組のモデルに切り替えるか、戻るまで待ちます。
制限の仕組みと、記録から分かったリセットの動き方は、Antigravityの利用制限の仕組みと確認方法で紹介しています。
まとめ
- -p で止まるのは、コマンドの許可を聞けないため
- 公式の直し方は permissions.allow だが、Windowsの1.2.12では command(*) でも効かなかった
- –dangerously-skip-permissions なら通るが、すべて許可になるので環境を選ぶ
- update.lock は更新処理の稼働を先に確認する。キーリングのエラーは保管場所を確認する
- モデルが使えないときは /usage で利用制限を見る
参考：Antigravity公式「Troubleshooting」（2026年10月14日再確認）。掲載のWindows実行結果は2026年9月29日・CLI 1.2.12の記録です。今回のPATHと更新ロックの補足は診断の前提整理であり、更新ロック削除やWindowsでの再現試験は行っていません。
よくある質問：Antigravity CLI（agy）のエラー
「headless mode cannot prompt for, so it was auto-denied」は、何のエラーですか？
画面の無い実行（agy -p）で、Antigravityがコマンドを実行しようとしたときに、許可の確認が出せずに止めたエラーです。終了コードは0なので、スクリプトから動かしていると失敗に気づきにくい点に注意します。
公式の直し方は、どうするのですか？
ホームフォルダの .gemini/antigravity-cli/settings.json の permissions.allow に、許可するコマンドを書きます。command(git) は、git で始まるコマンドを許可する書き方です。deny（止める）と ask（聞く）も書け、deny、ask、allow の順に優先されます。
permissions.allow を書いたのに、Windowsで止まるのはなぜですか？
記事の確認では、Windows 11・Antigravity CLI 1.2.12 で、command(echo hello)・command(echo)・command(*)（すべて許可）のどれを書いても止まりました。この版のWindowsでは、設定が効いていないか、置き場所や書き方が違う可能性があります。Windowsではコマンドが PowerShell などを通して実行されるため、先頭の語が違っていることも考えられますが、確かめられていません。
–dangerously-skip-permissions を付ければ、解決しますか？
記事の確認では、このフラグを付けると、許可の確認をすべて省いて実行され、結果が返ってきました。ただし、ファイルの書き込みもコマンドの実行もすべて許可されるので、中身を信頼できる指示と環境でだけ使います。
「agy: command not found」と出たら？
まずCLIを導入済みか確認します。導入済みなら、Mac・Linuxは command -v agy、PowerShellは Get-Command agy -All で実行ファイルを確認し、実際の保存先とPATHを照合します。PATH変更後はターミナルを開き直し、agy --version が表示されるか確かめます。
「failed to retrieve token: secret keyring is locked」は、どう直しますか？
ログイン情報を保管しているOSの仕組み（Macのキーチェーン、Linuxのsecret-service、Windowsの資格情報マネージャー）が開けないときに出ます。画面の無い環境やSSHで接続したときに起きやすく、Macは security unlock-keychain でキーチェーンを開き、Linuxは D-Bus のセッションを始めてからやり直します。
「another background updater process is already active (update.lock)」とは？
別の更新処理、異常終了後のロック残存、書き込み権限不足などを確認する警告です。まず更新処理が稼働中か確認し、動作中なら待ちます。止まっていると確認できた場合にだけ残存ロックを対処し、再発するならインストール先の権限を調べます。状態不明のままファイルを削除しないでください。
モデルが使えなくなったときは？
Antigravityには、モデルの組ごとに5時間と週の利用制限があり、残りが0%になると、その組のモデルは戻る時刻まで使えません。/usage で残りと戻る時刻を確かめ、別の組のモデルに切り替えるか、戻るまで待ちます。なお、記事は2026年9月29日時点の公式ドキュメントと Windows 上の Antigravity CLI 1.2.12 での確認にもとづきます。最新は公式ページで確認してください。
