Antigravity CLI（agy）で作業が止まったときに出るエラーを、意味と直し方の順にまとめました。
| エラー | 意味 | まずやること |
|---|---|---|
| headless mode cannot prompt for, so it was auto-denied | -p で動かしたので、許可の確認が出せずに止めた | 必要な操作のallow、競合するask/deny、Windowsの照合条件を確認 |
| agy: command not found | シェルが実行ファイルを見つけられない | 導入済みかと実際の保存先を確認 |
| failed to retrieve token: secret keyring is locked | ログイン情報の保管場所が開けない | キーチェーンなどを開いてからやり直す |
| another background updater process is already active (update.lock) | 別の更新処理、残存ロック、権限不足など | 更新処理が動いているか先に確認 |
| モデルが使えない | 利用上限・プラン対象外・通信障害など | /usage で残りと戻る時刻を見る |
2026年10月23日に公式資料を再照合しました。掲載のWindows実行結果は2026年9月29日の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 では聞けないので、実行せずに止めたという意味です。
通常のCLI動作では作業フォルダ内の読み書きは自動許可されますが、明示したdeny/askなどが優先されます。コマンドも実行モードと設定で判定が変わるため、必要な操作のルールを先に確認します。
現在の公式headless資料でも、確認できない操作を拒否するsoft-deniedでは、処理が続き、終了コード0とstderrへの通知が返ると説明されています。
一方、応答生成そのものに失敗した実行は非ゼロで終了し、JSON出力ではstatus・errorにも失敗が記録されます。
終了コード0だけでコマンドが実行されたと判断せず、stderrの拒否通知と、期待した成果物・テスト結果を確認してください。
公式の直し方：permissions.allow
ホームフォルダの .gemini/antigravity-cli/settings.json に、許可するコマンドを書きます。
既存ファイルがある場合は内容を控え、下の例で全体を置き換えず、既存のpermissions.allow配列へ必要なルールを追加してください。
permissionsやallowがすでにある場合は同名キーを重複させず、ほかの設定とdeny・askを保持します。
{
"permissions": {
"allow": [
"command(git)",
"command(regex:npm run (build|lint|test))"
]
}
}command(git)は通常のコマンド接頭辞の許可例です。公式のWindows条件では、語に分割できないコマンドは既定で完全一致となるため、必要な範囲に絞ったregex指定などを検討します。
deny（止める）と ask（聞く）も書け、deny、ask、allow の順に優先されます。
旧版1.2.12のWindows検証では許可できなかった
echo hello を実行させる指示で、許可の書き方を変えて試しました。
| settings.json の permissions.allow | 結果 |
|---|---|
| （なし） | 上のエラーで止まった |
| command(echo hello) | 止まった |
| command(echo) | 止まった |
| command(*)（すべて許可） | 止まった |
当時はcommand(*)でも拒否されましたが、Windows全般でallowが無効とは断定できません。設定の読込み先、優先されるdeny/ask、実際に要求された操作とコマンド文字列を照合してください。
Windowsでは、コマンドがPowerShellなどを通して実行されるため、先頭の語が違っていることも考えられますが、確かめられていません。
旧版で確認を省略した実行結果
agy -p "シェルで echo hello を実行して" --dangerously-skip-permissions2026年9月29日のCLI 1.2.12では、このフラグを付けた実行で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：キーストアのデーモンの稼働と解除状態、D-Busセッションを確認する。dbus-launchによるセッション作成だけではキーストアの解除は保証されない
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 は別の設定であり、原因確認の代わりにはなりません。
モデルが使えないとき
利用枠と回復周期はプラン・モデルで異なります。公式案内ではPro・Ultraは5時間枠と週上限があり、それ以外は週単位の回復です。
通常枠が0%ならその枠では続行できません。対象アカウントのクレジット追加利用は別扱いで、設定・地域条件・残高を確認します。
/usageで残量と回復予定を確認します。別モデルへ切り替える場合は、残量だけでなく契約プランでの利用可否も確認してください。
制限の仕組みと、記録から分かったリセットの動き方は、Antigravityの利用制限の仕組みと確認方法で紹介しています。
まとめ
- -p で止まるのは、コマンドの許可を聞けないため
- 公式の直し方は permissions.allow だが、Windowsの1.2.12では command(*) でも効かなかった
--dangerously-skip-permissionsは許可確認を省略するため、信頼できる環境に限り、別のエラー原因は個別に調べる- update.lock は更新処理の稼働を先に確認する。キーリングのエラーは保管場所を確認する
- モデルが使えないときは /usage で利用制限を見る
参考：Antigravity公式「Troubleshooting」（2026年10月23日再照合）。
掲載の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がコマンドを実行しようとしたときに、許可の確認が出せずに止めたエラーです。
現行資料でも、確認できない操作のsoft-deniedは終了コード0で処理が続く場合があり、応答生成そのものの失敗で非ゼロになる場合と区別されています。
stderrの拒否通知、JSONのstatus・error、期待した成果物を照合してください。
公式の直し方は、どうするのですか？
ホームフォルダの .gemini/antigravity-cli/settings.json の permissions.allow に、許可するコマンドを書きます。
command(git)は通常のコマンド接頭辞の許可例です。公式のWindows条件では、語に分割できないコマンドは既定で完全一致となるため、必要な範囲に絞ったregex指定などを検討します。
deny（止める）と ask（聞く）も書け、deny、ask、allow の順に優先されます。
permissions.allow を書いたのに、Windowsで止まるのはなぜですか？
記事の確認では、Windows 11・Antigravity CLI 1.2.12 で、command(echo hello)・command(echo)・command(*)（すべて許可）のどれを書いても止まりました。
当時の原因は未確定です。設定の読込み先・競合するdeny/ask・実際の操作種別とコマンド文字列を確認します。
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接続時には、macOSのキーチェーンの解除とアプリへの許可、LinuxのD-Busとキーストアの稼働・解除状態を確認します。D-Busを開始するだけで解消するとは限りません。
「another background updater process is already active (update.lock)」とは？
別の更新処理、異常終了後のロック残存、書き込み権限不足などを確認する警告です。
まず更新処理が稼働中か確認し、動作中なら待ちます。
止まっていると確認できた場合にだけ残存ロックを対処し、再発するならインストール先の権限を調べます。
状態不明のままファイルを削除しないでください。
モデルが使えなくなったときは？
利用枠と回復周期はプラン・モデルで異なります。通常枠が0%ならその枠では続行できません。対象アカウントのクレジット追加利用は別扱いで、設定・地域条件・残高を確認します。
/usageで残量と回復予定を確認します。別モデルへ切り替える場合は、残量だけでなく契約プランでの利用可否も確認してください。
実行記録は2026年9月29日のCLI 1.2.12です。今回の更新は公式資料照合で、認証解除・更新ロック削除・許可設定変更・エラー再現はしていません。
最新は公式ページで確認してください。
