権限ルール

Claude Code は、ツールごとに「聞かずに使う」「必ず聞く」「使わせない」をルールで細かく決められます。ルールはバージョン管理に入れてチームで共有でき、各自が自分用に足すこともできます。このページは、権限の仕組み・ルールの書き方・作業ディレクトリ・ワークスペースの信頼をまとめています。権限モードの使い分けは 権限モード、設定キーは 設定キー一覧 を見てください。

• ルールは deny → ask → allow の順に評価され、最初に一致したものが決まる（具体的かどうかは関係ない）
• ルールの形は Tool か Tool(指定子)。ツール名だけなら、そのツールのすべての使用に一致する
• 権限ルールを強制するのは Claude Code で、モデルではない。プロンプトや CLAUDE.md の指示は Claude が試すことを左右するが、Claude Code が許すことは変えない
• /permissions で全ルールと、各ルールがどの settings.json から来たかを確認・編集できる
• Bash のルールは、コマンドの文字列に対する照合で、セキュリティ境界ではない。OS レベルで止めるなら サンドボックス を使う

権限の仕組み#

ツールの種類ごとに、手動（Manual）モードで実行前に確認が出るかを示します。ほかの 権限モード は、どれを確認するかを変えます。auto mode では確認の代わりに分類器が審査します。

権限の確認は、Claude がこれからすることと、そのあとの選択肢を示します。Manual モードのセッションでの Bash コマンドの確認は、たとえば次の形です。

• 題は「Bash command」。auto mode についてのヒントの下に、説明（「Run the test suite」）、コマンド（npm test）、「This command requires approval」の行が出る
• 「Do you want to proceed?」に4つの選択肢：「Yes」・「Yes, and don't ask again for: npm test *」・「Yes, and switch to auto mode」・「No」
• フッターのキーは、Esc でキャンセル、Tab で修正

3つ目の「Yes, and switch to auto mode」は、すべての確認に出るわけではありません。

• 「Yes, and don't ask again」で恒久の承認（Bash コマンドや WebFetch のドメインなど）を選ぶと、ルールは git リポジトリのルート（worktree はメインのチェックアウトに解決）の .claude/settings.local.json に保存され、そのリポジトリのどこで始めたセッションにも効く。ファイル変更の承認はファイルに保存されず、セッションの終わりまで
• git リポジトリの外や Windows などではリポジトリのルートを使わない場合がある
• v2.1.211 より前は、開始ディレクトリに保存していたため、worktree やサブディレクトリでの承認がリポジトリの他の場所に効かなかった。以前のバージョンがサブディレクトリや worktree に保存したルールは、そこで始めたセッションでは引き続き効く
• 確認が 1 回きりの承認しか出さないことがある。ルールで許すものを確認画面が全部見せられるときだけ「don't ask again」などを出すため。1 回承認するか、/permissions でルールを自分で足す

権限確認にコメントを付ける#

1 件のアクションを承認・拒否するとき、Claude にメモを添えられます。Bash・PowerShell・ファイル・MCP ツールなどの確認で、「Yes」か「No」に移動して Tab を押すと、その選択肢にコメント欄が開きます。WebFetch とブラウザの確認では使えず、セッション中の許可やルールの保存の選択肢にもありません。

• Enter：コメントを付けて答えを送る。欄が空ならコメントなしで送る
• Tab：答えずに欄を閉じる。入力したテキストは残り、その選択肢で答えたときに送られる
• Shift+Tab：ファイルの確認（Edit・Write）では Tab と同じく欄を閉じる。v2.1.235 より前は、欄の中での Shift+Tab がセッション中の許可の選択肢を選び、コメントを捨てていた
• 「Yes」を選ぶとアクションを実行し、結果のあとにコメントを Claude に送る。「No」を選ぶとコメントを拒否の理由として送り、Claude は作業を続ける。メイン会話の確認でコメントなしの「No」を選ぶと、ターンが止まる

権限の管理#

/permissions で全ルールとその設定元のファイルを確認できます。Claude の作業中にも開け、ルールを足す・消すと、同じターンの Claude の次のツール呼び出しから反映されます（v2.1.234 より前はターンの終わりまで待たされた）。auto mode が使えるセッションでは、「Auto mode」タブで分類器のルールも見られます。

• 評価順は deny → ask → allow で、最初の一致が決まる。具体性は順序を変えない
• Bash(aws *) のような広い deny は、Bash(aws s3 ls) のような狭い allow にも一致する呼び出しをすべてブロックする。allow は deny の例外を作れない。ask と allow の間も同じで、一致する ask があれば、より具体的な allow があっても確認が出る
• ツール名だけの deny（Bash など）は、そのツールを Claude のコンテキストから外し、Claude には見えなくなる。セッション途中に足しても、次のツール呼び出しから呼べなくなる。Bash(rm *) のようにパターンを絞った deny はツールを残し、一致する呼び出しをブロックする
• ツール名だけの除去は EndConversation を除くすべてのツールに及ぶ（deny は、ほかのツールが残っているあいだ EndConversation を外せず、ask も確認を出さない）

権限モード#

• 開始モードは設定の defaultMode で変える
• bypassPermissions や auto を使えなくするには、どの設定ファイルでも permissions.disableBypassPermissionsMode や permissions.disableAutoMode を "disable" にする。上書きされない管理設定で使うのが効果的

ルールの書き方#

ルールの形は Tool か Tool(specifier) です。指定子の中の丸括弧は文字どおりに扱われるので、括弧を含むコマンドやパスにエスケープは要りません。

ツールのすべての使用に一致させる#

ツール名だけを書きます（丸括弧なし）。

Bash(*) は Bash と同じです。deny では、どちらの形もツールを Claude のコンテキストから外します。

指定子で絞る#

入力パラメーターで絞る#

deny と ask のルールは、組み込みツールなら Tool(param:value) で最上位の入力パラメーターに一致させられます。

• パラメーター名は、ツールの入力の直下のフィールド（Agent ツールの model など）でなければならない。オブジェクトや配列の中のフィールドには一致させられない
• 1 つのルールで名指しできるパラメーターは 1 つ。model と isolation の両方で絞るなら、ルールを 2 つ書く
• 値には * が使える（任意の文字列）。Agent(isolation:*) は明示された任意の isolation 値に一致。* が無ければ完全一致
• モデルが省いたパラメーターには一致しない。Agent(model:*) は model を指定しない呼び出しに一致しない
• 値は、正規化の前の、Claude が送る入力そのものと比べられる。Agent(model:opus) はエイリアス opus に一致するが、完全なモデル ID には一致しない
• Skill(skill:<name>) の deny は、別名や表示名など、スキルのどの名前にも一致する
• --verbose で、各ツール呼び出しの正確なパラメーター名と値が見える
• コロンの前後の空白は無視される
• MCP ツールのパラメーターに一致させるには、--disallowedTools で deny ルールを渡す。設定ファイルの括弧付きの mcp__ ルールは読み込み時にスキップされ、対話セッション開始時の無効設定ダイアログと claude doctor に出る
• ツールの主な内容フィールド（Bash・PowerShell の command、Read・Edit・Write の file_path、Grep・Glob の path、NotebookEdit の notebook_path、WebFetch の url）には使えない。Bash(command:rm *) は複合コマンドで回避できるため、Claude Code は無視して起動時に警告する。代わりに Bash(rm *)・Read(./path)・WebFetch(domain:host) を使う

ワイルドカード（Bash）#

Bash ルールの * は、空白を含む任意のテキストに一致するので、1 つのルールでコマンドの一族を覆えます。* が無いルールは、そのコマンドちょうどに一致します。

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "deny": ["Bash(git push *)"]
  }
}

この設定では、npm のスクリプトと git commit は聞かずに実行され、git push で始まるコマンドは拒否されます。別の書き方の push（git -C . push など）には一致しません。

* はルールの先頭・途中・末尾のどこにも置けます。

• * は、その位置にあるどんなテキストにも一致する。Bash(git * main) では * がサブコマンドの位置にあるので、すべての git サブコマンドと、その前のすべてのオプション（git が指定のプログラムを実行する -c を含む）に一致する。Bash(* --version) ではプログラム名の位置なので、どのプログラムにも一致する
• 末尾の、空白の前の * は、引数なしのコマンドにも一致する（Bash(ls *) は ls に、Bash(git log *) は git log に一致）。これは末尾の * がルールで唯一のワイルドカードのときだけ（Bash(* --help *) は npm --help に一致しない）
• 末尾の * の前の空白はルールの一部。Bash(ls *) は ls の後ろの空白が必要で lsof に一致せず、Bash(ls*) は空白がないので lsof にも一致する
• :* の接尾辞は末尾のワイルドカードの同等の書き方（Bash(ls:*) は Bash(ls *) と同じ）。パターンの末尾でしか認識されず、Bash(git:* push) ではコロンが文字として扱われ、git コマンドに一致しない
• 権限ダイアログで、コマンドの接頭辞に「Yes, and don't ask again」を選ぶと、空白区切りの形で書かれる

ツール名のワイルドカード#

deny と ask のルールは、ツール名の位置に glob パターンを使えます。パターンはツール名全体に一致しなければなりません（"*" は全ツール、"mcp__*" は全サーバーの全 MCP ツール）。

{
  "permissions": {
    "deny": ["mcp__*"]
  }
}

• ツール名だけの glob の deny で一致したツールは、ツール名だけの deny と同じく Claude のコンテキストから外れる（EndConversation の例外も同じ）
• allow ルールでツール名の glob が使えるのは、リテラルの mcp__<server>__ 接頭辞のあとだけ。サーバーの部分に glob は使えず、設定した特定のサーバーを指す。mcp__puppeteer__* は puppeteer サーバーの全ツール、mcp__github__get_* はその get_ で始まるツールに一致する。"*"・"B*"・"mcp__*" のような接頭辞に固定されていない allow の glob は、警告つきでスキップされ何も自動承認しない
• ツール名が既知のツールのどれにも一致しない deny／ask のルールは、タイプミスを見つけるため起動時に警告される（名前に _ や * を含むものと、削除済みのツール（TaskOutput など）は対象外）
• トランスクリプトや権限ダイアログに出るツールのラベルは、正式名と違うことがある（ラベル Stop Task の正式名は TaskStop）。ルールとフックのマッチャーはラベルに一致しないので、ツール一覧 の正式名を使う

ツールごとのルール#

Bash#

Bash のルールはコマンド全体の文字列に一致し、* が任意のテキストの代わりになります。

複合コマンド#

• deny と ask のルールは、どれかのサブコマンドが一致すれば適用される（サブシェル・コマンド置換・for ループなど制御フローの本体の中のコマンドを含む）。Bash(git clean *) の ask は、cd /tmp && git clean -f や echo "$(git clean -f)" でも、auto mode でも確認を出す
• npm test && のように &&・|| の後ろが空だと、解析できないコマンドとして扱われ、allow ルールの照合のためにサブコマンドへ分けられない（Bash(npm *) は承認しない）
• 複合コマンドを「Yes, and don't ask again」で承認すると、複合の文字列全体でなく、承認が必要な各サブコマンドごとにルールが保存される（git status && npm test なら npm test のルール）。作業ディレクトリの外へ cd するサブコマンドは、そのパスの Read ルールが作られる。1 つの複合コマンドで保存されるルールは最大 5 つ

ラッパー#

Bash ルールの照合の前に、固定のラッパーが取り除かれます。Bash(npm test *) は timeout 30 npm test にも一致します。

• 取り除かれるのは timeout・time・nice・nohup・stdbuf、シェル組み込みの command・builtin、zsh の noglob。いずれも引数を実際のコマンドとして実行する。コマンドを探すだけの command -v と、zsh の nocorrect は取り除かれない
• 既知の安全な環境変数の先頭の代入も取り除かれる（Bash(npm test *) は NODE_ENV=test npm test に一致）。ほかの変数の代入を越えては allow は一致しない。deny と ask は、どの先頭代入も越えて一致する（deny の Bash(rm *) は FOO=bar rm -rf tmp/ にも一致）
• フラグ無しの xargs も取り除かれる（Bash(grep *) は xargs grep pattern に一致）。xargs -n1 grep pattern のようにフラグ付きなら xargs コマンドとして照合され、内側のコマンドのルールでは覆えない
• このラッパーのリストは組み込みで、設定できない。direnv exec・devbox run・mise exec・npx・docker exec などの環境ランナーは含まれない。これらは引数をコマンドとして実行するので、Bash(devbox run *) は devbox run rm -rf . にも一致する。環境の中の作業を承認するには、ランナーと内側のコマンドの両方を含む具体的なルール（Bash(devbox run npm test)）を、内側のコマンドごとに書く
• watch・setsid・ionice・flock などの exec ラッパーは、Bash(watch *) の接頭辞ルールで自動承認できず、Manual モードでは必ず確認が出る。-exec や -delete 付きの find も同様で、Bash(find *) では覆えない。特定の呼び出しを承認するには、コマンド全体の完全一致ルールを書く

Bash ルールが一致しないもの#

Bash ルールは、Claude が書くコマンドの文字列に（複合コマンドの分割とラッパーの除去のあとで）一致します。同じプログラムの別の呼び出し方には一致しないので、deny や ask は、Claude が通常出す呼び出しを覆うだけで、プログラムの周りのセキュリティ境界ではありません。

• 右の列のコマンドは、ほかのルールと権限モードが決める
• コマンドの文字列に依存しないファイルシステムとネットワークの強制には、サンドボックスを使う。実行前にコマンド全文を自前のロジックで検査するなら PreToolUse フックを使う

読み取り専用コマンド#

組み込みの Bash コマンドの一式は読み取り専用と認識され、どのモードでも権限確認なしで動きます（permissions.blockReadsOutsideWorkingDirectories が作業ディレクトリ外のパスについて変えるものを除く）。ls・cat・echo・pwd・head・tail・grep・find・wc・which・diff・stat・du・cd と、git の読み取り専用の形が含まれます。この一式は設定できません。確認を出したいコマンドには ask か deny のルールを足します。auto mode では、これらのコマンドも分類器の審査を待つことがあります。

• ls > out.txt のようなリダイレクトは、対象への検査が加わる
• すべてのフラグが読み取り専用のコマンドでは、クォートされていない glob も許される（ls *.ts・wc -l src/*.py は確認なしで動く）

Manual モードでも、この一式のコマンドが確認を出す場合があります。

• クォートされていない glob を、書き込み・実行可能なフラグを持つコマンド（find・sort・sed・git など）で使うとき（glob が -delete のようなフラグに展開されうるため）
• docker が別のデーモンを指すとき：-H・--context、Podman の --url・--connection など別のデーモンを選ぶフラグがある読み取り専用の形
• file が -m/--magic-file か -f/--files-from を渡すとき（フラグの値のパスを開くため）
• Windows でネットワークパス：引数にネットワーク（UNC）パス（\\server\share\file）を含むコマンド（Windows の資格情報がそのホストへ送られうるため）。PowerShell ツールにも同じ検査がある
• PATH・IFS など特定の特殊なシェル変数を設定・解除・ループするコマンド
• 解析しきれないコマンド：読み取り専用として扱わず確認する。10,000 文字を超えるコマンドは常に確認が出る
• 作業ディレクトリか追加ディレクトリの中への cd も読み取り専用で、cd packages/api && ls のような複合コマンドは、各部分が単独で適格なら確認なしで動く。次の組み合わせは、各部分が読み取り専用でも確認が出る：cd と git（別のディレクトリへ cd すると、新しいディレクトリのフックが実行されうるため。現在の作業ディレクトリに解決される cd は何もしないので確認は出ない）、cd とリダイレクト（cd のあとにリダイレクト先がどのディレクトリを基準に解決されるか決められないとき。リダイレクト先が /dev/null だけのコマンド、例えば cd app; grep -r pattern . 2>/dev/null は確認が出ない）

より確実な URL の制限には、次の方法があります。

• Bash のネットワークツールを制限する：deny で curl・wget などを止め、許可するドメインは WebFetch(domain:github.com) で許す。deny はパス指定や sh -c の中の同じプログラムには一致しないので、制限を守りたいときはサンドボックスのネットワーク許可リストと組み合わせる
• PreToolUse フックで、Bash コマンドの URL を検査して許可されないドメインをブロックする
• CLAUDE.md に許可する curl のパターンを書く（Claude が試すことを左右するだけで境界ではないので、上のどれかと組み合わせる）
• WebFetch だけではネットワークアクセスは止まらない。Bash が許可されていれば、Claude は curl・wget などで任意の URL に届く

リダイレクト#

コマンドが出力や入力をリダイレクトするとき、Claude Code は、Claude がそのファイルを直接書く・読むのと同じように、リダイレクト先をファイルのルールに照らして検査します。

• 出力のリダイレクト（> file・>> file・2> file）：Edit の allow・deny ルール、保護されたパス、作業ディレクトリを検査する。Bash(git commit *) のようなルールはコマンドを許すが、リダイレクト先は許さない。~ で始まる、または glob 文字を含む先は承認が要る
• 入力のリダイレクト（< file）：Read の allow・deny ルールと作業ディレクトリを検査する。作業ディレクトリの外の先は、allow ルールが覆わないかぎり承認が要る。glob を含む先と、同じコマンド内の cd に続く相対パスは、allow ルールが覆っていても承認が要る。入力先の検査は v2.1.257 以降
• ファイルの実体がない先は検査されない：/dev/null・2>&1 や <&3 のようなファイル記述子の形・ヒアドキュメント・ヒアストリング
• tee が書くファイルも検査される（make | tee build.log のようなパイプラインも）。Edit の allow・deny ルール・保護されたパス・作業ディレクトリが対象で、Bash(tee *) の allow は作業ディレクトリ外の先を覆わない。tee の先の検査は v2.1.269 以降

PowerShell#

PowerShell のルールは Bash と同じ形です。* のワイルドカードは任意の位置、:* の接尾辞は末尾の * と同じで、PowerShell だけ、または PowerShell(*) はすべてのコマンドに一致します。

{
  "permissions": {
    "allow": ["PowerShell(Get-ChildItem *)", "PowerShell(git commit *)"],
    "deny": ["PowerShell(Remove-Item *)"]
  }
}

• 一般的なエイリアスは照合の前に正規化される。cmdlet 名のルールは、そのエイリアスにも一致する（PowerShell(Get-ChildItem *) は gci・ls・dir にも一致）。照合は大文字小文字を区別しない
• PowerShell の AST を解析し、複合コマンドの各コマンドを独立に検査する。パイプライン演算子 |・文の区切り ;・PowerShell 7+ のチェーン演算子 && と || が複合コマンドをサブコマンドに分ける。複合コマンドが許されるには、ルールがすべてのサブコマンドに一致しなければならない

Read と Edit#

Claude のファイルツールがファイルやディレクトリを読むのを止めるには、そのパスの Read の deny ルールを足します（Read(./.env)・Read(./secrets/**)）。プロジェクトに .claudeignore があっても効かないので、その中身は Read の deny ルールへ移します。

• Edit のルールは、ファイルを編集するすべての組み込みツールに適用される。Read のルールは、Grep・Glob などファイルを読む組み込みツール、プロンプトの @file の言及、接続した IDE が共有する選択範囲と開いているファイルのコンテキストにも、ベストエフォートで適用される
• Read の deny は、同じパスの Edit・Write ツールもブロックする（新規ファイルの作成を含む）。NotebookEdit は対象外なので、どのツールにも変更させないパスには Edit の deny を足す。この検査は、編集が v2.1.208 以降、書き込みが v2.1.228 以降
• ファイルの権限は Edit(path) と Read(path) のルールだけで検査される。Write・NotebookEdit・Glob・旧 MultiEdit のパスルールは、受け付けるが参照されず、起動時に警告される（--allowedTools で渡す Glob ルールを除く）。Write(docs/**) の代わりに Edit(docs/**)、Glob(docs/**) の代わりに Read(docs/**) を使う。パスのないツール名だけのルール（Write の deny など）は警告されず、ツール単位ですべてに一致する。v2.1.210 以降

Read と Edit のルールは、gitignore のパターン構文で、4 種類のパターンがあります。

/path のパターンは、定義した設定元に対応するディレクトリに固定されるので、同じルールでも置く場所で一致する場所が変わります。

• /permissions で足したルールは、保存先の設定ファイルの行に従う
• ローカル設定のルールは、v2.1.211 以降、Claude Code がファイルを保存するリポジトリのルートでなく、セッションのプライマリ作業ディレクトリに固定される。リポジトリのルートで始めたセッションでは同じで、worktree のセッションでは、Edit(/src/**) のような共有ルールがその worktree 自身の src/ に一致する
• ユーザー設定の Read(/secrets/**) の deny は、プロジェクトの secrets ディレクトリでなく ~/.claude/secrets/** をブロックする。ユーザー設定で全プロジェクトに効くルールを書くには、// の絶対パスか ~/ のホーム相対パスを使う
• Windows ではパスは照合の前に POSIX 形式に正規化される（C:\Users\alice は /c/Users/alice）。そのドライブの任意の .env には //c/**/.env、全ドライブには //**/.env

例：

• Edit(/docs/**)：<primary working directory>/docs/ の編集（/docs/ や <primary working directory>/.claude/docs/ ではない）
• Read(~/.zshrc)：ホームディレクトリの .zshrc の読み取り
• Edit(//tmp/scratch.txt)：絶対パス /tmp/scratch.txt の編集
• Read(src/**)：allow では <current-directory>/src/ のみ。deny と ask ではカレントディレクトリ以下の任意の深さの src ディレクトリに一致

ルールは固定位置の下のファイルにだけ一致し、その範囲で一致の深さはパターンの形と（1 セグメントのディレクトリパターンでは）ルールの種類で決まります。素のファイル名は gitignore の意味で任意の深さに一致するので、Read(.env) と Read(**/.env) は同じです。

src/** のように 1 つのディレクトリセグメントだけの相対パターンは、ルールの種類で一致する深さが違います。

• allow：Edit(src/**) は <cwd>/src とその下のファイルにだけ一致する。任意の深さのディレクトリ名を許すには Edit(**/src/**)
• deny と ask：Read(secrets/**) はカレントディレクトリ以下の任意の深さの secrets ディレクトリに一致するので、入れ子のコピーにも適用される
• そのほかのパターンの形は、どのルールの種類でも同じ深さで一致する（Edit(/src/**) と Edit(src/components/**) は固定された場所だけ、Edit(**/src/**) は任意の深さ）

トップレベルに src/ があり、vendor/ の下にもコピーがあるプロジェクトでは、次のようになります。

• gitignore パターンでは、* は 1 つのパスセグメントの中で一致し、どの位置にも置ける。** はディレクトリをまたいで一致する
• 「Yes, and don't ask again」でファイルパスを承認すると、そのパスの gitignore の特殊文字（[・]・* など）がエスケープされ、生成されたルールは承認したリテラルなパスだけに一致する。自分で書くルールはエスケープされない。v2.1.202 より前はエスケープされず、2024-06 Reports のようなディレクトリのルールが自分のパスに一致しなかったり、兄弟ディレクトリに意図せず一致したりした
• パスの丸括弧にエスケープは要らない（Edit(./Finance (2024)/**) は Finance (2024) フォルダに一致する）
• gitignore のパターンとして使えないパスの deny／ask は、その正確なパスを守る。使えないパターンの allow は何も承認しない
• ! で始まる deny／ask のパターンは gitignore の否定で、それより前に並べた path や ./path のルールから、一致するパスを除外する。1 つの設定ファイルの deny リストで Read(*.env) の後に Read(!sample.env) を置くと、任意の深さの .env で終わるファイルのうち sample.env を除いてブロックする。! のルールを先頭に置くと何も除外しない
• 除外は同じ設定元のルールにしか及ばない。プロジェクト設定や --disallowedTools の Read(!.env) は、管理設定や別の設定ファイルの Read(./.env) の deny を取り消さない
• ! のパターンが除外できる範囲には 2 つ限界がある：! の後に /・~/・// が続いても ! のパターンはカレントディレクトリからの相対として読まれるので、それらの接頭辞で固定されたルールには届かない（Read(!~/notes/public/**) は Read(~/notes/**) から何も除外しない）。ディレクトリ全体をブロックするルールの中のファイルを、除外で開き直すことはできない（Read(secrets/**) と Read(!secrets/public/**) では secrets/public も secrets のほかの部分と同じくブロックされる）

シンボリックリンク#

Claude が要求するファイルパスがシンボリックリンクを通るとき、権限の検査は、要求されたパスと、解決先のファイルの 2 つを対象にします。macOS・Linux・Windows のシンボリックリンクと、Windows のディレクトリジャンクに適用されます。

• allow ルール：要求されたパスと解決先のファイルの両方が一致するときだけ適用される。許可されたディレクトリ内の、外を指すシンボリックリンク経由の読み取りは一致しない
• deny ルール：要求されたパスか解決先のどちらかが一致すれば適用される。拒否されたファイルを指すシンボリックリンクは、それ自体が拒否される（Read(./project/**) を許可し Read(~/.ssh/**) を拒否していると、./project/key から ~/.ssh/id_rsa へのリンクは、解決先が allow に合わず deny に一致するのでブロックされる）
• macOS・Linux では、シンボリックリンクのディレクトリ経由で //・~/・/ のパターンで書いた deny／ask のルールは、そのディレクトリの実際の場所にも適用される（macOS で /etc は /private/etc に解決されるので、Read(//etc/**) は /private/etc/hosts もブロックする）。v2.1.268 より前は、実際の場所で指定したパスには適用されなかった
• Grep と Glob は path 引数が解決するディレクトリを検索し、Read の deny ルールはそのディレクトリに適用される
• 編集・書き込みを求められたパス自体がシンボリックリンクなら、Edit・Write ツールは書き込みを拒否し、リンクの対象へ向かうよう Claude に伝える
• 途中のディレクトリがシンボリックリンクの場合や、Bash・PowerShell コマンドが書き込む場合は、書き込みがリンクを通りうる。その場合は、書き込みの解決先が作業ディレクトリと保護されたパスに対してどこにあるかで決まる：作業ディレクトリの外に解決されるとき（要求パスは作業ディレクトリの中）、acceptEdits では自動承認されず、auto mode では allow ルールが承認しないかぎり分類器でなく確認が出る（確認は解決先のパスを示す）。要求パスが名指ししない保護されたパスに解決されるとき、保護されたパスの表が各モードの結果を示すが、表が分類器へ回す場合はこの書き込みは確認になる
• ディスク上で行き先を決められないとき（シンボリックリンクがループなど）、Read・Edit・Write は操作を拒否する。承認したファイルをツールが開くときは、パスが承認時と同じ場所に解決されることが再確認される

WebFetch#

WebFetch のルールは domain: 接頭辞を使い、リクエスト URL のホスト名に照合します。大文字小文字を区別せず、* ワイルドカードを使え、ルールとホスト名の両方の末尾の . は取り除かれます（example.com. と example.com は同じ）。

• WebFetch(domain:example.com)：example.com へのリクエストに一致
• WebFetch(domain:*.example.com)：任意の深さのサブドメイン（api.example.com・a.b.example.com）に一致し、example.com 自体には一致しない
• WebFetch(domain:*)：すべてのドメインに一致。ツール名だけの WebFetch とは別

先頭の *. と単独の * 以外の位置では、ワイルドカードは 2 つのドットの間のテキストにだけ一致します。WebFetch(domain:example.*) は example.org に一致しますが、ドットをまたぐ example.evil.com には一致しません（末尾のワイルドカードが、攻撃者が登録できるドメインに一致しないようにするため）。WebFetch のワイルドカードで取得に一致させるには v2.1.172 以降が必要です。

すべての取得を許可・拒否する#

ツール名だけの WebFetch（"deny": "WebFetch" など）と WebFetch(domain:*) は、どちらもすべての URL を覆いますが、動きが違います。domain: 形だけが、そのドメインをサンドボックスの許可・拒否ドメインのリストにも足します。

• アーティファクト（Artifact ツールが claude.ai に公開するページ）の読み取りでも違いが出る。ツール名だけの WebFetch の deny・ask は、その読み取りには適用されない。claude.ai や *.claudeusercontent.com のコンテンツホストを覆う domain: ルール（WebFetch(domain:claude.ai)・WebFetch(domain:*)）は、各読み取りを拒否するか確認する。Artifact ルールも同じ。ルールが読み取りをブロックしたとき、拒否の表示はルールを名指しする。v2.1.268 より前は、ツール名だけの WebFetch の deny がすべてのアーティファクトの読み取りをブロックし、ask がそれぞれの前に確認していた
• サンドボックスの許可リストを変えずに Claude に自由に取得させるには、ツール名だけの形を使う

{
  "permissions": {
    "allow": ["WebFetch"]
  }
}

ページの取得は確認なしで動きますが、サンドボックスの許可リストの外のホストに対するサンドボックス内の curl は、ツール名だけのルールがホストを許可リストに足さないので、そのホストについて確認が出ます。auto mode では、Claude は分類器が審査できるよう、コマンドごとの許可ドメインにそのホストを挙げます。

MCP#

MCP のルールは、Claude Code に設定されたサーバー名を使い、続けてそのサーバーのツール名を書けます。

• mcp__puppeteer：puppeteer サーバーが提供する任意のツールに一致

• mcp__puppeteer__*：ワイルドカード構文で、puppeteer サーバーの全ツールに一致

• mcp__puppeteer__puppeteer_navigate：puppeteer サーバーの puppeteer_navigate ツールに一致

• 組織が claude.ai コネクタのツールを ask にし、その設定がセッションに届いていると、そのツールの allow は効かない。auto や bypassPermissions でも毎回確認が出て、確認しない dontAsk では拒否される。Claude Code 自身が取得するコネクタのツールは mcp__claude_ai_<server>__<tool> の名前で出る

• Claude Desktop アプリの Cowork セッションでは、Claude は組み込みの Bash でなく Cowork の mcp__workspace__bash でシェルコマンドを実行し、Web 取得には mcp__workspace__web_fetch を使う。Bash や WebFetch のツール全体を指す deny は、これらの Cowork ツールにも適用される（管理設定の Bash の deny は、Cowork でのシェルコマンドも止める）。ブロックされたとき、メッセージは Cowork のツールを名指しする（Permission to use mcp__workspace__bash has been denied.）。allow は引き継がれない（Bash の allow は mcp__workspace__bash に適用されない）

Agent（サブエージェント）#

Agent(AgentName) のルールで、Claude が使えるサブエージェントを制御します。

• Agent(Explore)：Explore サブエージェント
• Agent(Plan)：Plan サブエージェント
• Agent(my-custom-agent)：my-custom-agent という名前のカスタムサブエージェント

特定のエージェントを無効にするには、設定の deny 配列か --disallowedTools フラグに足します。

{
  "permissions": {
    "deny": ["Agent(Explore)"]
  }
}

Cd#

Cd のルールは、/cd コマンドがセッションを移せるディレクトリを制御します。Cd はモデルが呼べるツールでなく、Claude は呼べません。ルールは自分が /cd を実行したときだけ適用されます。

• ツール名だけの Cd の deny は /cd を完全に無効にする。Cd(<path-pattern>) の deny は一致する移動先をブロックする。deny は、移動先のすべての書き方（解決するシンボリックリンクの各ホップを含む）を確認するので、1 つのパスで書いたルールは、そこに解決される移動先もブロックする
• Cd の allow を 1 つでも足すと、/cd は許可リストモードになり、解決された移動先ディレクトリがどれかの allow に一致しなければ /cd は拒否する。Cd ルールが無ければ、/cd は既定どおり、見慣れないディレクトリを信頼するか確認する
• パスのパターンは Read・Edit の //・~/・/ の固定を共有するが、照合は gitignore 流でなくディレクトリパス全体に固定される。* はちょうど 1 つのパスセグメント、** はセグメントをまたぐ。末尾の /** は、名指しされたルートにも一致する

フックで権限を拡張する#

フックは、実行時に権限を評価するシェルコマンドを登録する仕組みです。ツール呼び出しのとき、PreToolUse フックは権限確認の前に（EndConversation を除くすべてのツールで）動きます。フックの出力は、呼び出しを拒否する・確認を強制する・確認を省いて進めさせる、のいずれかにできます。詳しくは フックのリファレンス を見てください。

• PreToolUse フックの判断は権限ルールを回避しない。deny と ask のルールは、PreToolUse フックの戻り値に関係なく評価される。一致する deny はブロックし、一致する ask は、フックが "allow" や "ask" を返しても確認を出す（管理設定の deny を含め、deny 優先の順序が保たれる）
• その優先順位が及ぶのは、設定ファイルのフックと、プラグインの hooks/hooks.json のフック。インストールした Mod（モッド） が tool.check を扱うと、ルールと PreToolUse フックが決めたあとに答え、その答えがルールやフックの答えを置き換えうる
  • ask ルール：ask ルールが確認を出す呼び出しを、Mod が承認できる
  • PreToolUse フックのブロック：フックが管理設定にあるものでなければ、Mod が呼び出しを承認できる
  • auto mode の分類器：auto mode では、Mod が承認した呼び出しは、分類器の確認なしで動く
  • deny ルール：管理設定のあるマシンか、Team か Enterprise のプランでサインインしているときは、既定で deny ルールが Mod より強く、組織はこれを変えられる。それ以外では、deny ルールが拒む呼び出しを Mod が承認できる
  • 詳しくは、Mod を使うの「信頼するかを決める」と、管理設定を配るときの「既定で何が起きるか」を見る
• requiresUserInteraction が付いた MCP ツールと、組織が ask にしたコネクタのツールも、フックが "allow" を返しても確認が出る
• ブロックするフックは allow ルールより優先される。終了コード 2 で終わるフックは、権限ルールが評価される前にツール呼び出しを止めるので、allow ルールが通すはずの呼び出しもブロックされる。一部を除いてすべての Bash コマンドを確認なしで動かすには、allow リストに "Bash" を足し、特定のコマンドを拒否する PreToolUse フックを登録する

作業ディレクトリ#

既定では、Claude は起動したディレクトリのファイルにアクセスできます。そのディレクトリは、/cd で移すまで、セッションのプライマリ作業ディレクトリです。アクセスは次の方法で広げられます。

• 起動時：--add-dir <path> の CLI 引数

• セッション中：/add-dir コマンド

• 恒久の設定：設定ファイルの additionalDirectories に足す

• 追加ディレクトリのファイルは元の作業ディレクトリと同じ権限ルールに従う（確認なしで読め、編集の権限は現在の権限モードに従う）

• UNC 共有（\\server\share）など、ほとんどのネットワークパスは作業ディレクトリに追加できない（調べるとそこで指すホストへ接続しうるため）。Windows では共有をドライブ文字に割り当て、そのドライブを起動時に --add-dir で渡す

• permissions.blockReadsOutsideWorkingDirectories を設定すると、ファイルツールが、囲われた外のパスをどの権限モードでも拒否する。auto mode では、Claude が作業ディレクトリの外を初めて読むとき、オンにするよう提案される

• macOS のバックグラウンドセッションでは、セッションのホストが、~/Desktop・~/Documents・~/Downloads などの保護されたフォルダへのアクセスを、ターミナルとは別に要求する。そこでの読み取りが Operation not permitted で失敗するなら、バックグラウンドセッションへのフォルダアクセスの許可が要る

セッションを別のディレクトリへ移す#

ディレクトリを並べて足すのでなく、プライマリ作業ディレクトリを移すには /cd <path> を実行します。会話は保たれ、新しいディレクトリの CLAUDE.md が読み込まれ、初めてのワークスペースなら信頼の確認が出ます。移したあと、新しいディレクトリで --resume すると移したセッションが見つかります。

移した時点で、新しいディレクトリのプロジェクト設定が適用されます。

• プロジェクト設定（権限ルールとフックを含む）
• .mcp.json のサーバー（起動時と同じサーバーの承認を経る）と、そこに登録したローカルスコープの MCP サーバー
• 設定が有効にするプラグイン・スキル・サブエージェント
• env の値（前のディレクトリの設定の環境変数の上に重ねられ、前のものも有効なまま）
• 前のディレクトリのプロジェクトとローカルスコープの MCP サーバーと、移したあとに有効でなくなったプラグインのサーバーは切断される。追加ディレクトリは前のものでなく新しいディレクトリの設定から取り、--add-dir・/add-dir で足したものは保たれる。移動が有効にしたフックには、セッションを始めたプロジェクトルートを指す ${CLAUDE_PROJECT_DIR} が渡る
• 新しいディレクトリがまだ信頼されていないとき、信頼の確認に、そのディレクトリの設定が有効にする allow ルール・追加ディレクトリ・フック・ヘルパーコマンドが一覧され、承認前に確認できる。断るとセッションは元の場所のまま。v2.1.246 より前は、セッションを再開するまで新しいディレクトリの設定・フック・MCP サーバー・スキルは適用されず、信頼の確認にも一覧されなかった
• /cd の移動先は Cd のルールで制限・無効化できる

追加ディレクトリはファイルアクセスを与えるだけで、設定は与えない#

ディレクトリを足すと、Claude が読み・編集できる場所が広がります。そのディレクトリが設定のルートになるわけではなく、.claude/ の設定の多くは追加ディレクトリからは検出されませんが、いくつかは例外として読み込まれます。例外は、--add-dir フラグか /add-dir コマンドで足したディレクトリ（Agent SDK がフラグ経由で足すものを含む）にだけ適用されます。設定ファイルの permissions.additionalDirectories に載せたディレクトリは、ファイルアクセスだけを与え、下の設定は何も読み込みません。

• Agent SDK の TypeScript の additionalDirectories オプションと Python の add_dirs オプションも例外を受ける（SDK が各項目を --add-dir として渡すため、フラグで足したディレクトリと同じに動く）。フラグで足したディレクトリのスキル・コマンド・サブエージェントは project の設定ソース経由で読み込まれるので、CLI の --setting-sources や SDK の settingSources でそのソースを除くと読み込まれず、bare mode ではそのうちコマンドとサブエージェントが読み込まれない
• プライマリ作業ディレクトリのサブディレクトリのスキル・コマンド・サブエージェントをセッション中に読み込むには、そのサブディレクトリのパスで /add-dir を実行する。確認も作業ディレクトリの追加もなしに、セッションの残りのあいだ読み込まれる（すでに読めるサブディレクトリのため）。v2.1.257 以降
• 出力スタイルは、現在の作業ディレクトリとその親、~/.claude/ のユーザーディレクトリ、管理設定から検出される。フックとほかの .claude/settings.json のキーは、現在の作業ディレクトリの .claude/ から（親ディレクトリへのフォールバックなし）、ユーザーの ~/.claude/settings.json と管理設定とともに読み込まれる。.claude/settings.local.json は、サブディレクトリで Claude Code を始めても git リポジトリのルートから読み込まれる（Windows などリポジトリのルートを使わない場合を除く。v2.1.211 より前は現在の作業ディレクトリだけ）

設定をプロジェクト間で共有するには、次の方法があります。

• ユーザー階層の設定：~/.claude/agents/・~/.claude/output-styles/・~/.claude/settings.json に置くと全プロジェクトで使える
• プラグイン：設定をパッケージ化して、チームがインストールできるよう配布する（プラグインを作って配る）
• 設定ディレクトリから起動する：読み込みたい .claude/ 設定を含むディレクトリで Claude Code を動かす

サンドボックスとの関係#

権限とサンドボックスは、補い合うセキュリティの層です。

• 権限：Claude Code が使えるツールと、アクセスできるファイル・ドメインを制御する。Bash・Read・Edit・WebFetch・MCP などすべてのツールに適用される（ほかのツールが残っているあいだ EndConversation を deny／ask でブロックできない点を除く）
• サンドボックス：シェルコマンドのファイルシステムとネットワークへのアクセスを OS レベルで強制して制限する。Bash・PowerShell・Monitor のコマンドとその子プロセスにだけ適用される
• プロンプトインジェクションが Claude の判断を迂回しても、サンドボックスの制限は効くので、両方を使って多層で守る。サンドボックスの設定と権限ルールのパスとドメインは、最終的なサンドボックス設定にマージされる
• サンドボックスを有効にして autoAllowBashIfSandboxed を既定の true のままにすると、権限に Bash だけの ask ルール（同等の Bash(*)）があっても、サンドボックス内の Bash コマンドは確認なしで動く（サンドボックスの境界が、ツール全体の確認の代わりになる）
• plan mode ではこの代替が働かない。ask ルールが無ければ、組み込みの読み取り専用コマンドは確認なしで動き、そのほかのシェルコマンドは計画中でも通常の権限の流れに従う。Bash だけの ask ルールがあれば、サンドボックス内の読み取り専用コマンドを含むすべての Bash コマンドで確認が出る（サンドボックスの外と同じ）。v2.1.212 より前は plan mode でも代替が働いた

これらの検査は引き続き適用されます。

• Bash(git push *) のような内容を絞った ask ルールは、確認を強制する
• 明示的な deny ルールは適用される
• 重要なパスを対象にする rm や rmdir は、通常の権限の流れに従う
• 除外されたコマンドなど、サンドボックス内で動かないコマンドは、Bash だけの ask ルールに従う

サンドボックスの動作の変え方は サンドボックス を見てください。

管理設定#

組織が一元管理するため、管理者が配る管理設定は、いくつかのセキュリティ上重要なキーを除き、ユーザー・プロジェクトの設定では上書きできません。配布の仕組みは 組織への導入と管理設定 を見てください。

• allowManagedPermissionRulesOnly は、管理設定を権限ルールの唯一の設定元にする。ほかのどの設定元を無視するかは 設定キー一覧 の項にある
• disableBypassPermissionsMode は通常、組織のポリシーを強制するため管理設定に置くが、どのスコープでも動く。ユーザーが自分の設定に書いて、自分を bypass モードから締め出すこともできる

設定の優先順位#

権限ルールは、ほかの Claude Code の設定と同じ設定の優先順位に従い、管理設定が最上位です。コマンドライン引数を含め、どの階層も管理設定の権限ルールを上書きできません。

• どこかの階層で拒否されたツールは、ほかの階層で許可できない。管理設定の deny は --allowedTools で上書きできず、--disallowedTools は管理設定の定義に加えて制限を足せる
• 設定スコープをまたいでも同じ：ユーザー設定が許可していてもプロジェクト設定が拒否していれば、deny がブロックする。逆も同じで、ユーザー階層の deny がプロジェクト階層の allow をブロックする（どのスコープの deny も allow より先に評価される）
• この優先順位は、設定ファイルとコマンドライン引数のあいだのものです。インストールした Mod に対して deny ルールが強いかは、「フックで権限を拡張する」を見る
• 組み込み先のホストは、SDK の managedSettings オプションで追加の管理ポリシー（管理者が allowManaged*Only のロックを設定していなければ allow ルールを含む）を与えられる

プロジェクトの allow ルールとワークスペースの信頼#

プロジェクトの .claude/settings.json の permissions.allow ルールと permissions.additionalDirectories は、権限を与えるので、そのフォルダのワークスペース信頼ダイアログを承認した後にだけ適用されます。ダイアログは、フォルダが与えるルールとディレクトリを一覧するので、事前に確認できます。deny と ask のルールは制限するだけなので、影響を受けません。

承認した信頼は、起動した場所に応じて、次のように保存されます。

• リポジトリの中：git リポジトリのルートに信頼が固定され、その中に入れ子の git リポジトリ（サブモジュールなど）を除いてリポジトリ全体に効く。worktree ではメインのチェックアウトのルートを使う（保存されたルールと同じ）
• リポジトリの外：起動したディレクトリに信頼が固定され、その下のサブディレクトリ（入れ子の git リポジトリ＝クローンを除く）に効く
• ホームディレクトリで起動したとき：信頼は現在のセッションだけで保持され、ディスクには書かれない
• 信頼ダイアログは対話セッションにだけ出る。claude -p や SDK のセッションには出ず、親フォルダを信頼してもこれらのルールには数えられない
• バックグラウンドセッションを始める・再起動する前にも、セッションが動くディレクトリのワークスペースの信頼が確認される。信頼していないディレクトリで claude --bg を実行すると、まず信頼ダイアログが出て、承認するとセッションが始まる。スクリプトなどダイアログが出せない場所では、コマンドは Workspace not trusted エラーで終了する

ローカル設定ファイルが信頼を要するとき#

.claude/settings.local.json は通常は自分のファイルなので、その allow ルールと追加ディレクトリは信頼の手順なしで適用されます。ファイルが git で追跡されている、または .claude がシンボリックリンクの場合は、リポジトリが供給したものとして、フォルダを信頼するまでルールが保留されます。

• 追跡されているかを見るために Claude Code は git を実行するが、フォルダを信頼した後にだけ（そのフォルダか信頼が及ぶ親ディレクトリでダイアログを承認した、または -p か SDK のセッション）。それまでは、起動した場所でファイルのルールの扱いが決まる
• 設定ホームの中（ホームディレクトリ、または .claude サブディレクトリを CLAUDE_CONFIG_DIR に設定したディレクトリ）：そのフォルダの .claude/settings.local.json は git を実行せずすぐ適用される。その CLAUDE_CONFIG_DIR のディレクトリが git リポジトリの中にあり、ローカル設定をリポジトリのルートに置く場合は、ほかと同じく保留される
• それ以外の場所：ファイルのルールをプロジェクト設定と同じく保留する。検査が済むと、追跡されていないファイルや git リポジトリの外のディレクトリのファイルのルールは、そのフォルダ自体を信頼していなくても適用される
• v2.1.196〜v2.1.199 は、設定ホームと git リポジトリの外でもファイルのルールを保留し、this workspace has not been trusted の警告を出した。v2.1.207 より前は、追跡されていないファイルのルールをダイアログの承認前に適用した

信頼する前に動くもの#

次の表は、リポジトリが供給できる内容の種類ごとに、フォルダ自体は信頼していない 2 つの場合の動きを示します。親フォルダだけを信頼した場合と、claude -p や SDK で動かした場合（信頼ダイアログが出ない）です。親フォルダの列は入れ子のリポジトリ内では当てはまりません（対話セッションでは信頼ダイアログが出て、claude -p や SDK では claude -p の列に従う）。

• そのフォルダ自体の信頼が要る行は、手で信頼できる：~/.claude.json の projects["<path>"].hasTrustDialogAccepted を true にする（<path> はリポジトリのルート、リポジトリの外ならそのフォルダ）。正確なキーは、スキップされたサブエージェントのフックやインライン MCP サーバーのデバッグログ、スキップされた allow ルールの stderr の警告、スキップされたヘルパーの headersHelper not run の行に出る

自分が書いていないリポジトリで claude -p を実行する前に、何を手元のマシンで動かしてよいかを決めておきます。

• --setting-sources user を渡す（SDK なら settingSources からプロジェクト設定を外す）：プロジェクトの設定ファイルも .mcp.json も読まない
• --bare で始める：プロジェクトのフック・スキル・カスタムコマンド・サブエージェント・プラグイン・.mcp.json のサーバーを読まない。プロジェクトの env ブロックと設定ファイルの awsAuthRefresh などのヘルパーは引き続き適用され、apiKeyHelper は --settings からだけ読まれる
• --settings '{"disableAllHooks": true}' を渡す：その実行のフックをオフにする。ユーザー設定だけに書いても足りない（リポジトリのプロジェクト設定がユーザー設定より優先され、false に戻せるため）
• disabledMcpjsonServers に項目を足す：どの種類のセッションでも .mcp.json のサーバーを名前で拒否する

関連ページ#

• 設定キー一覧：権限のキーを含むすべての設定キー
• 権限モード：モードの使い分けと auto mode
• サンドボックス：Bash コマンドの OS レベルのファイルシステム・ネットワークの隔離
• セキュリティとデータの扱い：安全策とベストプラクティス
• フックのリファレンス：ワークフローの自動化と権限評価の拡張