/fewer-permission-promptsで許可プロンプトを自動整理する
/fewer-permission-promptsは過去の会話履歴を走査し、繰り返し許可しているBashやMCPのツール呼び出しをsettings.jsonのallowlistへ自動で追加するスキルです。仕組みと注意点をまとめます。
/fewer-permission-prompts は、過去のトランスクリプトを走査してよく許可しているBashやMCPのツール呼び出しを見つけ出すバンドルスキルです。優先度付きのallowlistとして、プロジェクトの .claude/settings.json に追加します。毎回同じコマンドで「Yes, and don't ask again」を押し続ける手間を、まとめて解消できます。
/fewer-permission-promptsは何をするコマンドか
/fewer-permission-prompts を実行すると、Claude Codeはこれまでの会話履歴からBashとMCPのツール呼び出しをスキャンします。そこで頻出する読み取り専用系の呼び出しを洗い出し、優先順位を付けてプロジェクトの .claude/settings.json にallowlistとして書き込みます。1件ずつ「はい、次から聞かない」を押し続ける代わりに、これまでの傾向をまとめて反映する形です。
/fewer-permission-prompts/doctor(セットアップの健康診断コマンド)にも似た機能があり、頻繁に拒否されている読み取り専用コマンドの事前承認を提案します。両者は目的が近く、/doctor はインストール診断のついでに提案する形、/fewer-permission-prompts は許可プロンプトの削減そのものに特化したスキルという違いがあります。
読み取り専用コマンドはそもそも一部が自動承認されている
/fewer-permission-prompts の効果を正しく見積もるには、Claude Codeが元々どこまで自動で許可しているかを知っておく必要があります。ls cat echo pwd head tail grep find wc which diff stat du cd、それにgitの読み取り専用な使い方は、組み込みの読み取り専用コマンド集としてプロンプトなしに実行されます。この一覧は設定で変更できませんが、例外もあります。Manualモードでは、書き込み・実行フラグを持つコマンド(find sort sed git など)へクォートなしのグロブを渡す場合や、watch setsid ionice flock などのexecラッパーを経由する場合、find の -exec / -delete を伴う場合は、この一覧に含まれるコマンドでもプロンプトが出ます。
つまり /fewer-permission-prompts が実質的に効くのは、この組み込みセットに含まれない読み取り専用コマンド(プロジェクト固有のCLIツールやスクリプトなど)と、MCPサーバー経由のツール呼び出しです。組み込みで既に自動承認されているコマンドをallowlistに書き足しても効果は変わりません。
allowlistはプロジェクト設定に書かれる
/fewer-permission-prompts が書き込む先はプロジェクトスコープの .claude/settings.json です。Claude Codeの設定はManaged・User・Project・Localの4スコープに分かれています。このうちProjectスコープは「リポジトリの全コラボレーターに影響し、gitにコミットされて共有される」設定です。
つまり /fewer-permission-prompts を実行してそのままコミットすると、生成されたallowlistはチーム全員に適用されます。個人的な作業環境だけで許可を増やしたい場合は、生成されたルールを .claude/settings.local.json(gitignore対象のLocalスコープ)へ手動で移します。コミット前にレビューして、本当にチーム共有してよい範囲かを確認する運用も安全です。
| スコープ | 場所 | チーム共有 |
|---|---|---|
| Project | 場所.claude/settings.json | チーム共有される(gitにコミット) |
| Local | 場所.claude/settings.local.json | チーム共有されない(gitignore対象) |
allowlistのルールがどう評価されるか
/fewer-permission-prompts が追加するのは permissions.allow のエントリです。Bashの許可ルールはワイルドカード * を使ったパターンマッチで、コマンドの前後どこにでも置けます。Bash(npm run test *) は npm run test で始まるコマンドに一致し、Bash(npm *) は npm で始まる任意のコマンドに一致します。
ルールの評価順序はdeny→ask→allowの固定順で、範囲の広さは関係ありません。Bash(aws *) のようなdenyルールがあれば、より狭いallowルールが一致していてもブロックされます。/fewer-permission-prompts が生成したallowルールがある場合でも、既存のdeny/askルールの方が常に優先される点は覚えておく必要があります。
複合コマンド(&& || ; | などで繋いだコマンド)は、各サブコマンドが個別に評価されます。ただしルールとして保存されるのは、承認が必要だったサブコマンドだけです。git status && npm test を承認した場合、git status は組み込みの読み取り専用コマンドとしてすでに承認不要なので、保存されるのは npm test のルールだけです。1つの複合コマンドから保存されるルールは最大5個までという上限があります。
コマンドの前に付くラッパーは、マッチング前に取り除かれます。該当するのは timeout time nice nohup stdbuf、シェル組み込みの command builtin、zshの noglob です。Bash(npm test *) というルールは、timeout 30 npm test にもそのまま一致します。この一覧は固定で設定変更できません。一方、direnv exec devbox run mise exec npx docker exec のような開発環境ランナーはこの一覧に含まれていません。これらは自分の引数をそのままコマンドとして実行するため、Bash(devbox run *) のようなルールは devbox run の後ろに続く任意のコマンドに一致してしまいます。環境ランナー越しの操作を承認したいときは、ランナー名と内部コマンドの両方を含む具体的なルール(Bash(devbox run npm test) 等)を1コマンドずつ書く必要があります。/fewer-permission-prompts が生成したルールに環境ランナー経由のコマンドが含まれている場合は、この広がりすぎのリスクを意識して確認するとよいでしょう。
MCPツールはサーバー単位かツール単位で許可される
/fewer-permission-prompts はBashだけでなくMCPのツール呼び出しも走査対象にします。MCPの許可ルールは、Claude Codeに設定されたサーバー名だけを書くか、その後ろに個別のツール名を続けるかの2段階で指定します。
mcp__puppeteerはpuppeteerサーバーが提供する全ツールに一致しますmcp__puppeteer__*もワイルドカード構文で同様に全ツールへ一致しますmcp__puppeteer__puppeteer_navigateはpuppeteerサーバーのpuppeteer_navigateツールだけに一致します
どちらの粒度でルールが生成されるかはトランスクリプトの使用傾向によって変わるため、実行後は /permissions を開いてどの粒度のルールが実際に追加されたかを確認しておくとよいでしょう。狭いルールほど、まだ使っていない別のツールを誤って許可しない安全側の選択です。
なお、組織のclaude.aiコネクタがそのツールを ask に設定している場合、allowルールを追加しても効果がありません。auto モードや bypassPermissions モードでも毎回確認を求められ、dontAsk モードではその呼び出し自体が拒否されます。/fewer-permission-prompts が生成したルールも、この組織設定の上からは書き換えられません。
生成されたallowlistの落とし穴
/fewer-permission-prompts が作るBashルールは、コマンド文字列の前方一致・後方一致・部分一致のパターンです。ここには構造的な弱点があります。たとえば「curlの宛先をgithub.comに絞りたい」という意図で Bash(curl http://github.com/ *) のようなルールを書いても、これは次のような別形式のコマンドには一致しません。
- オプションがURLより前に来る場合(
curl -X GET http://github.com/...) - プロトコルが違う場合(
https://github.com/...) - リダイレクトを経由する場合(短縮URLがgithub.comへリダイレクトするケース)
- 変数を経由する場合(
URL=http://github.com && curl $URL)
/fewer-permission-prompts はトランスクリプトに実際に現れたコマンド文字列からルールを起こすため、生成された時点のルールが将来使われる別の書き方まではカバーしません。自動生成だからといって安全側に倒れているとは限らない点は意識しておく必要があります。ネットワークアクセスを伴うコマンドを厳密に制限したいなら、別のアプローチが確実です。Bashの curl や wget 自体をdenyルールでブロックし、許可したいドメインだけ WebFetch(domain:github.com) のようなWebFetchツールの許可ルールに切り替えます。
手動でallowlistを書く場合との違い
/fewer-permission-prompts は実際の使用パターンから逆算してルールを生成する点が、最初から手動でallowlistを設計する方法と異なります。
| 方法 | 向いている場面 | 注意点 |
|---|---|---|
/fewer-permission-prompts | 向いている場面すでにある程度セッションを重ね、繰り返し許可しているコマンドが把握できている | 注意点走査対象はトランスクリプトなので、まだ使っていないコマンドは拾えない |
| 手動でallowlistを設計 | 向いている場面プロジェクト開始時に方針を先に決めたい、チームの合意を明文化したい | 注意点ワイルドカードの挙動(スペースの有無で単語境界が変わる等)を理解して書く必要がある |
どちらの方法でも、生成・追記したルールはコマンドラインで確認できます。/permissions ダイアログを開くと、現在有効な全ルールとそれぞれがどの settings.json に由来するかが一覧表示されます。/fewer-permission-prompts の実行後は、この画面で追加されたルールを確認してから使い始めるとよいでしょう。settings.json の全項目を体系的に把握したい場合はClaude Code settings.json完全ガイドが参考になります。
Claude Code以外のAIコーディングエージェントと権限モデルを比較したい場合は、AIコーディングエージェント権限モデル比較で設計思想の違いを整理しています。
よくある質問
/fewer-permission-promptsを実行すると何が危険になるか
追加されるのはBashとMCPの読み取り専用寄りのツール呼び出しに限られますが、Bashの許可パターンはコマンド文字列のマッチングであり、意図しないコマンドまで一致する可能性がある点は変わりません。生成後は /permissions で内容を確認し、書き込み系のコマンドが誤って含まれていないか目視するのが安全です。
/fewer-permission-promptsと/doctorはどちらを使えばよいか
許可プロンプトの削減だけが目的なら /fewer-permission-prompts を直接使う方が早く終わります。/doctor はインストール診断・不要なスキルやMCPサーバーの検出など他のチェックも同時に行うコマンドなので、セットアップ全体の健康診断をしたいときに向きます。
生成されたallowlistをチームで共有したくない場合はどうするか
/fewer-permission-prompts はプロジェクトスコープの .claude/settings.json に書き込むため、そのままコミットすればチーム全員に適用されます。個人利用に留めたいなら、生成されたエントリを .claude/settings.local.json へ移すか、コミット前にレビューします。
MCPサーバーのツールも自動でallowlist化されるか
対象になります。/fewer-permission-prompts はBashだけでなくMCPのツール呼び出しもトランスクリプトから走査するため、頻繁に許可しているMCPツールがあればサーバー単位またはツール単位のルールとして追加されます。ただし組織のclaude.aiコネクタが ask に設定しているツールには、生成されたallowルールがあっても確認プロンプトが出続けます。
まとめ
/fewer-permission-prompts はトランスクリプトの実際の使用履歴から許可ルールを逆算して生成する分、手動でallowlistを設計するより着手が早いスキルです。ただし組み込みの読み取り専用コマンドにはそもそも効果がなく、書き込み先がプロジェクト共有の settings.json である点は実行前に把握しておく必要があります。生成後は /permissions で内容を確認し、環境ランナー越しの広いルールが混ざっていないか一度は目を通してから使い始めるのが安全です。