権限を設定する

きめ細かい権限ルール、モード、管理ポリシーを使用して、Claude Code がアクセスして実行できる内容を制御します。

Claude Code は、エージェントが実行できることと実行できないことを正確に指定できるようにするため、きめ細かい権限をサポートしています。権限設定はバージョン管理にチェックインでき、組織内のすべての開発者に配布できるほか、個々の開発者がカスタマイズできます。

権限システム

Claude Code は、パワーと安全性のバランスを取るために、段階的な権限システムを使用しています。表は、各ツールタイプについて、Manual モードがアクションの実行前に確認するかどうかを示しています。その他の権限モードは、これらのどれがあなたに確認するかを変更します。auto モードでは、分類器があなたの代わりにアクションをレビューし、分類器がアクションをどのように評価するかは、それが見るアクションをリストアップしています。

権限プロンプトには、Claude が実行しようとしている内容が表示され、その後に選択肢が続きます。次の例は、Manual モードのセッションにおける Bash コマンドのプロンプトです。

3 番目のオプションである Yes, and switch to auto mode は、すべてのプロンプトに表示されるわけではありません。

「はい、今後は聞かない」を選択し、承認が永続的に保存される場合（Bash コマンドや WebFetch ドメインなど）、Claude Code はルールを git リポジトリのルートにある .claude/settings.local.json に保存します。これはworktreesを通じてメインチェックアウトに解決されます。ルールは、そのリポジトリ内のサブディレクトリで開始されたセッションや worktrees 内のセッションを含む、そのリポジトリ内の将来のセッションに適用されます。ファイル変更の承認はファイルに保存されません。表が示すように、セッション終了まで続きます。git リポジトリの外部や Windows 上など、場合によっては Claude Code はリポジトリルートを使用しません。Claude Code が各ファイルを探す場所は、これらのケースと代わりにルールを保存する場所をリストアップしています。

v2.1.211 より前では、Claude Code は常にルールを開始ディレクトリに保存していたため、worktree またはサブディレクトリで付与された承認はリポジトリの残りの部分に適用されませんでした。以前のバージョンがサブディレクトリまたは worktree に保存したルールは、そこで開始されたセッションに引き続き適用されます。

場合によっては、権限プロンプトは 1 回限りの承認のみを提供し、「今後は聞かない」オプションもセッションの残りの部分のアクションを許可するオプションもありません。Claude Code はプロンプトがそれらが許可するすべてのものをあなたに表示できる場合にのみ、これらのオプションを提供するため、プロンプトから保存するルールは、その名前のオプションが許可するものだけをカバーします。プロンプトが 1 回限りの承認のみを提供する場合、アクションを 1 回承認するか、/permissionsでルール自体を追加してください。

権限プロンプトに回答するときにコメントを追加する

権限プロンプトに回答するときに、単一のアクションを承認または拒否するときに、Claude にメモを添付できます。Bash、PowerShell、ファイル、MCP ツールプロンプトを含むほとんどの権限プロンプトで、はいまたはいいえに移動し、Tab を押してそのオプションのコメントフィールドを開きます。WebFetch とブラウザプロンプトはフィールドを提供しません。セッションの残りの部分のアクションを許可するか、ルールを保存するオプションも 1 つを取りません。

フィールドが開いている状態で、コメントを入力してから、これらのキーのいずれかを押します。

• Enter：コメントが添付された状態で回答を送信します。フィールドを空のままにすると、Claude Code はコメントなしで回答を送信します。
• Tab：フィールドを閉じて回答しません。Claude Code は入力したテキストを保持し、そのオプションで回答する場合でも送信します。
• Shift+Tab：ファイルプロンプト（Edit または Write プロンプトなど）では、フィールドを Tab と同じように閉じます。v2.1.235 より前では、フィールド内で Shift+Tab を押すと、セッションの残りの部分のアクションを許可するオプションが選択されたため、Claude Code はセッションの残りの部分のアクションを承認し、コメントを破棄しました。

Claude Code は、回答方法に応じてコメントを異なる方法で配信します。

• はい：Claude Code はアクションを実行し、結果の後に Claude にコメントを送信します。
• いいえ：Claude Code はコメントを Claude に拒否の理由として送信し、Claude は作業を続けます。メインの会話からのプロンプトでコメントなしでいいえを選択すると、Claude Code はターンを停止します。

権限を管理する

/permissions を使用して、Claude Code のツール権限を表示および管理できます。このダイアログは、すべての権限ルールと、各ルールが取得される settings.json ファイルをリストします。Claude が作業中にダイアログを開くことができます。ルールを追加または削除すると、Claude Code は同じターン内の Claude の次のツール呼び出しから変更を適用します。v2.1.234 より前では、Claude Code はターンが終了するまでコマンドをキューに入れていました。

• Allow ルールは、Claude Code が手動承認なしで指定されたツールを使用できるようにします。
• Ask ルールは、Claude Code が指定されたツールを使用しようとするたびに確認を促します。
• Deny ルールは、Claude Code が指定されたツールを使用することを防止します。

ルールは順序で評価されます。deny、ask、allow の順です。その順序での最初のマッチがアウトカムを決定し、ルールの特異性は順序を変更しません。

Bash(aws *) のような広い deny ルールは、Bash(aws s3 ls) のようなより狭い allow ルールにもマッチする呼び出しを含む、マッチするすべての呼び出しをブロックします。allow ルールは deny ルールから例外を作成することはできません。ask と allow の間にも同じ優先順位が適用されます。マッチする ask ルールは、同じ呼び出しにマッチするより具体的な allow ルールがある場合でも、プロンプトを表示します。

Deny ルールは、ツール名を指定するか、ツール内のパターンをスコープするかによって異なる動作をします。Bash のようなベアツール名は、ツールを Claude のコンテキストから完全に削除するため、Claude はそれを見ることはありません。セッション中にそのようなルールを追加する場合、Claude は次のツール呼び出しからそのツールを呼び出すことができません。ツール全体を拒否するでは、Claude が既に見た定義に何が起こるかについて説明しています。Bash(rm *) のようなスコープ付きルールは、ツールを利用可能なままにし、Claude が試みたときにマッチする呼び出しをブロックします。

ベア名削除はすべてのツールに適用されます（EndConversation を除く）。deny ルールは他のツールが残っている間はそれを削除できず、ask ルールはそれに対してプロンプトを表示しません。

auto mode がセッションで利用可能な場合、ダイアログには auto mode classifier rules も含まれます。Auto mode タブを選択して、それらを表示します。

権限モード

Claude Code は、ツール呼び出しの承認方法を制御するいくつかの権限モードをサポートしています。権限モードを参照して、各モードをいつ使用するかを確認してください。セッションが開始される際のモードを変更するには、設定ファイルで defaultMode を設定してください。セッションが開始されるモードでは、各プランの組み込みデフォルトと VS Code 拡張機能が読み込む内容について説明しています。

bypassPermissions または auto モードが使用されるのを防ぐには、任意の設定ファイルで permissions.disableBypassPermissionsMode または permissions.disableAutoMode を "disable" に設定してください。これらは、オーバーライドできない管理設定で最も有用です。

権限ルール構文

権限ルールは、Tool または Tool(specifier) の形式に従います。スペシファイア内の括弧はリテラルであるため、括弧を含むコマンドまたはパスはエスケープが不要です。

ツールのすべての使用をマッチさせる

ツールのすべての使用をマッチさせるには、括弧なしでツール名を使用します。

Bash(*) は Bash と同等で、すべての Bash コマンドをマッチさせます。拒否ルールとして、両方の形式は Claude のコンテキストからツールを削除します。

細かい制御のためにスペシファイアを使用する

括弧内にスペシファイアを追加して、特定のツール使用をマッチさせます。

入力パラメータでマッチさせる

拒否ルールと確認ルールは、Tool(param:value) を使用して任意のビルトインツール上のトップレベル入力パラメータをマッチさせることができます。

MCP ツール上のパラメータをマッチさせるには、--disallowedTools を使用して拒否ルールを渡します。Claude Code が設定ファイルを読み込むとき、括弧を持つ mcp__ ルールをスキップします。Claude Code は、インタラクティブセッションが開始されるときに無効な設定ダイアログでスキップされたルールをリストし、claude doctor 出力に表示します。

パラメータルールは、Claude がそのパラメータをその正確な値に設定してツールを呼び出すときにマッチします。1 つのパラメータ値に対する許可ルールは、その呼び出しが全体的に安全であることを確立しないため、許可ルールは各ツール独自のスペシファイア構文を使用し続けます。これはツールが受け入れるスカラーパラメータで機能します。

パラメータマッチングは以下のルールに従います。

• パラメータ名は Agent ツール上の model など、ツールの入力の直接フィールドである必要があります。オブジェクトまたは配列内にネストされたフィールドはマッチ可能ではありません
• 各ルールは 1 つのパラメータに名前を付けます。model と isolation の両方でゲートするには、1 つのルールで組み合わせるのではなく、Agent(model:opus) と Agent(isolation:worktree) の 2 つのルールを記述します
• 値は * をワイルドカードとしてサポートし、任意の文字シーケンスにマッチするため、Agent(isolation:*) は任意の明示的な isolation 値にマッチします。* がない場合、マッチは正確です
• モデルが省略するパラメータは決してマッチしないため、Agent(model:*) は model が設定されていない呼び出しにはマッチしません
• 値は Claude が送信するリテラル入力と比較され、正規化の前です。Agent(model:opus) は別名 opus にマッチしますが、完全なモデル ID にはマッチしません
• Skill(skill:<name>) 拒否ルールは代わりに スキルをそのいずれかの名前でマッチさせます。別名や表示名など
• --verbose で実行して、各ツール呼び出しの正確なパラメータ名と値を確認してください
• コロンの周りのホワイトスペースは無視されます

ツールのプライマリコンテンツフィールドはこの方法ではマッチ可能ではありません。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 ルールの * は、スペースを含む任意のテキストにマッチするため、1 つのルールはコマンドのファミリーをカバーします。* のないルールは 1 つの正確なコマンドにマッチします。

Claude が質問なしで実行するコマンドを記述し、変わる部分を * に置き換えます。この設定により、Claude Code は npm スクリプトと git コミットを質問なしで実行し、git push で始まるコマンドを拒否します。git -C . push のように別の書き方をした push はマッチしません。Bash ルールがマッチしないものを参照してください。

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

* はルール内の任意の場所に配置できます。開始時、中間、または終了時です。各行はルール、マッチするコマンド、マッチしない近くのコマンドを示します。

3 つのマッチングルールがこれらの行を生成します。

• * はその場所にあるテキストの代わりになります。 Bash(git * main) では、サブコマンドの代わりになるため、Claude Code はすべての git サブコマンドとその前のすべてのオプションにマッチします。これには -c が含まれます。これは git に名前を付けたプログラムを実行させます。Bash(* --version) では、* はプログラムの代わりになるため、任意のプログラムがマッチします。
• 末尾の * とその前のスペースは、ベアコマンドにもマッチします。 Bash(ls *) は ls にマッチし、Bash(git log *) は git log にマッチします。これは末尾の * がルールの唯一のワイルドカードである場合にのみ成立します。Bash(* --help *) は npm --help x にマッチしますが npm --help にはマッチしません。
• 末尾の * の前のスペースはルールの一部です。 Bash(ls *) は ls の後にスペースが必要であるため、lsof はマッチしません。Bash(ls*) にはスペースがないため、lsof にもマッチします。

:* サフィックスは末尾のワイルドカードを記述する同等の方法であるため、Bash(ls:*) は Bash(ls *) と同じコマンドをマッチさせます。

権限ダイアログは、コマンドプレフィックスに対して「はい、今後は聞かない」を選択すると、スペース区切り形式を書き込みます。:* 形式はパターンの末尾でのみ認識されます。Bash(git:* push) のようなパターンでは、コロンはリテラル文字として扱われ、git コマンドにはマッチしません。

ツール名ワイルドカード

拒否ルールと確認ルールは、ツール名の位置でもグロブパターンを受け入れます。パターンはツール名全体にマッチする必要があります。"*" はすべてのツールにマッチし、"mcp__*" はすべてのサーバー全体のすべての MCP ツールにマッチします。ベアネーム glob 拒否ルールでマッチしたツールは Claude のコンテキストから削除されます。これはベアツール名と同じです。EndConversation 例外を含みます。glob 拒否は他のツールが残っている間はそれを削除できず、glob 確認はそれに対してプロンプトを表示しません。この設定はすべての MCP ツールを拒否します。

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

許可ルールは、リテラル mcp__<server>__ プレフィックスの後でのみツール名 glob を受け入れます。サーバーセグメントは glob フリーである必要があるため、ルールは設定した特定のサーバーに名前を付けます。mcp__puppeteer__* は puppeteer サーバーからのすべてのツールにマッチし、mcp__github__get_* はその get_ ツールにマッチします。"*"、"B*"、または "mcp__*" などのアンカーなし許可 glob は警告とともにスキップされ、自動承認されません。

ツール名がマッチしない既知のツールを持つ拒否ルールまたは確認ルールは、タイプミスをキャッチするためにスタートアップ警告を生成します。_ または * を含むツール名はチェックから除外されます。また、Claude Code が削除したツール（TaskOutput など）の名前も除外されます。

トランスクリプトと権限ダイアログに表示されるツールのラベルは、その正規名と異なる場合があります。たとえば、トランスクリプトで Stop Task というラベルが付いているツールの正規名は TaskStop です。権限ルールと hook マッチャー はラベルにはマッチしないため、Stop Task として記述されたルールはマッチしません。拒否ルールと確認ルールの場合、上記のスタートアップ警告がミスマッチをキャッチします。ツール参照 に記載されている正規名を使用してください。

ツール固有の権限ルール

Bash

Bash 権限ルールはコマンド全体をマッチさせ、* は任意のテキストを表します。ワイルドカードパターンは各ルール形状がマッチするコマンドと * の配置場所を示しています。このセクションの残りは、Claude Code が複合コマンドとラッパーをどのようにマッチさせるか、ルールがマッチしないもの、読み取り専用コマンド、およびリダイレクションについて説明しています。

複合コマンド

Deny ルールと ask ルールは、サブシェル内のネストされたコマンド、コマンド置換、または for ループなどの制御フロー本体内のコマンドを含む、マッチするサブコマンドが存在する場合に適用されます。Bash(git clean *) のような ask ルールは、auto モードでも、cd /tmp && git clean -f または echo "$(git clean -f)" に対してプロンプトを表示します。

&& または || の後に何もない場合（npm test && など）、Claude Code はコマンドを解析不可能として扱い、allow ルールマッチングのためにサブコマンドに分割しないため、Bash(npm *) のようなルールはそれを承認しません。

「はい、今後は聞かない」で複合コマンドを承認すると、Claude Code は複合文字列全体の単一ルールではなく、承認が必要な各サブコマンドの個別ルールを保存します。たとえば、git status && npm test を承認すると、npm test のルールが保存されるため、将来の npm test 呼び出しは && の前に何があるかに関係なく認識されます。cd をサブディレクトリに移動するようなサブコマンドは、そのパスの独自の Read ルールを生成します。単一の複合コマンドに対して最大 5 つのルールが保存される場合があります。

ラッパー

Bash ルールをマッチさせる前に、Claude Code は固定されたラッパーセットをストリップするため、Bash(npm test *) のようなルールは timeout 30 npm test もマッチさせます。ストリップされるラッパーは timeout、time、nice、nohup、stdbuf、およびシェルビルトイン command と builtin、および zsh の noglob です。各ラッパーは引数を実際のコマンドとして実行します。ストリップされない関連する 2 つの形式があります。コマンドを検索する command -v クエリ形式と、zsh の nocorrect です。

Claude Code はまた、既知の安全な環境変数の先頭の割り当てをストリップするため、Bash(npm test *) は NODE_ENV=test npm test にマッチします。Allow ルールは他の変数の割り当てを超えてマッチしません。Deny ルールまたは ask ルールは任意の先頭の割り当てを超えてマッチするため、Bash(rm *) を deny で使用すると、FOO=bar rm -rf tmp/ にマッチします。

ベア xargs もストリップされるため、Bash(grep *) は xargs grep pattern にマッチします。ストリップは xargs にフラグがない場合にのみ適用されます。xargs -n1 grep pattern のような呼び出しは xargs コマンドとしてマッチされるため、内部コマンド用に記述されたルールはそれをカバーしません。

このラッパーリストは組み込まれており、設定不可能です。direnv exec、devbox run、mise exec、npx、docker exec などの開発環境ランナーはリストに含まれていません。これらのツールは引数をコマンドとして実行するため、Bash(devbox run *) のようなルールは run の後に続くものをマッチさせます。これには devbox run rm -rf . が含まれます。環境ランナー内での作業を承認するには、ランナーと内部コマンドの両方を含む特定のルールを記述します。例えば Bash(devbox run npm test)。許可する内部コマンドごとに 1 つのルールを追加します。

watch、setsid、ionice、flock などの Exec ラッパーは、Bash(watch *) のようなプレフィックスルールで自動承認することはできず、Manual モードでは常にプロンプトを表示します。同じことが -exec または -delete を使用する find にも適用されます。Bash(find *) ルールはこれらの形式をカバーしません。特定の呼び出しを承認するには、完全なコマンド文字列の正確一致ルールを記述します。

Bash ルールがマッチしないもの

Bash ルールは Claude が記述したコマンドテキストにマッチします。Claude Code が複合コマンドを分割し、ラッパーをストリップした後です。同じプログラムを別の形式で呼び出した場合、マッチしません。そのため、deny または ask ルールは Claude が通常生成する呼び出しをカバーし、プログラムの周りのセキュリティ境界ではありません。deny または ask のこれらのルールは最初の形式を停止し、他の形式は停止しません。

最後の列のコマンドは、他のルールと権限モードによって決定されます。

コマンドテキストに依存しないファイルシステムとネットワークの強制には、サンドボックスを使用してください。実行前に独自のロジックで完全なコマンドテキストを検査するには、PreToolUse フックを使用してください。

読み取り専用コマンド

Claude Code は、Bash コマンドの組み込みセットを読み取り専用として認識し、permissions.blockReadsOutsideWorkingDirectoriesがフェンスするパスを除き、すべてのモードで権限プロンプトなしで実行します。セットには ls、cat、echo、pwd、head、tail、grep、find、wc、which、diff、stat、du、cd、および git の読み取り専用形式が含まれます。セットは設定不可能です。これらのコマンドの 1 つにプロンプトを要求するには、それに対して ask または deny ルールを追加します。auto モードでは、これらのコマンドは分類器のレビューを待つこともできます。分類器がアクションを評価する方法を参照してください。

ls > out.txt などのリダイレクトはターゲットのチェックを追加します。リダイレクションを参照してください。

すべてのフラグが読み取り専用であるコマンドに対しては、引用符なしのグロブパターンが許可されるため、ls *.ts および wc -l src/*.py はプロンプトなしで実行されます。

Manual モードでは、このセットのコマンドは以下の場合にもプロンプトを表示します。

• 書き込み可能なフラグを持つコマンドの引用符なしグロブ：find、sort、sed、git などの書き込み可能または実行可能なフラグを持つコマンドは、グロブが -delete のようなフラグに展開される可能性があるため、引用符なしのグロブが存在する場合にプロンプトを表示します。
• 別のデーモンを指す docker：読み取り専用形式の docker は、-H、--context、または Podman の --url と --connection などの異なるデーモンを選択するフラグを持つコマンドでプロンプトを表示します。
• パス開放フラグを持つ file：file は -m/--magic-file または -f/--files-from を渡す場合にプロンプトを表示します。これらのフラグにより、file はフラグの値で指定されたパスを開くためです。
• Windows 上のネットワークパス：\\server\share\file などのネットワーク（UNC）パスを含む引数を持つコマンドは、ネットワークパスへのアクセスが Windows 認証情報をそれが指すホストに送信する可能性があるため、プロンプトを表示します。同じチェックが PowerShell ツールコマンドに適用されます。
• 特殊シェル変数への書き込み：PATH または IFS などの特定の特殊シェル変数を設定、設定解除、またはループするコマンドは、コマンドの残りが読み取り専用であっても、プロンプトを表示します。
• 解析できないコマンド：Claude Code がコマンドを完全に解析できない場合、読み取り専用として扱う代わりに承認を求めます。10,000 文字を超えるコマンドは、解析が超過するため常にプロンプトを表示します。

作業ディレクトリまたは追加ディレクトリ内のパスへの cd も読み取り専用です。cd packages/api && ls のような複合コマンドは、各部分が独立して適格である場合、プロンプトなしで実行されます。これらの組み合わせは、各部分が読み取り専用であっても、プロンプトを表示します。

• cd と git：cd が異なるディレクトリに変更される場合にプロンプトを表示します。新しいディレクトリで git を実行するとそのディレクトリのフックを実行できるためです。ターゲットが現在の作業ディレクトリに解決される cd は、操作なしであり、プロンプトをトリガーしません。
• cd とリダイレクト：Claude Code が cd 実行後にリダイレクトターゲットが解決するディレクトリを判定できない場合にプロンプトを表示します。唯一のリダイレクトターゲットが /dev/null であるコマンド（cd app; grep -r pattern . 2>/dev/null など）は、/dev/null は作業ディレクトリに依存しないため、プロンプトを表示しません。

リダイレクション

コマンドが出力または入力をリダイレクトする場合、Claude Code はリダイレクトターゲットをファイルルールに対してチェックします。Claude が直接そのファイルを書き込みまたは読み取ったかのようにです。

• 出力リダイレクト：> file、>> file、または 2> file の場合、チェックは Edit allow ルールと deny ルール、保護されたパス、および作業ディレクトリをカバーします。Bash(git commit *) のようなルールはコマンドを許可し、ターゲットは許可しません。~ で始まるターゲットまたはグロブ文字を含むターゲットは承認が必要です。
• 入力リダイレクト：< file の場合、チェックは Read allow ルールと deny ルール、および作業ディレクトリをカバーします。作業ディレクトリの外のターゲットは、allow ルールがカバーしない限り承認が必要です。グロブパターンを含むターゲット、または同じコマンド内の cd に続く相対パスは、allow ルールがカバーしている場合でも承認が必要です。Claude Code は v2.1.257 以降で入力ターゲットをチェックします。

ターゲットの背後にファイルがない場合はチェックされません。/dev/null、2>&1 や <&3 などのファイルディスクリプタ形式、および here-docs と here-strings です。

Claude Code はまた、tee コマンドが書き込むファイルをチェックします。これには make | tee build.log などのパイプラインが含まれます。チェックは Edit allow ルールと deny ルール、保護されたパス、および作業ディレクトリをカバーします。Bash(tee *) のような allow ルールは、作業ディレクトリの外の宛先をカバーしません。Claude Code は v2.1.269 以降で tee ターゲットをチェックします。

PowerShell

PowerShell 権限ルールは Bash ルールと同じ形状を使用しています。* を使用したワイルドカードは任意の位置でマッチし、:* サフィックスは末尾の * と同等であり、ベア PowerShell または PowerShell(*) はすべてのコマンドをマッチさせます。この設定により、Get-ChildItem および git commit コマンドが許可され、Remove-Item がブロックされます。

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

一般的なエイリアスはマッチング前に正規化されます。コマンドレット名用に記述されたルールはそのエイリアスもマッチさせるため、PowerShell(Get-ChildItem *) は gci、ls、dir もマッチさせます。マッチングは大文字と小文字を区別しません。

Claude Code は PowerShell AST を解析し、複合コマンド内の各コマンドを独立してチェックします。パイプオペレータ |、ステートメント区切り文字 ;、および PowerShell 7 以降のチェーンオペレータ && と || は複合コマンドをサブコマンドに分割します。複合コマンドが許可されるには、ルールがすべてのサブコマンドをマッチさせる必要があります。

Read と Edit

Claude のファイルツールがファイルまたはディレクトリを読み取るのをブロックするには、Read(./.env) または Read(./secrets/**) などのパスに対して Read deny ルールを追加します。機密ファイルを除外にはペースト可能な例があります。プロジェクトに .claudeignore ファイルがある場合、そのファイルは効果がないため、そのエントリを Read deny ルールに移してください。

Edit ルールはファイルを編集するすべての組み込みツールに適用されます。Claude は、Grep や Glob などのファイルを読み取るすべての組み込みツール、プロンプト内の @file メンション、および接続された IDE が Claude と共有する選択およびオープンファイルコンテキストに Read ルールを適用するためにベストエフォートを試みます。

Read deny ルールは、同じパスの Edit と Write ツールもブロックします。これには新しいファイルの作成も含まれます。NotebookEdit はカバーされないため、ツールが変更できないパスに対して Edit deny ルールを追加してください。チェックには編集時に Claude Code v2.1.208 以降が必要です。書き込み時には v2.1.228 以降が必要です。

Claude Code は Edit(path) と Read(path) ルールに対してのみファイル権限をチェックします。代わりに Write、NotebookEdit、Glob、またはレガシー MultiEdit ツール用にパスルールを記述する場合、Claude Code はルールを受け入れますが、それを参照することはなく、起動時に警告を表示します。ただし、--allowedTools で渡された Glob ルールは除きます。Write(docs/**)、NotebookEdit(docs/**)、または MultiEdit(docs/**) の代わりに Edit(docs/**) を使用し、Glob(docs/**) の代わりに Read(docs/**) を使用してください。Claude Code は Write の deny ルールなど、パスのないツール名ルールについては警告しません。それはどこでもツールレベルでそのルールをマッチさせます。v2.1.210 以降が必要です。

Read と Edit ルールの両方は、gitignoreパターン構文を使用し、4 つの異なるパターンタイプがあります。単一セグメントディレクトリパターンの場合、マッチング深度はルールタイプにも依存し、このセクションの後半で説明されています。

/path パターンは、それを定義する設定ソースに関連付けられたディレクトリにアンカーされるため、同じルールは配置場所に応じて異なる場所にマッチします。

/permissions を通じて追加するルールは、保存先の設定ファイルの行に従います。

ローカル設定ルールは、v2.1.211 以降で Claude Code が ファイルを保存するリポジトリルートではなく、セッションの primary working directory にアンカーされます。リポジトリルートで開始されたセッションでは、2 つのディレクトリは同じです。worktreeセッションでは、Edit(/src/**) などの共有ルールはそのワークツリー独自の 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 ディレクトリにマッチします

ルールはそのアンカーの下のファイルのみをマッチさせます。その範囲内で、マッチング深度はパターン形状に依存し、単一セグメントディレクトリパターンの場合、ルールタイプにも依存します。以下で説明されています。ベアファイル名は gitignore セマンティクスに従い、任意の深さでマッチするため、Read(.env) と Read(**/.env) は同等です。

単一ディレクトリセグメント（src/** など）を持つ相対パターンは、ルールタイプに応じて異なる深さでマッチします。

• Allow ルール：Edit(src/**) は <cwd>/src とその下のファイルのみをマッチさせます。任意の深さでディレクトリ名を許可するには、Edit(**/src/**) を記述してください。
• Deny と ask ルール：Read(secrets/**) は現在のディレクトリの下の任意の深さで secrets という名前のディレクトリをマッチさせるため、ルールはネストされたコピーにも適用されます。

他のすべてのパターン形状は、すべてのルールタイプで同じ深さでマッチします。Edit(/src/**) と Edit(src/components/**) はそのアンカーされた場所でのみマッチし、Edit(**/src/**) は任意の深さでマッチします。

次の例は、トップレベルの src/ ディレクトリと vendor/ の下のネストされたコピーを持つプロジェクトに対する各パターン形状を示しています。

<current-directory>/
├── src/
│   └── app.ts
└── vendor/
    └── pkg/
        └── src/
            └── lib.js

「はい、今後は聞かない」でファイルパスを承認すると、Claude Code は [、]、* などの gitignore パターン文字をそのパスでエスケープするため、生成されたルールは承認したリテラルパスのみをマッチさせます。自分で記述したルールはエスケープされません。v2.1.202 より前では、Claude Code はパスをエスケープなしで保存していたため、[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 つの制限は、! パターンが削除できるものを狭めます。

• Claude Code は、! の後に /、~/、または // が続く場合でも、! パターンを現在のディレクトリから相対的に読み取るため、パターンはこれらのプレフィックスの 1 つでアンカーされたルールに到達できません。Read(!~/notes/public/**) は Read(~/notes/**) から何も削除しません。
• 削除は、ルールが全体としてブロックするディレクトリ内のファイルを再度開くことはできません。Read(secrets/**) と Read(!secrets/public/**) では、Claude Code は secrets/public をそれ以外の secrets と一緒にブロックします。

シンボリックリンク

Claude がシンボリックリンクを通じてファイルパスにアクセスするとき、権限チェックは 2 つのパスをカバーします。Claude が要求したパスと、それが解決するファイルです。これは macOS、Linux、Windows 上のシンボリックリンク、および Windows 上のディレクトリジャンクションに適用されます。

ルールがシンボリックリンク付きパスをマッチさせる方法

Allow ルールと deny ルールは、要求されたパスと解決先のファイルを異なる方法で扱います。

• 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 より前では、シンボリックリンク付きディレクトリを通じて記述された deny または ask ルールは、その実際の場所で指定されたパスに適用されませんでした。

Grep と Glob は path 引数が解決するディレクトリを検索します。Claude Code はそのディレクトリに Read deny ルールを適用します。

シンボリックリンクを通じた書き込み

Claude が編集または書き込みを要求するパスがそれ自体がシンボリックリンクである場合、Edit と Write ツールは 書き込みを拒否し、Claude をリンクのターゲットに向ける。

ディレクトリへのパスがシンボリックリンクである場合、またはファイルへのパスがシンボリックリンクを通じている場合、または Bash または PowerShell コマンドが書き込みを行う場合、書き込みはシンボリックリンクを通じて渡される可能性があります。これらの書き込みについて、何が起こるかは、書き込みが解決するファイルが working directories と protected paths に対してどこに位置するかに依存します。

• 作業ディレクトリの外に解決：要求されたパスが作業ディレクトリ内にあり、解決先のファイルがそうでない場合、書き込みは acceptEdits モードで自動承認されません。auto モードでは、allow ルールが書き込みを承認しない限り、分類器が決定する代わりに、書き込みについてプロンプトが表示されます。プロンプトは、書き込みが解決するパスを指定します。
• 要求されたパスが指定しない保護されたパスに解決：protected paths テーブルは各権限モードの結果を示しますが、テーブルが書き込みを分類器にルーティングする場合を除き、この書き込みはプロンプトを表示します。

解決できないパスまたは変更されるパス

Claude Code がディスク上のパスがどこに導くかを判定できない場合（たとえば、シンボリックリンクがループを形成する場合）、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 にマッチします。ここで * は org になりますが、example.evil.com にはマッチしません。ここで * は evil.com になり、ドットを越えます。これにより、末尾のワイルドカードが攻撃者が登録できるドメインをマッチさせるのを防ぎます。

WebFetch ルールのワイルドカードは、フェッチをマッチさせるために Claude Code v2.1.172 以降が必要です。

すべてのフェッチを許可または拒否

ベア WebFetch ルールは、"deny": ["WebFetch"] などの domain: 部分のないツール名です。それと WebFetch(domain:*) の両方はすべての URL をカバーしますが、Claude Code はそれらを異なる方法で適用し、domain: 形式のみがそのドメインをサンドボックスの 許可または拒否ドメインリストに追加します。そのセクションはサンドボックスが尊重するワイルドカード形式とそれを追加したバージョンをリストしています。

各行は、allow リストと deny リストでルールが何をするかを示しています。

2 つの形式は artifacts（Artifact ツールが claude.ai に公開するページ）の読み取りについても異なります。ベア WebFetch deny または ask ルールはこれらの読み取りに適用されません。claude.ai または *.claudeusercontent.com コンテンツホストをカバーする domain: ルール（WebFetch(domain:claude.ai) または WebFetch(domain:*) など）は、各読み取りを拒否するか、その前にプロンプトを表示します。Artifact ルールも同じことを行います。

ルールが読み取りをブロックするとき、拒否はルールを指定します。v2.1.268 より前では、ベア WebFetch deny ルールはすべての artifact 読み取りをブロックし、ベア ask ルールはそれぞれの前にプロンプトを表示していました。

Claude がフェッチを自由に行えるようにしながら、サンドボックス許可リストをそのままにするには、ベア形式を使用してください。この settings.json はそれを行います。

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

Claude にページをフェッチするよう求めると、プロンプトなしでフェッチします。サンドボックス化された curl をサンドボックス許可リストの外のホストに対して実行するよう求めると、Claude Code はそのホストに対してプロンプトを表示します。ベア形式はホストを許可リストに追加しなかったためです。

auto モードでは、Claude は代わりにホストを分類器がレビューするコマンドの per-command allowed domains に指定します。

MCP

MCP ルールは Claude Code で設定されたサーバー名を使用し、オプションでそのサーバーからのツールの名前が続きます。

• mcp__puppeteer は puppeteer サーバーによって提供されるツールをマッチさせます
• mcp__puppeteer__* ワイルドカード構文を使用し、puppeteer サーバーからのすべてのツールもマッチさせます
• mcp__puppeteer__puppeteer_navigate は puppeteer サーバーによって提供される puppeteer_navigate ツールをマッチさせます

組織が claude.ai コネクタツールを ask に設定している場合、そのツールの allow ルールは有効になりません。Claude Code は auto および bypassPermissions モードでも、すべての呼び出しでプロンプトを表示します。プロンプトを表示しない dontAsk モードでは、Claude Code は代わりに呼び出しを拒否します。Claude Code が自分で取得するコネクタからのツールは mcp__claude_ai_<server>__<tool> として表示されます。

Claude Desktop アプリの Coworkセッションでは、Claude は組み込み Bash ツールではなく Cowork の mcp__workspace__bash ツールを通じてシェルコマンドを実行し、Cowork は同様に mcp__workspace__web_fetch をウェブフェッチに提供します。Claude Code はまた、全体の Bash または WebFetch ツールを指す deny ルールをこれらの Cowork ツールに適用するため、管理された Bash deny ルールは Claude が Cowork でシェルコマンドを実行するのを停止します。Claude Code がそのような呼び出しをブロックするとき、メッセージは Cowork ツールを指定します。Permission to use mcp__workspace__bash has been denied. Allow ルールは引き継がれません。Claude Code は Bash allow ルールを mcp__workspace__bash に適用することはありません。

Agent（subagents）

Agent(AgentName) ルールを使用して、Claude が使用できる subagents を制御します。

• Agent(Explore) は Explore subagent をマッチさせます
• Agent(Plan) は Plan subagent をマッチさせます
• Agent(my-custom-agent) は my-custom-agent という名前のカスタム subagent をマッチさせます

これらのルールを設定の deny 配列に追加するか、--disallowedTools CLI フラグを使用して特定のエージェントを無効にします。Explore エージェントを無効にするには：

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

Cd

Cd ルールは、/cd コマンドがセッションを移動できるディレクトリを制御します。Cd はモデル呼び出し可能なツールではありません。Claude はそれを呼び出すことはできず、ルールは自分で /cd を実行する場合にのみ適用されます。

ベア Cd deny ルールは /cd を完全に無効にします。Cd(<path-pattern>) deny ルールはマッチするターゲットをブロックします。Deny ルールはターゲットのすべてのスペルをチェックします。これには、それが解決する各シンボリックリンクホップが含まれるため、1 つのパス用に記述されたルールは、それに解決するターゲットもブロックします。

任意の Cd allow ルールを追加すると、/cd をホワイトリストモードに切り替えます。解決されたターゲットディレクトリは、allow ルールの 1 つにマッチする必要があります。そうでない場合、/cd は拒否します。Cd ルールが設定されていない場合、/cd はデフォルト動作を保持し、見慣れないディレクトリを信頼するようにプロンプトを表示します。

パスパターンは Read と Edit ルールから //、~/、/ アンカーを共有しますが、マッチングはディレクトリパス全体にアンカーされます。gitignore スタイルではなく、* は正確に 1 つのパスセグメントをマッチさせ、** はセグメント全体でマッチさせます。末尾の /** はその名前付きルートもマッチさせます。

フックで権限を拡張する

Claude Code フックは、実行時に権限評価を実行するカスタムシェルコマンドを登録する方法を提供します。Claude Code がツール呼び出しを行うと、PreToolUse フックは権限プロンプトの前に実行されます。ただし、EndConversationを除くすべてのツールに対して実行されます。フック出力はツール呼び出しを拒否し、プロンプトを強制し、またはプロンプトをスキップしてコールを続行させることができます。

PreToolUse フック決定は権限ルールをバイパスしません。Claude Code は deny ルールと ask ルールを、フックが何を返すかに関係なく評価します。マッチする deny ルールはコールをブロックし、マッチする ask ルールはフックが "allow" または "ask" を返した場合でもプロンプトを表示します。これは、権限を管理するで説明されている deny 優先の優先順位を保持し、管理設定で設定された deny ルールを含みます。

その優先順位は、設定ファイル内のフックとプラグインの hooks/hooks.json 内のフックをカバーしています。インストールした mod が tool.check を処理する場合、ルールと PreToolUse フックが決定した後に応答し、その応答はそれらの決定を置き換えることができます。

• Ask ルール: mod は ask ルールがプロンプトを表示するコールを承認できます
• PreToolUse フックからのブロック: mod はコールを承認できます。ただし、フックが管理設定にある場合を除きます
• 自動モード分類器: 自動モードでは、mod が承認するコールは分類器チェックなしで実行されます
• Deny ルール: 管理設定を持つマシン上、または Team または Enterprise プランでサインインしている場合、deny ルールはデフォルトで mod より優先され、組織はそれを変更できます。その他の場所では、mod は deny ルールが拒否するコールを承認できます

mod を信頼するかどうかを決定するを参照するか、管理設定をデプロイする場合は組織の mod を管理するを参照してください。

requiresUserInteractionでマークされた MCP ツールも、フックが "allow" を返した場合でもプロンプトを表示します。コネクタツール（組織が ask に設定）も同様に、その設定が Claude Code に到達するセッションではプロンプトを表示します。

ブロッキングフックは allow ルールよりも優先されます。終了コード 2 で終了するフックは、権限ルールが評価される前にツール呼び出しを停止するため、allow ルールがコールを許可する場合でもブロックが適用されます。プロンプトなしですべての Bash コマンドを実行し、ブロックしたい少数のコマンドを除外するには、allow リストに "Bash" を追加し、それらの特定のコマンドを拒否する PreToolUse フックを登録します。適応できるフックスクリプトについては、保護されたファイルへの編集をブロックするを参照してください。

作業ディレクトリ

デフォルトでは、Claude は起動されたディレクトリ内のファイルにアクセスできます。そのディレクトリはセッションの主要な作業ディレクトリであり、/cd でセッションを移動するまで変わりません。このアクセスを拡張できます。

• 起動時：--add-dir <path> CLI 引数を使用します
• セッション中：/add-dir コマンドを使用します
• 永続的な設定：設定ファイルの additionalDirectories に追加します

追加ディレクトリ内のファイルは、元の作業ディレクトリと同じ権限ルールに従います。プロンプトなしで読み取り可能になり、ファイル編集権限は現在の権限モードに従います。

ほとんどのネットワークパス（\\server\share などの UNC 共有など）は、作業ディレクトリとして追加できません。これは、ルックアップがそれが指す名前のホストに接続する可能性があるためです。Windows では、代わりに共有をドライブ文字にマップし、起動時に --add-dir でドライブを渡します。

permissions.blockReadsOutsideWorkingDirectories を設定して、ファイルツールがすべての権限モードで囲まれたパスを拒否するようにします。自動モードでは、Claude Code は Claude が作業ディレクトリの外側を読み取る最初の時点でこれをオンにするよう提案します。

macOS のバックグラウンドセッションでは、セッションホストは ~/Desktop、~/Documents、~/Downloads などの保護されたフォルダへのアクセスをターミナルとは別に要求します。Claude がそこでファイルを読み取りまたは書き込む必要がある場合、Operation not permitted で読み取りが失敗する場合は、バックグラウンドセッションにフォルダアクセスを許可する方法を参照してください。

セッションを別のディレクトリに移動する

セッションを別の主要な作業ディレクトリに移動するには、現在のディレクトリの横にディレクトリを追加するのではなく、/cd <path> を実行します。Claude Code は会話を保持し、新しいディレクトリの CLAUDE.md を読み込み、以前にそこで作業していない場合はワークスペースを信頼するよう促します。その後、新しいディレクトリから --resume を実行すると、Claude Code は移動されたセッションを検出します。

移動するとすぐに、Claude Code は新しいディレクトリのプロジェクト設定を適用します。

• プロジェクト設定（権限ルールとhooksを含む）
• .mcp.json サーバー（起動時と同じサーバー承認の対象であり、それに登録したローカルスコープ MCP サーバー）
• 設定が有効にするプラグイン、そのスキル、およびそのサブエージェント
• env 値（前のディレクトリの設定から適用された環境変数の上に適用され、有効なままです）

Claude Code はまた、前のディレクトリのプロジェクトとローカルスコープ MCP サーバーを切断し、移動後に有効でなくなったプラグインのサーバーを切断します。前のディレクトリの設定ではなく、新しいディレクトリの設定から追加ディレクトリを取得し、--add-dir または /add-dir で追加したディレクトリを保持します。移動が有効にする Hooks は、セッションが開始されたプロジェクトルートに設定された${CLAUDE_PROJECT_DIR}を受け取ります。

新しいディレクトリがまだ信頼されていない場合、Claude Code は信頼プロンプトでディレクトリの設定が有効にするアロールール、追加ディレクトリ、hooks、およびヘルパーコマンドをリストアップするため、受け入れる前に確認できます。拒否した場合、セッションはそのままです。v2.1.246 より前では、/cd は再開するまで新しいディレクトリの設定、hooks、MCP サーバー、またはスキルを適用しませんでした。また、信頼プロンプトはディレクトリの設定が何を有効にするかをリストアップしませんでした。

Cd 権限ルールで /cd ターゲットを制限または無効にします。

追加ディレクトリはファイルアクセスを許可し、設定ではありません

ディレクトリを追加すると、Claude がファイルを読み取りおよび編集できる場所が拡張されます。そのディレクトリを完全な設定ルートにはしません。ほとんどの .claude/ 設定は追加ディレクトリから検出されませんが、いくつかのタイプは例外として読み込まれます。

これらの例外は、--add-dir フラグまたは /add-dir コマンドで追加されたディレクトリにのみ適用されます（Agent SDK がフラグを通じて追加するディレクトリを含む）。設定ファイルの permissions.additionalDirectories にリストされているディレクトリは、ファイルアクセスのみを許可し、以下の設定は読み込みません。

Agent SDK の TypeScript のadditionalDirectoriesオプションと Python のadd_dirsオプションは、TypeScript オプションが設定キーと同じ名前を共有していても、例外を受け取ります。SDK は各エントリを Claude Code に --add-dir として渡すため、これらのディレクトリはフラグで追加されたディレクトリのように動作します。任意のフラグで追加されたディレクトリからのスキル、コマンド、およびサブエージェントは、プロジェクト設定ソースを通じて読み込まれるため、CLI で--setting-sourcesを使用するか SDK で settingSources を使用してそのソースを除外した場合は読み込まれず、ベアモードはそれらの中のコマンドとサブエージェントをスキップします。

次の設定タイプは --add-dir ディレクトリから読み込まれます。

主要な作業ディレクトリのサブディレクトリからスキル、コマンド、およびサブエージェントをセッション中に読み込むには、そのサブディレクトリのパスで /add-dir を実行します。Claude Code はサブディレクトリが既に読み取り可能であるため、プロンプトを表示したり作業ディレクトリを追加したりせずに、セッションの残りの間それらを読み込みます。これには Claude Code v2.1.257 以降が必要です。

Claude Code は現在の作業ディレクトリとその親、~/.claude/ のユーザーディレクトリ、および管理設定から出力スタイルを検出します。Hooks およびその他の .claude/settings.json キーは、現在の作業ディレクトリの .claude/ フォルダから親ディレクトリへのフォールバックなしで読み込まれ、ユーザーの ~/.claude/settings.json および管理設定と共に読み込まれます。.claude/settings.local.json は git リポジトリルートから読み込まれます。Claude Code がサブディレクトリで起動された場合でも、Windows など Claude Code がリポジトリルートを使用しない場合を除きます。v2.1.211 より前では、これも現在の作業ディレクトリからのみ読み込まれました。Agent SDKセッションはすべてのバージョンで作業ディレクトリから読み込みます。

その設定をプロジェクト全体で共有するには、次のいずれかのアプローチを使用します。

• ユーザーレベルの設定：~/.claude/agents/、~/.claude/output-styles/、または ~/.claude/settings.json にファイルを配置して、すべてのプロジェクトで利用可能にします
• プラグイン：設定をプラグインとしてパッケージ化および配布し、チームがインストールできるようにします
• 設定ディレクトリから起動する：使用する .claude/ 設定を含むディレクトリから Claude Code を実行します

権限とサンドボックス化がどのように相互作用するか

権限とサンドボックス化は補完的なセキュリティレイヤーです。

• 権限は Claude Code が使用できるツール、およびアクセスできるファイルやドメインを制御します。これらは Bash、Read、Edit、WebFetch、MCP、およびその他すべてのツールに適用されます。ただし、他のツールが残っている場合、deny ルールまたは ask ルールはEndConversationをブロックできません。
• サンドボックス化は OS レベルの強制を提供し、シェルコマンドのファイルシステムとネットワークアクセスを制限します。これは Bash、PowerShell、およびMonitorコマンドとその子プロセスにのみ適用されます。

防御の多層化のために両方を使用してください。プロンプトインジェクションが Claude の意思決定をバイパスしても、サンドボックス制限は引き続き適用されます。サンドボックス設定と権限ルールからのパスとドメインは最終的なサンドボックス構成にマージされます。

サンドボックス化を有効にして autoAllowBashIfSandboxed をデフォルトの true のままにすると、サンドボックス化された Bash コマンドは、権限に bare Bash ask ルール、または同等の Bash(*) フォームが含まれている場合でも、プロンプトなしで実行されます。サンドボックス境界がそのツール全体のプロンプトの代わりになります。

プランモードでは、Claude Code はこの置き換えをスキップします。ask ルールがない場合、組み込みの読み取り専用コマンドは引き続きプロンプトなしで実行され、その他のシェルコマンドはプランニング中に通常の権限フローを通過します。プランモードの詳細については、プランモードを参照して、Claude Code がそこでコマンドをどのようにゲートするかを確認してください。bare Bash ask ルールがある場合、サンドボックス化された読み取り専用コマンドを含むすべての Bash コマンドがプロンプトされます。これはサンドボックス化の外側と同じです。v2.1.212 より前では、置き換えはプランモードでも適用されていました。

これらのチェックは引き続き適用されます。

• Bash(git push *) のようなコンテンツスコープの ask ルールは引き続きプロンプトを強制します
• 明示的な deny ルールは引き続き適用されます
• 重要なパスをターゲットとする rm または rmdir コマンドは引き続き通常の権限フローを通過します

除外されたコマンドなど、サンドボックス化されて実行されないコマンドは、通常どおり bare Bash ask ルールを尊重します。この動作を変更するには、サンドボックスモードを参照してください。