Claude Media
/fewer-permission-promptsで許可プロンプトを自動整理する
Claude CodeTips

/fewer-permission-promptsで許可プロンプトを自動整理する

/fewer-permission-promptsは過去の会話履歴を走査し、繰り返し許可しているBashやMCPのツール呼び出しをsettings.jsonのallowlistへ自動で追加するスキルです。仕組みと注意点をまとめます。

読了目安 約11分

/fewer-permission-prompts は、過去のトランスクリプトを走査してよく許可しているBashやMCPのツール呼び出しを見つけ出すバンドルスキルです。優先度付きのallowlistとして、プロジェクトの .claude/settings.json に追加します。毎回同じコマンドで「Yes, and don't ask again」を押し続ける手間を、まとめて解消できます。

ただし、効く場面は思ったより限られます。v2.1.283以降はauto modeが対話セッションの既定モードです(全プラン・全プロバイダーに広がったのはv2.1.284)。読み取り専用の主要コマンドは、最初から確認なしで動きます。

/fewer-permission-promptsは何をするコマンドか

/fewer-permission-prompts を実行すると、Claude Codeはこれまでの会話履歴からBashとMCPのツール呼び出しをスキャンします。頻出する読み取り専用系の呼び出しを洗い出し、優先順位を付けてプロジェクトの .claude/settings.json にallowlistとして書き込みます。

/fewer-permission-prompts

/doctor(セットアップの健康診断コマンド)にも似た機能があります。頻繁に拒否されている読み取り専用コマンドの事前承認を、診断のついでに提案する形です。許可プロンプトの削減だけが目的なら /fewer-permission-prompts を直接使うほうが早く、インストール診断や不要なスキル・MCPサーバーの検出も一緒にやりたいときは /doctor が向きます。

実行する前に確認したい3つの状況

プロンプトが出る原因によって、このスキルで減るかどうかが分かれます。

  • auto modeで動いている: 確認の相手は、あなたではなく分類器(classifier)です。読み取り専用の組み込みコマンドも、分類器のレビューを待つことがあります。
  • Manualモードで動いている: 組み込みの読み取り専用セットを除く、プロジェクト固有のコマンドとMCPツールが主な対象です。このスキルが最も効く条件です。
  • 組織のコネクタ設定が絡む: allowルールでは動かせないプロンプトがあります(MCPの節で扱います)。

auto modeでは、広すぎるallowルールは、auto modeに入った時点で外れる点にも注意が必要です。auto modeに入るときに無効になるのは、次のルールです。Bash(*) のような全面許可。Bash(python*) のようなインタープリターのワイルドカード許可。パッケージマネージャーのrun系コマンド。Agent と Monitor のallowルール。Bash(npm test) のような狭いルールは残り、auto modeを抜けると外れたルールも戻ります。

つまり、npm run * のようなルールをこのスキルで生成しても、auto modeの間は効かない可能性があります。ルールが「効いていない」と感じたら、まずStatus barでモードを確かめます。Shift+Tab を押すと、auto mode on、manual mode on、accept edits on、plan mode on の順に切り替わります。

Manualモードで起動するフラグと、起動時だけ許可を足すフラグは、v2.1.287のclaude --helpに次の形で載っています。

$ claude --help
  --allowedTools, --allowed-tools <tools...>
      Comma or space-separated list of tool names to allow (e.g. "Bash(git *)
      Edit")
  --permission-mode <mode>              Permission mode to use for the session
                                        (choices: "acceptEdits", "auto",
                                        "bypassPermissions", "manual",
                                        "dontAsk", "plan")

--permission-mode manualで起動すれば、このスキルが最も効く条件を再現できます。--allowedToolsは、そのセッションの間だけルールを足す手段で、設定ファイルは書き換えません。

読み取り専用コマンドはそもそも一部が自動承認されている

次のコマンドは、組み込みの読み取り専用セットとして確認なしで動きます。ls cat echo pwd head tail grep find wc which diff stat du cd、それにgitの読み取り専用な使い方です。この一覧は設定で変更できません。確認を求めたいときは、そのコマンドに ask か deny のルールを足します。

Manualモードでは、この一覧に含まれるコマンドでもプロンプトが出る場合があります。

  • find sort sed git など、書き込み・実行系のフラグを持つコマンドに、クォートなしのグロブを渡したとき
  • 別のdaemonを指すフラグ(-H --context など)を付けた docker
  • file に -m や -f を付けたとき
  • PATH や IFS といった特殊なシェル変数を書き換えるコマンド
  • 解析しきれないコマンド、または1万字を超えるコマンド
  • Windowsで、ネットワーク(UNC)パス(\\server\share\file など)を引数に含むコマンド

cd を含む複合コマンドにも癖があります。cd packages/api && ls は、それぞれが読み取り専用なら確認なしで動きます。一方、別のディレクトリへ cd してから git を実行する場合は、そのディレクトリのフックが走りうるため確認が出ます。

cd の後にリダイレクトが続き、出力先がどのディレクトリ基準か判定できないときも、確認が出ます。2>/dev/null だけなら出ません。

つまり /fewer-permission-prompts が実質的に効くのは、この組み込みセットに含まれない読み取り専用コマンドと、MCPサーバー経由のツール呼び出しです。組み込みで通るコマンドをallowlistに書き足しても、効果は変わりません。

手作業の承認と、このスキルでは保存先が違う

ここが一番ずれやすい点です。「Yes, and don't ask again」を押したときの保存先と、/fewer-permission-prompts の書き込み先は別のファイルです。

くらべる

許可ルールが保存される場所

手作業の承認

Yes, and don't ask again

.claude/settings.local.json に保存されます。場所はgitリポジトリのルートで、worktreeからでもメインのチェックアウトに解決されます。gitignore対象なので、チームには共有されません。

スキルの一括生成

/fewer-permission-prompts

プロジェクトスコープの .claude/settings.json に書き込みます。gitにコミットすると、リポジトリの全コラボレーターに適用されます。

Claude Codeの設定は、User・Shared project・Project local・Managedの4スコープに分かれています。個人の作業環境だけで許可を増やしたいなら、生成されたルールを .claude/settings.local.json(Project localスコープ)へ手動で移します。コミット前にレビューして、チーム共有してよい範囲かを確かめる運用も安全です。

実行後の確認手順

生成されたルールは、そのまま信用せず、次の流れで確かめます。

手順

実行後の確認

  1. 1

    差分を見る

    git diff .claude/settings.json で、追加された permissions.allow のエントリを確認します。

  2. 2

    /permissionsで由来を確認する

    /permissions ダイアログは、現在有効な全ルールと、それぞれがどの設定ファイル由来かを一覧にします。

  3. 3

    広すぎるルールを探す

    環境ランナー経由(devbox run * など)や、書き込み系のコマンドが混ざっていないかを見ます。

  4. 4

    共有範囲を決める

    チームに配るならコミットし、自分だけで使うなら .claude/settings.local.json へ移します。

生成されたルールを読むときに要る評価の仕組み

/fewer-permission-prompts が追加するのは permissions.allow のエントリです。Bashのルールはワイルドカード * によるパターンマッチで、Bash(npm run test *) は npm run test で始まるコマンドに一致します。

評価順序はdeny→ask→allowの固定順です。生成されたallowルールがあっても、既存のdeny/askルールが常に優先されます。「常に許可」を選んでも聞かれ続ける原因は他にも複数あり、Claude Codeのalways allowが効かない原因と対処法で切り分け方をまとめています。

複合コマンド(&& || ; | など)は、サブコマンドごとに評価されます。allowは全サブコマンドに一致が必要で、denyとaskは1つでも一致すれば全体に効きます。cd /tmp && git clean -f は、Bash(git clean *) のaskルールにより、auto modeでも確認が出ます。承認時に保存されるのは、承認が必要だったサブコマンドのルールだけです。

timeout time nice nohup stdbuf といったラッパーは、マッチングの前に取り除かれます。Bash(npm test *) は timeout 30 npm test にも一致します。

一方、devbox run direnv exec mise exec npx docker exec のような環境ランナーは取り除かれず、Bash(devbox run *) は後ろに続く任意のコマンドに一致します。スキルが生成したルールにランナー経由のものが混ざっていたら、広がりすぎていないかを確かめます。watch setsid ionice flock の実行ラッパーや、-exec -delete 付きの find は、前方一致ルールでは通りません。

MCPツールはサーバー単位かツール単位で許可される

/fewer-permission-prompts はBashだけでなくMCPのツール呼び出しも走査対象にします。MCPの許可ルールは、サーバー名だけを書くか、その後ろにツール名を続けるかの2段階で指定します。

  • mcp__puppeteer はpuppeteerサーバーが提供する全ツールに一致します
  • mcp__puppeteer__* もワイルドカード構文で、同様に全ツールへ一致します
  • mcp__puppeteer__puppeteer_navigate は、puppeteerサーバーの puppeteer_navigate ツールだけに一致します

どの粒度で生成されるかは、トランスクリプトの使用傾向で変わります。実行後は /permissions を開いて、実際に追加されたルールの粒度を見ます。狭いルールほど、まだ使っていない別のツールを誤って許可せずに済みます。

組織のclaude.aiコネクタがそのツールを ask に設定していて、その設定がセッションに届いている場合は、allowルールを足しても効果がありません。auto モードや bypassPermissions モードでも毎回確認が出て、dontAsk モードではその呼び出し自体が拒否されます。スキルが生成したルールも、この組織設定の上からは書き換えられません。

生成されたルールの落とし穴

Bashのルールはコマンド文字列に対するパターンなので、引数を絞る意図で書いても、別の書き方をすり抜けられます。たとえば「curlの宛先をgithub.comに絞りたい」と考えて Bash(curl http://github.com/ *) を書いても、次のコマンドには一致しません。

  • オプションがURLより前に来る場合(curl -X GET http://github.com/...)
  • プロトコルが違う場合(https://github.com/...)
  • リダイレクトを経由する場合(curl -L http://short.example.com/xyz)
  • 変数を経由する場合(URL=http://github.com && curl $URL)

スキルはトランスクリプトに実際に現れたコマンド文字列からルールを起こします。生成された時点のルールは、将来使われる別の書き方まではカバーしません。自動生成だからといって、安全な範囲に収まるとは限りません。

ネットワークアクセスを厳密に絞りたいなら、別のアプローチが確実です。curl や wget をdenyルールでブロックし、許可したいドメインだけを WebFetch(domain:github.com) のようなWebFetchのルールで通します。

手動でallowlistを書く場合との違い

/fewer-permission-prompts は実際の使用パターンから逆算してルールを作ります。最初に方針を決める手動の設計とは、出発点が逆です。

方法向いている場面注意点
/fewer-permission-prompts向いている場面セッションを重ねて、繰り返し許可しているコマンドが溜まっている注意点まだ使っていないコマンドは拾えない
手動でallowlistを設計向いている場面プロジェクト開始時に方針を決めたい、チームの合意を明文化したい注意点スペースの有無で単語境界が変わるなど、ワイルドカードの挙動を理解して書く必要がある

settings.json の全項目を体系的に把握したいときは、Claude Code settings.json完全ガイドが参考になります。Claude Code以外のAIコーディングエージェントと権限モデルを比べたいときは、AIコーディングエージェント権限モデル比較で設計思想の違いを整理しています。

まとめ

auto modeで使っている間は、このスキルで減るプロンプトはほとんどありません。Manualモードで、組み込み外のコマンドやMCPツールの確認が多いときに使うコマンドです。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →