権限を設定する

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

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

権限システム

Claude Code は、パワーと安全性のバランスを取るために、段階的な権限システムを使用しています。

権限を管理する

/permissions を使用して、Claude Code のツール権限を表示および管理できます。この UI は、すべての権限ルールと、それらが取得される settings.json ファイルをリストします。

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

ルールは順序で評価されます。deny -> ask -> allow。最初にマッチしたルールが優先されるため、deny ルールは常に優先されます。

権限モード

Claude Code は、ツールの承認方法を制御するいくつかの権限モードをサポートしています。権限モードを参照して、各モードをいつ使用するかを確認してください。設定ファイルで defaultMode を設定します。

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

権限ルール構文

権限ルールは、Tool または Tool(specifier) の形式に従います。

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

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

Bash(*) は Bash と同等で、すべての Bash コマンドをマッチさせます。

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

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

ワイルドカードパターン

Bash ルールは * を使用したグロブパターンをサポートしています。ワイルドカードはコマンド内の任意の位置に表示できます。この設定により、npm および git commit コマンドが許可され、git push がブロックされます。

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

* の前のスペースは重要です。Bash(ls *) は ls -la にマッチしますが lsof にはマッチしません。一方、Bash(ls*) は両方にマッチします。:* サフィックスは末尾のワイルドカードを記述する同等の方法であるため、Bash(ls:*) は Bash(ls *) と同じコマンドをマッチさせます。

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

ツール固有の権限ルール

Bash

Bash 権限ルールは * を使用したワイルドカードマッチングをサポートしています。ワイルドカードは、開始、中央、終了を含むコマンド内の任意の位置に表示できます。

• Bash(npm run build) は正確な Bash コマンド npm run build をマッチさせます
• Bash(npm run test *) は npm run test で始まる Bash コマンドをマッチさせます
• Bash(npm *) は npm で始まるコマンドをマッチさせます
• Bash(* install) は install で終わるコマンドをマッチさせます
• Bash(git * main) は git checkout main や git log --oneline main などのコマンドをマッチさせます

単一の * は、スペースを含む任意の文字シーケンスをマッチさせるため、1 つのワイルドカードで複数の引数にまたがることができます。Bash(git *) は git log --oneline --all をマッチさせ、Bash(git * main) は git push origin main および git merge main をマッチさせます。

* が末尾にスペース付きで表示される場合（Bash(ls *) など）、単語境界を強制し、プレフィックスの後にスペースまたは文字列の終わりが続く必要があります。たとえば、Bash(ls *) は ls -la にマッチしますが lsof にはマッチしません。対照的に、スペースなしの Bash(ls*) は、単語境界制約がないため、ls -la と lsof の両方にマッチします。

複合コマンド

「はい、今後は聞かない」で複合コマンドを承認すると、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 です。

ベア 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 *) のようなプレフィックスルールで自動承認することはできません。同じことが -exec または -delete を使用する find にも適用されます。Bash(find *) ルールはこれらの形式をカバーしません。特定の呼び出しを承認するには、完全なコマンド文字列の正確一致ルールを記述します。

読み取り専用コマンド

Claude Code は、Bash コマンドの組み込みセットを読み取り専用として認識し、すべてのモードで権限プロンプトなしで実行します。これには ls、cat、echo、pwd、head、tail、grep、find、wc、which、diff、stat、du、cd、および git の読み取り専用形式が含まれます。セットは設定不可能です。これらのコマンドの 1 つにプロンプトを要求するには、それに対して ask または deny ルールを追加します。

すべてのフラグが読み取り専用であるコマンドに対しては、引用符なしのグロブパターンが許可されるため、ls *.ts および wc -l src/*.py はプロンプトなしで実行されます。find、sort、sed、git などの書き込み可能または実行可能なフラグを持つコマンドは、グロブが -delete のようなフラグに展開される可能性があるため、引用符なしのグロブが存在する場合でもプロンプトを表示します。

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

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

Edit ルールは、ファイルを編集するすべての組み込みツールに適用されます。Claude は、Grep や Glob などのファイルを読み取るすべての組み込みツールに Read ルールを適用するためにベストエフォートを試みます。

Read と Edit ルールの両方は、gitignore 仕様に従い、4 つの異なるパターンタイプがあります。

Windows では、パスはマッチング前に POSIX 形式に正規化されます。C:\Users\alice は /c/Users/alice になるため、//c/**/.env を使用してそのドライブ上の .env ファイルをマッチさせます。すべてのドライブ全体でマッチさせるには、//**/.env を使用します。

例：

• Edit(/docs/**): <project>/docs/ での編集（/docs/ ではなく、<project>/.claude/docs/ でもありません）
• Read(~/.zshrc): ホームディレクトリの .zshrc を読み取ります
• Edit(//tmp/scratch.txt): 絶対パス /tmp/scratch.txt を編集します
• Read(src/**): <current-directory>/src/ から読み取ります

ルールはそのアンカーの下のファイルのみをマッチさせるため、アンカーは deny ルールがどこまで到達するかを決定します。ベアファイル名は gitignore セマンティクスに従い、任意の深さでマッチするため、Read(.env) と Read(**/.env) は同等です。

Claude がシンボリックリンクにアクセスするとき、権限ルールは 2 つのパスをチェックします。シンボリックリンク自体と、それが解決するファイルです。Allow ルールと deny ルールはそのペアを異なる方法で扱います。allow ルールはプロンプトにフォールバックし、deny ルールは完全にブロックします。

• Allow ルール：シンボリックリンクパスとそのターゲットの両方がマッチする場合にのみ適用されます。許可されたディレクトリ内のシンボリックリンクがそれの外を指している場合でも、プロンプトが表示されます。
• Deny ルール：シンボリックリンクパスまたはそのターゲットのいずれかがマッチする場合に適用されます。拒否されたファイルを指すシンボリックリンク自体が拒否されます。

たとえば、Read(./project/**) が許可され、Read(~/.ssh/**) が拒否されている場合、./project/key にあるシンボリックリンクが ~/.ssh/id_rsa を指している場合、ターゲットが allow ルールに失敗し、deny ルールにマッチするため、ブロックされます。

WebFetch

• WebFetch(domain:example.com) は example.com へのフェッチリクエストをマッチさせます

MCP

• mcp__puppeteer は puppeteer サーバーによって提供されるツール（Claude Code で設定された名前）をマッチさせます
• mcp__puppeteer__* ワイルドカード構文は、puppeteer サーバーからのすべてのツールもマッチさせます
• mcp__puppeteer__puppeteer_navigate は puppeteer サーバーによって提供される puppeteer_navigate ツールをマッチさせます

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)"]
  }
}

フックで権限を拡張する

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

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

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

作業ディレクトリ

デフォルトでは、Claude は起動されたディレクトリ内のファイルにアクセスできます。このアクセスを拡張できます。

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

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

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

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

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

Subagents、コマンド、および出力スタイルは、現在の作業ディレクトリとその親、~/.claude/ のユーザーディレクトリ、および管理設定から検出されます。Hooks およびその他の settings.json キーは、現在の作業ディレクトリの .claude/ フォルダから親ディレクトリへのフォールバックなしで読み込まれ、ユーザーの ~/.claude/settings.json および管理設定と共に読み込まれます。その設定をプロジェクト全体で共有するには、次のいずれかのアプローチを使用します。

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

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

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

• 権限は、Claude Code が使用できるツール、およびアクセスできるファイルまたはドメインを制御します。すべてのツール（Bash、Read、Edit、WebFetch、MCP など）に適用されます。
• サンドボックスは、Bash ツールのファイルシステムとネットワークアクセスを制限する OS レベルの強制を提供します。Bash コマンドとその子プロセスにのみ適用されます。

防御を深くするために両方を使用します。

• 権限 deny ルールは、Claude が制限されたリソースへのアクセスを試みることさえ防止します
• サンドボックス制限は、プロンプトインジェクションが Claude の意思決定をバイパスしても、Bash コマンドが定義された境界外のリソースに到達することを防止します
• サンドボックス内のファイルシステム制限は、sandbox.filesystem 設定と Read および Edit deny ルールを組み合わせます。両方が最終的なサンドボックス境界にマージされます
• ネットワーク制限は、WebFetch 権限ルールとサンドボックスの allowedDomains および deniedDomains リストを組み合わせます

サンドボックスが autoAllowBashIfSandboxed: true で有効になっている場合（デフォルト）、サンドボックス化された Bash コマンドは、権限に ask: Bash(*) が含まれている場合でもプロンプトなしで実行されます。サンドボックス境界はコマンドごとのプロンプトの代わりになります。明示的な deny ルールは引き続き適用され、/、ホームディレクトリ、またはその他の重要なシステムパスをターゲットとする rm または rmdir コマンドは、引き続きプロンプトをトリガーします。サンドボックスモードを参照して、この動作を変更してください。

管理設定

Claude Code 設定の一元的な制御が必要な組織の場合、管理者はユーザーまたはプロジェクト設定でオーバーライドできない管理設定をデプロイできます。これらのポリシー設定は通常の設定ファイルと同じ形式に従い、MDM/OS レベルのポリシー、管理設定ファイル、またはサーバー管理設定を通じて配信できます。配信メカニズムとファイルの場所については、設定ファイルを参照してください。

管理のみの設定

一部の設定は管理設定でのみ有効です。ユーザーまたはプロジェクト設定ファイルに配置しても効果がありません。

disableBypassPermissionsMode は通常、組織ポリシーを強制するために管理設定に配置されますが、任意のスコープから機能します。ユーザーは独自の設定で設定して、自分自身をバイパスモードからロックアウトできます。

設定の優先順位

権限ルールは、他のすべての Claude Code 設定と同じ設定優先順位に従います。

1. 管理設定：コマンドライン引数を含む他のレベルでオーバーライドできません
2. コマンドライン引数：一時的なセッションオーバーライド
3. ローカルプロジェクト設定（.claude/settings.local.json）
4. 共有プロジェクト設定（.claude/settings.json）
5. ユーザー設定（~/.claude/settings.json）

ツールがいずれかのレベルで拒否されている場合、他のレベルはそれを許可できません。たとえば、管理設定の deny は --allowedTools でオーバーライドできず、--disallowedTools は管理設定が定義する内容を超えて制限を追加できます。

埋め込みホストは、parentSettingsBehaviorが "merge" に設定されている場合、SDK の managedSettings オプションを介して追加の管理ポリシーを提供できます。埋め込み元の値はポリシーを厳しくできますが、緩和することはできません。

たとえば、ユーザー設定で権限が許可されており、プロジェクト設定で拒否されている場合、拒否ルールがそれをブロックします。逆も同様です。ユーザーレベルの deny がプロジェクトレベルの allow をブロックします。これは、任意のスコープからの deny ルールが allow ルールの前に評価されるためです。

設定例

このリポジトリには、一般的なデプロイメントシナリオのスターター設定が含まれています。これらを出発点として使用し、ニーズに合わせて調整してください。

関連項目

• 設定。権限設定テーブルを含む完全な設定リファレンス
• auto モードを設定する。auto モード分類器が組織が信頼するインフラストラクチャを伝えます
• サンドボックス。Bash コマンドの OS レベルのファイルシステムとネットワーク分離
• 認証。Claude Code へのユーザーアクセスを設定します
• セキュリティ。セキュリティ保護とベストプラクティス
• フック。ワークフローを自動化し、権限評価を拡張します