私は夜間にClaude Codeのheadless実行（claude -p）で無人ループを回しています。寝ている間や離席中に走らせているので、途中で「これ実行していいですか？」というプロンプトが出て止まってしまうと、朝まで誰も答えられないまま固まっていた、ということが起きます。オートモードがデフォルトになった話を書いたときにも触れましたが、オートモードの分類器（classifier）がどれだけ賢くなっても、「これは人に判断してもらうしかない」と分類器自身が判断した場面は残ります。無人運用では、その残った1件で丸ごと止まるのが一番怖いところです。
v2.1.259（2026年9月2日）で、この「答える人がいない」状況そのものに手を打つオプションが来ました。--permission-prompts noneです。公式changelogの記述を確認しましょう。
Added `--permission-prompts none` for unattended headless hosts: anything that
would prompt is denied automatically while the active permission mode
(including auto mode) keeps deciding「プロンプトが出るはずの場面を全部自動denyにする」だけでなく、「オートモードを含む、今動いているパーミッションモードの判定はそのまま生きる」という点がポイントです。ここを素朴な対処法と比較しながら見ていきます。
素朴な対処1: dontAskモードに変える
今までも「プロンプトが出そうなら全部拒否する」という運用はできました。--permission-mode dontAskです。公式docsにはこう書かれています。
If you set dontAsk mode, Claude Code auto-denies every tool call that would
otherwise prompt you. Claude still runs actions that need no approval in
Manual mode... Use this mode for CI pipelines or restricted environments
where you pre-define what Claude may doただ、これはパーミッションモードそのものを丸ごと切り替える話です。dontAskに入ると、オートモードの分類器によるアクション単位のレビューは使えなくなります。事前に許可リストで固めたCI向けの割り切った運用には向いていますが、「オートモードの柔軟さは残したまま、無人時だけ人手待ちを消したい」というニーズには合いません。
素朴な対処2: 承認用のMCPツールを渡す
--permission-prompt-toolで、プロンプトの判断を外部のMCPツールに委ねる方法もあります。ただしこれは「誰かが（あるいは何かが）答える」ことが前提の仕組みです。答える主体を用意できない無人ホストでは、結局そのツールへの問い合わせがタイムアウトするか、応答がないまま待たされることになります。答える相手がいないのに、答えてもらう仕組みだけ用意しても意味がありません。
本命: –permission-prompts noneは「待つかどうか」を切り替える
公式のheadlessガイドを読むと、このフラグが効くのはまさに「ホストがいる場合」だと明記されています。
The flag matters most when your run has a permission host: an Agent SDK app
with a canUseTool callback, or an MCP tool you pass with
--permission-prompt-tool. Without the flag, your run waits for that host to
answer each permission request.
With the flag, your run doesn't consult the host or wait on it. Anything that
would prompt is denied unless a PermissionRequest hook allows it, Claude is
told that nobody can approve the request and not to retry it, and the run
continues.つまり、Agent SDKのcanUseToolコールバックや--permission-prompt-toolで承認ホストを渡している構成が対象です。このフラグなしだと、Claude Codeはそのホストからの回答をひたすら待ちます。フラグを付けると、ホストへの問い合わせ自体をやめて即座にdenyし、Claudeには「もう誰も承認できないので、この操作はリトライしなくていい」と伝えます。ホストを持たない素のclaude -p単体実行では、そもそも承認prompt自体が最初からdenyされる仕組みなので、このフラグの主戦場はもう少し複雑な構成（Agent SDKや承認ツールを組んだ運用）だということになります。
使い方はオートモードと組み合わせるのが公式の想定です。
claude -p "Update the dependency pins and run the tests" \
--permission-mode auto --permission-prompts noneこの例では、分類器がいつも通り各アクションを個別にレビューし、そのうえで「これは人に聞くしかない」と分類器が判断したものだけを自動denyにします。dontAskモードのようにモード全体を切り替えるわけではないので、分類器のきめ細かい判定はそのまま使えます。公式docsも「Permission rules, PermissionRequest hooks, and the permission mode you set still decide every call first; Claude Code denies only the requests that nothing else resolves」と、優先順位をはっきり書いています。permissionルールやHooks、パーミッションモードが先に判定し、それでも残った「人に聞くしかない」ものだけが今回のフラグの対象です。
人に聞く前提のツールは、呼べなくなる
もう一つ正直に書いておきたい挙動があります。--permission-prompts noneを付けると、AskUserQuestionのような「人に聞く」ことが前提のツール自体が取り除かれ、Claudeはそもそも呼べなくなります。MCPのelicitationリクエストも、ElicitationHookが答えない限りキャンセルされます。単にプロンプトへの回答を自動denyにするだけでなく、「聞く」という選択肢そのものをClaudeの手札から抜いてしまう仕組みだと理解した方が正確そうです。
--output-format stream-jsonで流している場合は、denyされた瞬間がpermission_deniedというsystemメッセージで見え、最終的な結果メッセージのpermission_denialsにもまとめて載るとのことです。無人ループのログを後から見返すときに、「どこがdenyされて、そのままタスクが進んだのか」を追いかけられそうです。
dontAskモードとの違いを整理する
| –permission-mode dontAsk | –permission-prompts none | |
|---|---|---|
| 正体 | パーミッションモードそのもの | printモード(-p)専用のフラグ |
| オートモードの分類器 | 使えない（モードが切り替わる） | 使える（分類器の判定はそのまま生きる） |
| 対象 | Manual相当で承認されないもの全部 | 承認ホストに聞くしかない場面だけ |
| 向いている用途 | 許可リストで固めたCI | Agent SDK/承認ツール込みの無人headless運用 |
| 必要バージョン | (既存機能) | v2.1.259以降 |
以前–restrictedの記事で、コマンド実行やWebFetchそのものを封じるオプションを紹介しました。今回のはそれとは軸が違います。–restrictedは「できることの範囲」を狭める話で、–permission-prompts noneは「できる範囲は変えず、人に聞く必要が出た場面の扱い方」を変える話です。無人運用でどちらを組み合わせるかは、封じたいのが操作の範囲なのか、止まってしまう場面なのかで選ぶことになりそうです。
正直に書いておくこと
公式docsの記述を読み込んだ範囲では、フラグの仕様と、それがAgent SDKの承認ホストを前提にした挙動だということはかなり詳しく書かれていました。一方で、実際に自分のheadlessループにこのフラグを組み込んで、denyが積み重なったときにタスク全体がどこまで進められるのか、分類器の判定と噛み合わずに想定外の場所でdenyが増えないか、といった運用面の手触りはまだ確認していません（v2.1.259がリリースされてから日が浅いこともあります）。付けてみて様子を見る、という段階だと思ってください。
まずは分類器を残したまま試す
導入するなら、--permission-mode dontAskにモードごと切り替えるより、まず今使っているモード（オートモードならauto）に--permission-prompts noneだけ足してみるのがいいはずです。分類器の判定基準は変えずに、人待ちで固まる場面だけをdenyに倒せます。完了通知のHooksと組み合わせれば、denyが起きたことも含めて後から気付けるようになります。無人ループを回している人には、地味ですが刺さるオプションだと思います。他に組み合わせて使えそうなパターンがあれば、コメントで教えてください。
コメント