Antigravity CLI（agy）で作業が止まったときに出るエラーを、意味と直し方の順にまとめました。
| エラー | 意味 | まずやること |
|---|---|---|
| headless mode cannot prompt for, so it was auto-denied | -p で動かしたので、許可の確認が出せずに止めた | 許可の設定を足す（Windowsでは効かないことがある） |
| agy: command not found | agy の場所がPATHに入っていない | PATHを足してターミナルを開き直す |
| failed to retrieve token: secret keyring is locked | ログイン情報の保管場所が開けない | キーチェーンなどを開いてからやり直す |
| another background updater process is already active (update.lock) | 自動更新のロックが残っている | 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 に入っていないときに出ます。
Mac・Linuxなら、シェルの設定ファイルに場所を足して読み込み直します。
source ~/.zshrcWindowsなら、PATHを足したあとPowerShellを開き直します。
当方のWindowsでは、agy.exe が Codex のアプリのフォルダの中（AppData の Packages 以下）に入っていました。
見つからないと思ったら、AppData\Local の中で agy.exe を検索すると見つかることがあります。
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)
自動更新の途中でAntigravityが落ちるなどして、更新のロックのファイルが残ったときに出ます。
rm -f ~/.gemini/antigravity-cli/updater/update.lock自動更新を止めたいときは、環境変数 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」「Headless mode」「Permissions」（2026年9月29日に確認）。
