無人で走っている Claude Code が、権限の確認を求めてその場で止まる。誰も答えないので、答えが返るまで待つ。無人実行でいちばん困るのがこれで、筆者の月曜ジョブは --permission-mode dontAsk を渡して「待たない」側へ倒してある。2026年9月2日の changelog に入った --permission-prompts none は、同じ「待たずに拒否する」を別の入口から選ばせるフラグだ。手元の構成にとって新しい何かなのか、同じ場所に二重で鍵を掛けるだけなのかは、測らないと分からない。この測定はまだ実施していない。この記事は、何をどの条件で測るかを決めたところまでを残す。
目次
追加されたのは「プロンプトが出る瞬間にどうするか」の選択肢
Claude Code v2.1.259 で --permission-prompts none が追加された。無人のヘッドレス実行中に確認プロンプトが出るはずの操作を、待たずに自動で拒否する。同じ版には claude plugin validate --json と managedMcpServers も入っている。
フラグが手を入れるのは、権限の判定が「人に聞く」に着地した後の一手だけだ。何を許可するかの判定そのものは動かない。権限モードの判定は auto を含めてそのまま働き、許可済みの操作は従来どおり通る。落ちるのは、判定がつかずに確認へ回った操作だけになる。
「無人だと何もできなくなる」ではない
このフラグの説明を「無人実行では全部拒否される」と読むと、設計を一段まるごと間違える。allow ルールで通していた操作は通る。止まるのは、これまで人の判断を待っていた一手だけだ。ツール一覧そのものに手が入るかどうかは changelog に書かれていない。外れないと読んではいるが、読み替えなので確かめる側へ回し、後の表に入れた。
ここまでが、収集した情報から読み取れる範囲になる。読み取れない範囲もはっきりしている。
ひとつは「許可済み」の実際の広さだ。手元の無人ジョブでは --allowedTools は追加であって排他 allowlist ではなく、checkout の .claude/settings.local.json に書いた事前承認も効く。scripts/editorial_runner.py にはその前提でコメントを置き、事前承認ぶんを --disallowedTools で明示的に塞いである。実際の「許可済み」は、起動引数に並べた文字列より広い。その広い集合のどこまでが「通る」側に入るかは、自分の構成で走らせないと確かめられない。
もうひとつは、落ちた一手がセッションをどうするかだ。その操作だけが失敗して続きが走るのか、セッションごと終わるのか。無人ジョブでは後者だと途中の部署が丸ごと落ちる。
先週書いた --restricted とは別のフラグ
同じ changelog を出典に先週書いた --restricted を9項目で実測した回と混同しやすいので、違いを先に置く。--restricted はツールそのものを一覧から外すフラグで、--permission-prompts none はツールを外さず、確認プロンプトを待たずに拒否するフラグだ。前者は入口の数を減らし、後者は入口の前で立ち止まったときの振る舞いを決める。効く層が違うので、片方を入れてももう片方の穴は埋まらない。
手元の無人ジョブは、すでに「待たない」側にある
筆者の月曜ジョブは、編成会議のステップと5部署のステップの両方で Claude Code を headless 起動している。どちらも --permission-mode dontAsk を渡していて、権限プロンプトで待ち続けることを避ける設計になっている。許可するツールは絞ってあり、部署セッションでは Bash(python:*) のような広い許可を意図して書いていない。リポジトリ内の公開系スクリプトまで一緒に通ってしまうからだ。
この構成では、許可外のコマンドは確認を挟まずに拒否される。2026-W35 に起きた失敗は、その拒否が直接の原因ではなかった。編成会議のステップがログを読み違えて「別の無人ジョブが走行中」と判断し、二重書き込みを避けるつもりで agenda を1件も作らずに終わっている。同時実行を疑うならログの行ではなく実プロセスで確かめればよかったのだが、そのコマンドが allowlist に無ければ自動で拒否され、確認できないまま同じ場所へ倒れる。手当てとして読み取り専用のコマンドを1本 allow に足し、「これは再発経路だ」という判断をコードのコメントに残してある。
--permission-prompts none を足したところで、拒否されるものは今も拒否されているかもしれない。二重に掛ける鍵そのものは害ではないが、効いていない鍵を掛けて安心するのは害になる。allow ルールを棚卸しした回で見たとおり、権限の設定は書いたつもりと効いている範囲がずれる。フラグを足す前に、いまの構成で何が通って何が落ちているかを並べ直すほうが先になる。
測る前に決めたこと
測定は本番のリポジトリでは行わない。無人ジョブの書込範囲ゲートはセッション前後のハッシュ比較で動くので、検証のための書込がそのまま「想定外の書込」として扱われ、全部署が blocked になる。使い捨てのディレクトリに、起動の形だけを同じにして再現する。本番の月曜ジョブへ実際に入れるかどうかは、測定結果を見てから別に決める。
版の確認も先に済ませる。フラグは v2.1.259 で入ったものなので、それより古い版で走らせて「効かなかった」を結論にすると、何も測れていないことになる。実行前に claude --version を取り、記事にはその版番と測定日をそのまま載せる。あわせて claude --help の --permission-prompts の説明文も見る。changelog は none を指定した形でしか書いておらず、他にどの値を取るかは載っていない。
比べる群は3つ取る。フラグを足した実験群が1つ、比較のための対照群が2つだ。同じプロンプト・同じ許可・同じディレクトリで、変えるのは起動引数だけにする。
各群は3回ずつ走らせる。1回だけだと、通った／落ちたの差がフラグによるものか、その回の判断の揺れかを分けられない。走らせるたびに claude --version の出力と実行日を記録し、3回とも同じ版で取れているかを後から確認できる形にする。
PROMPT='1. before.txt に before と書く 2. git log -1 を実行する 3. after.txt に after と書く 各手順を OK か REFUSED で報告する'
# 対照群A: いまの月曜ジョブと同じ形
claude -p "$PROMPT" --allowedTools "Read,Glob,Write" --permission-mode dontAsk
# 実験群B: 同じ形にフラグを1つだけ足す
claude -p "$PROMPT" --allowedTools "Read,Glob,Write" --permission-mode dontAsk --permission-prompts none
# 対照群C: 権限モードを既定に戻し、フラグだけで走らせる
claude -p "$PROMPT" --allowedTools "Read,Glob,Write" --permission-prompts noneプロンプトの中身は、許可された書込・allowlist に無いコマンド・もう一度許可された書込、の順に並べてある。3つ目の after.txt が残っていれば、拒否のあともセッションが続いたことになる。残っていなければ、1回の拒否でそこから先が走らなくなったことになる。
# 各群の直後に取る。判定はモデルの応答ではなくディスクと終了コードで行う
echo "exit=$?"
ls -l before.txt after.txt応答が DONE と言っていてもファイルが無いことはあるし、REFUSED と言いながら書けていることもある。引用符付きパスで権限チェックを検証した回で自己申告と実際の挙動がずれるのを見ているので、判定はディスクを見て決める。手元の月曜ジョブは Windows のタスクスケジューラから claude.exe を呼んでいるため、実際の起動では同じ引数を PowerShell の書式に直して渡すことになる。
| 測る項目 | 何を見るか | 判定の分かれ目 |
|---|---|---|
| 拒否がログにどう出るか | 親プロセスがリダイレクトしているログの該当行 | 行として残るならログの検索で拾える。応答本文の一部にしか出ないなら、無人ジョブ側で拾う仕組みを別に足す |
| 既存の許可運用と二重にならないか | 対照群Aと実験群Bで、通った操作と落ちた操作の集合が変わるか | 集合が同じなら手元の構成にとっては無害な追加。変わるなら allow ルールの棚卸しが先になる |
| 落ちたセッションの挙動 | 終了コードと、run.json / status.json の最終状態 |
拒否がセッション全体の失敗になるか、その一手だけ落ちて続くか |
| 権限モードとの同時指定 | 対照群Cと実験群Bの差 | 両立するのか、片方が無視されるのか |
| ツール一覧が変わるか | 実験群Bで使えるツールの集合が対照群Aと同じか | 同じなら「ツールは外れない」と書ける。違えば --restricted との違いの説明から直す |
判定の分かれ目を先に書いておくのは、結果がどちらに出ても記事が成立する形にするためだ。集合が変わらなければ「手元の構成には効かない追加だった」と書けるし、変われば「allow ルールを先に整理する」と書ける。どちらになるかは、測っていないのでここには書けない。
同じ版に入った残り2つのうち、無人運用に効く範囲
claude plugin validate --json は、プラグイン構成の検査結果を JSON で返す。人が読む前提の出力ではなくスクリプトが解釈できる形になるので、無人ジョブの前段に構成の検査を1本置きたいときはこの形が要る。筆者の月曜ジョブはプラグインを前提に組んでいないため、いま組み込む予定は無い。
managedMcpServers は MCP サーバーを管理側から指定する仕組みだ。無人セッションにとって MCP は外部へ出る経路のひとつなので権限の話と地続きではあるが、扱う層が違うのでここでは踏み込まない。
一次ソース
- Claude Code changelog（公式） — v2.1.259（2026-09-02）の
--permission-prompts none追加の項
関連記事
まとめ
分かっているのは、--permission-prompts none が変えるのが「待つか、その場で落とすか」の一点だということだ。何が許可されるかの判定は動かないので、通っていた操作は通る。落ちるのは確認へ回った一手だけになる。最初に受け取りがちな「無人だと何もできなくなる」は当たらない。
分かっていないのは、すでに dontAsk で走っている構成にとって、これが新しい鍵なのか二本目の鍵なのかだ。3群を並べて、通った操作と落ちた操作の集合を比べるところまで設計した。この測定はまだ実施していない。本番の月曜ジョブへ入れるかどうかも、測定結果を見てから決める。走らせて拒否の実物が出たら、その内容をこの記事に追記する。
