自作したコマンドを走らせるたびに「このコマンドを実行していいですか」と聞かれる。3回目くらいで、確認そのものが作業になってきます。
かといって全部を許可すると、意図しない操作まで通ってしまう。この中間を作るのが allowed-tools です。コマンドのファイル先頭にある設定欄(フロントマター)に書きます。ただし効き方に癖があって、そこを知らずに使うと「許可したはずなのにまた聞かれる」ことになります。
許可は「呼んだそのターンだけ」効く
いちばん誤解しやすいのがここです。
allowed-tools に書いた道具は、そのコマンドを呼んだターンのあいだだけ確認なしで使えます。あなたが次のメッセージを送った時点で、許可は切れます。
---
description: 変更をステージ(コミットする対象として選ぶこと)してコミットする
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *)
---
allowed-tools は 道具名(対象) の形で書き、* は「以降は何でも」を意味します。このコマンドを呼べば、その流れの中では git add も git commit も聞かれません。ですが会話を続けて次の指示を出すと、許可は消えています。もう一度コマンドを呼べば、また効きます。
一方でコマンドの本文そのものは、セッションのあいだ文脈に残り続けます。 指示は残るのに許可は切れる。この非対称が「さっきは通ったのに」の正体です。
セッション全体で許可したいなら、コマンド側ではなく権限設定に許可の規則を足すのが筋です。権限設定は /permissions で開けるほか、設定ファイルに直接書くこともできます。
許可であって、制限ではない
もう1つ間違えやすいのが方向です。ここでいう道具は、ファイルを読む Read、文字を探す Grep、コマンドを走らせる Bash といった、Claude Codeが持っている機能のことです。allowed-tools は書いた道具の確認を省くもので、書かなかった道具を使えなくするものではありません。
ここに Read と Grep だけを書いたとしても、Claudeが Bash を使えなくなるわけではありません。Bash は今までどおり、あなたの権限設定に従って確認を挟みながら使えます。絞り込みのつもりで書くと、想定と違う動きになります。
取り上げたいときは別の項目を使う
では本当に使わせたくない場合はどうするか。disallowed-tools を使います。こちらは書いた道具を、そのコマンドを呼んだターンのあいだClaudeの手元から外します。
用途がはっきりしているのは、人に確認せず走らせたいコマンドです。放っておくと質問を返してくるようなものから AskUserQuestion を外しておけば、途中で止まらずに最後まで進みます。
こちらも次のメッセージで解除されます。すべての場面で禁じたいなら、権限設定の拒否規則に書くほうが確実です。なお会話を終える道具(EndConversation)だけは、ほかの道具が残っている限り取り上げられない決まりになっています。
途中で止めずに走らせる話は、繰り返しの上限とセットで考えると分かりやすいです。
同梱したスクリプトを、確認なしで走らせる
実用でよく効く組み合わせがあります。コマンドと一緒に置いたスクリプトを、確認なしで呼べるようにする書き方です。
---
description: CSVからグラフを描く
allowed-tools: Bash(${CLAUDE_SKILL_DIR}/scripts/render.sh *)
---
`${CLAUDE_SKILL_DIR}/scripts/render.sh <csvファイル>` を実行してグラフを描いてください。
scripts/render.sh は自分で用意して、SKILL.md と同じディレクトリの下に置きます。${CLAUDE_SKILL_DIR} はそのコマンドが置かれているディレクトリを指します。ポイントは、この置き換えが本文だけでなく allowed-tools の中でも行われることです。両方が同じ実際のパスに展開されるので、許可の条件と実際に走るコマンドがぴったり一致し、確認が出ません。
相対パスで書くと、どのディレクトリから呼ぶかで結果が変わります。私はこれで、動く日と動かない日がある状態をしばらく放置していました。この変数に変えてから揺れが止まりました。
allowed-tools の中での置き換えに対応したのは Claude Code v2.1.129 からです。それより古いと ${CLAUDE_SKILL_DIR} が文字列のまま残り、条件に一致しません。claude --version で確認できます。
リポジトリのコマンドを信頼するということ
チームで使う場合、見落としやすい点があります。
リポジトリの .claude/skills/ に置かれたコマンドの allowed-tools は、そのフォルダを信頼するかどうかの確認に同意した後で効きはじめます。 設定ファイルに書いた権限規則と同じ扱いです。
裏を返すと、リポジトリを信頼した時点で、そこに入っているコマンドは自分に広い権限を渡せる状態になります。他人のリポジトリを開いて信頼を許可する前に、.claude/ の中に何が入っているかを一度見ておくほうがいいです。中身はただのMarkdownなので、読むのに専門知識は要りません。allowed-tools の行だけ追えば十分です。
シェルの実行そのものを止める設定もある
コマンドの中には、Claudeに渡す前にシェルを走らせる書き方があります。バッククォートの前に ! を付ける記法で、別記事で詳しく扱いました。便利な反面、リポジトリから配られたコマンドが勝手にコマンドを走らせる、という形にもなります。
組織として止めたい場合は disableSkillShellExecution を true にします。対象は利用者・プロジェクト・プラグイン由来のスキルとカスタムコマンドで、該当箇所は実行されず [shell command execution disabled by policy] という文字に置き換わります。管理者が配る設定に書いておけば、利用者側では上書きできません。Claude Codeに最初から入っているスキルと、管理者側で配っているスキルには影響しません。
確認の回数を、どこで減らすか
整理すると、選択肢は3つあります。
コマンドを呼ぶ流れの中だけ楽にしたいなら allowed-tools。毎回の作業すべてで楽にしたいなら権限設定の許可規則。特定の道具を確実に触らせたくないなら disallowed-tools か拒否規則。
私は最初、全部を allowed-tools に書こうとして失敗しました。次のメッセージで切れるので、会話が続く作業では結局また聞かれます。一連の流れで完結するコマンドにはこちらが向いていて、普段づかいの許可は権限設定側に置く。 この住み分けにしてから、確認の回数と安心感の折り合いがつきました。
