権限を設定する
きめ細かい権限ルール、モード、管理ポリシーを使用して、Claude Code がアクセスして実行できる内容を制御します。
Claude Code は、エージェントが実行できることと実行できないことを正確に指定できるようにするため、きめ細かい権限をサポートしています。権限設定はバージョン管理にチェックインでき、組織内のすべての開発者に配布できるほか、個々の開発者がカスタマイズできます。
権限システム
Claude Code は、パワーと安全性のバランスを取るために、段階的な権限システムを使用しています。
| ツールタイプ | 例 | 承認が必要 | 「はい、今後は聞かない」の動作 |
|---|---|---|---|
| 読み取り専用 | ファイル読み取り、Grep | いいえ | N/A |
| Bash コマンド | シェル実行 | はい | プロジェクトディレクトリとコマンドごとに永続的 |
| ファイル変更 | Edit/Write ファイル | はい | セッション終了まで |
権限を管理する
/permissions を使用して、Claude Code のツール権限を表示および管理できます。この UI は、すべての権限ルールと、それらが取得される settings.json ファイルをリストします。
- Allow ルールは、Claude Code が手動承認なしで指定されたツールを使用できるようにします。
- Ask ルールは、Claude Code が指定されたツールを使用しようとするたびに確認を促します。
- Deny ルールは、Claude Code が指定されたツールを使用することを防止します。
ルールは順序で評価されます。deny、ask、allow の順です。その順序での最初のマッチがアウトカムを決定し、ルールの特異性は順序を変更しません。Bash(aws *) のような広い deny ルールは、Bash(aws s3 ls) のようなより狭い allow ルールにもマッチする呼び出しを含む、マッチするすべての呼び出しをブロックするため、deny ルールはアローリスト例外を含むことはできません。ask と allow の間にも同じ優先順位が適用されます。マッチする ask ルールは、同じ呼び出しにマッチするより具体的な allow ルールがある場合でも、プロンプトを表示します。
Deny ルールは、ツール名を指定するか、ツール内のパターンをスコープするかによって異なる動作をします。Bash のようなベアツール名は、ツールを Claude のコンテキストから完全に削除するため、Claude はそれを見ることはありません。Bash(rm *) のようなスコープ付きルールは、ツールを利用可能なままにし、Claude が試みたときにマッチする呼び出しをブロックします。
権限モード
Claude Code は、ツール呼び出しの承認方法を制御するいくつかの権限モードをサポートしています。権限モードを参照して、各モードをいつ使用するかを確認してください。設定ファイルで defaultMode を設定します。
| モード | 説明 |
|---|---|
default |
標準動作。各ツールの最初の使用時に権限を促します |
acceptEdits |
ファイル編集と一般的なファイルシステムコマンド（mkdir、touch、mv、cp など）を、作業ディレクトリまたは additionalDirectories 内のパスに対して自動的に受け入れます |
plan |
Plan Mode。Claude はファイルを読み取り、読み取り専用シェルコマンドを実行して探索しますが、ソースファイルを編集しません |
auto |
バックグラウンド安全チェック付きでツール呼び出しを自動承認し、アクションがリクエストと一致することを確認します。現在は研究プレビューです |
dontAsk |
/permissions または permissions.allow ルールで事前に承認されていない限り、ツールを自動的に拒否します |
bypassPermissions |
権限プロンプトをスキップします。ただし、明示的な ask ルールで強制されたプロンプトは除きます。ファイルシステムルートまたはホームディレクトリの削除（rm -rf / など）も回路遮断器として引き続きプロンプトを表示します |
bypassPermissions または auto モードが使用されるのを防ぐには、任意の設定ファイルで permissions.disableBypassPermissionsMode または permissions.disableAutoMode を "disable" に設定します。これらは、オーバーライドできない管理設定で最も有用です。
権限ルール構文
権限ルールは、Tool または Tool(specifier) の形式に従います。
ツールのすべての使用をマッチさせる
ツールのすべての使用をマッチさせるには、括弧なしでツール名を使用します。
| ルール | 効果 |
|---|---|
Bash |
すべての Bash コマンドをマッチさせます |
WebFetch |
すべてのウェブフェッチリクエストをマッチさせます |
Read |
すべてのファイル読み取りをマッチさせます |
Bash(*) は Bash と同等で、すべての Bash コマンドをマッチさせます。拒否ルールとして、両方の形式は Claude のコンテキストからツールを削除します。
細かい制御のためにスペシファイアを使用する
括弧内にスペシファイアを追加して、特定のツール使用をマッチさせます。
| ルール | 効果 |
|---|---|
Bash(npm run build) |
正確なコマンド npm run build をマッチさせます |
Read(./.env) |
現在のディレクトリの .env ファイルを読み取ることをマッチさせます |
WebFetch(domain:example.com) |
example.com へのフェッチリクエストをマッチさせます |
入力パラメータでマッチさせる
拒否ルールと確認ルールは、Tool(param:value) を使用して任意のツール上のトップレベル入力パラメータをマッチさせることができます。ルールは Claude がそのパラメータをその正確な値に設定してツールを呼び出すときにマッチします。1 つのパラメータ値に対する許可ルールは、その呼び出しが全体的に安全であることを確立しないため、許可ルールは各ツール独自のスペシファイア構文を使用し続けます。これはツールが受け入れるスカラーパラメータで機能します。
| ルール | マッチ |
|---|---|
Agent(model:opus) |
Opus モデルティアをリクエストする Agent 呼び出し |
Agent(isolation:worktree) |
git worktree をリクエストする Agent 呼び出し |
Bash(run_in_background:true) |
バックグラウンドで実行される Bash 呼び出し |
パラメータマッチングは以下のルールに従います。
- パラメータ名は 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 にはマッチしません。--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 ルールは * を使用したグロブパターンをサポートしています。ワイルドカードはコマンド内の任意の位置に表示できます。この設定により、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 コマンドにはマッチしません。
ツール名ワイルドカード
拒否ルールと確認ルールは、ツール名の位置でもグロブパターンを受け入れます。パターンはツール名全体にマッチする必要があります。"*" はすべてのツールにマッチし、"mcp__*" はすべてのサーバー全体のすべての MCP ツールにマッチします。ベアネーム glob 拒否ルールでマッチしたツールは Claude のコンテキストから削除されます。これはベアツール名と同じです。この設定はすべての MCP ツールを拒否します。
{
"permissions": {
"deny": [
"mcp__*"
]
}
}
許可ルールは、リテラル mcp__<server>__ プレフィックスの後でのみツール名 glob を受け入れます。サーバーセグメントは glob フリーである必要があるため、ルールは設定した特定のサーバーに名前を付けます。mcp__puppeteer__* は puppeteer サーバーからのすべてのツールにマッチし、mcp__github__get_* はその get_ ツールにマッチします。"*"、"B*"、または "mcp__*" などのアンカーなし許可 glob は警告とともにスキップされ、自動承認されません。
ツール名がマッチしない既知のツールを持つ拒否ルールまたは確認ルールは、タイプミスをキャッチするためにスタートアップ警告を生成します。_ または * を含むツール名はチェックから除外されます。
トランスクリプトと権限ダイアログに表示されるツールのラベルは、その正規名と異なる場合があります。たとえば、トランスクリプトで Stop Task というラベルが付いているツールの正規名は TaskStop です。権限ルールと hook マッチャー は正規名のみをマッチさせるため、Stop Task として記述されたルールはマッチしません。拒否ルールと確認ルールの場合、上記のスタートアップ警告がミスマッチをキャッチします。ツール参照 に記載されている正規名を使用してください。
ツール固有の権限ルール
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 ルールを適用するためにベストエフォートを試みます。また、プロンプト内の @file メンションや、接続された IDE が Claude と共有する選択およびオープンファイルコンテキストにも適用します。
Read と Edit ルールの両方は、gitignore 仕様に従い、4 つの異なるパターンタイプがあります。
| パターン | 意味 | 例 | マッチ |
|---|---|---|---|
//path |
ファイルシステムルートからの絶対パス | Read(//Users/alice/secrets/**) |
/Users/alice/secrets/** |
~/path |
ホームディレクトリからのパス | Read(~/Documents/*.pdf) |
/Users/alice/Documents/*.pdf |
/path |
プロジェクトルートからの相対パス | Edit(/src/**/*.ts) |
<project root>/src/**/*.ts |
path または ./path |
現在のディレクトリからの相対パス | Read(*.env) |
<cwd>/*.env |
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) は同等です。
| Deny ルール | ブロック | ブロックしない |
|---|---|---|
Read(.env) または Read(**/.env) |
現在のディレクトリ以下の任意の .env |
親ディレクトリまたは別のプロジェクト内の .env |
Read(//**/.env) |
ファイルシステム上の任意の場所の .env |
なし。ルールはファイルシステムルートにアンカーされています |
Claude がシンボリックリンクにアクセスするとき、権限ルールは 2 つのパスをチェックします。シンボリックリンク自体と、それが解決するファイルです。Allow ルールと deny ルールはそのペアを異なる方法で扱います。allow ルールはプロンプトにフォールバックし、deny ルールは完全にブロックします。
- Allow ルール：シンボリックリンクパスとそのターゲットの両方がマッチする場合にのみ適用されます。許可されたディレクトリ内のシンボリックリンクがそれの外を指している場合でも、プロンプトが表示されます。
- Deny ルール：シンボリックリンクパスまたはそのターゲットのいずれかがマッチする場合に適用されます。拒否されたファイルを指すシンボリックリンク自体が拒否されます。
たとえば、Read(./project/**) が許可され、Read(~/.ssh/**) が拒否されている場合、./project/key にあるシンボリックリンクが ~/.ssh/id_rsa を指している場合、ターゲットが allow ルールに失敗し、deny ルールにマッチするため、ブロックされます。
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 になり、ドットを越えます。これにより、末尾のワイルドカードが攻撃者が登録できるドメインをマッチさせるのを防ぎます。
MCP
MCP ルールは、Claude Code で設定されたサーバー名を使用し、オプションでそのサーバーからのツールの名前が続きます。
mcp__puppeteerはpuppeteerサーバーによって提供されるツールをマッチさせます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)"]
}
}
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 つのパスセグメントをマッチさせ、** はセグメント全体でマッチさせます。末尾の /** はその名前付きルートもマッチさせます。
| ルール | マッチ | マッチしない |
|---|---|---|
Cd(~/code/*) |
~/code/app |
~/code/app/src、~/code |
Cd(~/code/**) |
~/code およびその下のディレクトリ |
~/code の外のディレクトリ |
Cd(**/node_modules) |
任意の深さの任意の node_modules ディレクトリ |
node_modules/pkg |
フックで権限を拡張する
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に追加します
追加ディレクトリ内のファイルは、元の作業ディレクトリと同じ権限ルールに従います。プロンプトなしで読み取り可能になり、ファイル編集権限は現在の権限モードに従います。
セッションの主要な作業ディレクトリを別のディレクトリを追加する代わりに変更するには、/cdを使用します。/cd コマンドには Claude Code v2.1.169 以降が必要です。/add-dir とは異なり、セッションを再配置します。新しいディレクトリの CLAUDE.md が読み込まれ、--resume はそこからセッションを検出します。
追加ディレクトリはファイルアクセスを許可し、設定ではありません
ディレクトリを追加すると、Claude がファイルを読み取りおよび編集できる場所が拡張されます。そのディレクトリを完全な設定ルートにはしません。ほとんどの .claude/ 設定は追加ディレクトリから検出されませんが、いくつかのタイプは例外として読み込まれます。
これらの例外は、--add-dir フラグまたは /add-dir コマンドで追加されたディレクトリにのみ適用されます。設定ファイルの permissions.additionalDirectories にリストされているディレクトリは、ファイルアクセスのみを許可し、以下の設定は読み込みません。
次の設定タイプは --add-dir ディレクトリから読み込まれます。
| 設定 | --add-dir から読み込まれます |
|---|---|
.claude/skills/ の Skills |
はい、ライブリロード付き |
.claude/agents/ の Subagents |
はい |
.claude/settings.json および .claude/settings.local.json の Settings |
enabledPlugins および extraKnownMarketplaces キーのみ |
CLAUDE.md ファイル、.claude/rules/、および CLAUDE.local.md |
CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 が設定されている場合のみ。CLAUDE.local.md はさらに local 設定ソースが必要です。これはデフォルトで有効になっています |
コマンドおよび出力スタイルは、現在の作業ディレクトリとその親、~/.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 コマンドは、権限に bare Bash ask ルール、または同等の Bash(*) 形式が含まれている場合でもプロンプトなしで実行されます。サンドボックス境界は、そのツール全体のプロンプトの代わりになります。これらのチェックは引き続き適用されます。
Bash(git push *)のようなコンテンツスコープ ask ルールは、引き続きプロンプトを強制します- 明示的な deny ルールは引き続き適用されます
/、ホームディレクトリ、またはその他の重要なシステムパスをターゲットとするrmまたはrmdirコマンドは、引き続きプロンプトをトリガーします
除外されたコマンドなど、サンドボックス化されて実行されないコマンドは、通常どおり bare Bash ask ルールを尊重します。サンドボックスモードを参照して、この動作を変更してください。
管理設定
Claude Code 設定の一元的な制御が必要な組織の場合、管理者はユーザーまたはプロジェクト設定でオーバーライドできない管理設定をデプロイできます。これらのポリシー設定は通常の設定ファイルと同じ形式に従い、MDM/OS レベルのポリシー、管理設定ファイル、サーバー管理設定、または自己ホスト型のClaude apps gatewayを通じて配信できます。配信メカニズムとファイルの場所については、設定ファイルを参照してください。
管理のみの設定
以下の設定は管理設定からのみ読み込まれます。ユーザーまたはプロジェクト設定ファイルに配置しても効果がありません。
| 設定 | 説明 |
|---|---|
allowAllClaudeAiMcps |
true の場合、claude.ai コネクタはデプロイされた managed-mcp.json と並行して読み込まれ、その排他的な制御によって抑制されません。管理 MCP 設定を参照してください |
allowedChannelPlugins |
メッセージをプッシュできるチャネルプラグインのホワイトリスト。設定されている場合、デフォルトの Anthropic ホワイトリストを置き換えます。channelsEnabled: true が必要です。チャネルプラグインの実行を制限するを参照してください |
allowManagedHooksOnly |
true の場合、管理フック、SDK フック、および管理設定 enabledPlugins で強制有効にされたプラグインからのフックのみが読み込まれます。ユーザー、プロジェクト、およびその他すべてのプラグインフックはブロックされます |
allowManagedMcpServersOnly |
true の場合、管理設定からの allowedMcpServers のみが尊重されます。deniedMcpServers はすべてのソースからマージされます。管理 MCP 設定を参照してください |
allowManagedPermissionRulesOnly |
true の場合、ユーザーおよびプロジェクト設定が allow、ask、または deny 権限ルールを定義することを防止します。管理設定のルールのみが適用されます。MCP サーバーのホワイトリストには影響しません。その場合は、allowManagedMcpServersOnly を設定してください |
blockedMarketplaces |
マーケットプレイスソースのブロックリスト。ブロックされたソースはダウンロード前にチェックされるため、ファイルシステムに触れることはありません。管理マーケットプレイス制限を参照してください |
channelsEnabled |
組織のチャネルを許可します。各プランのデフォルトについては、エンタープライズコントロールを参照してください |
disableSideloadFlags |
{/* min-version: 2.1.193 */}--plugin-dir、--plugin-url、--agents、および --mcp-config CLI フラグをスタートアップで拒否します。これがない場合、ユーザーはこれらのフラグを渡すことで、単一の実行に対して strictKnownMarketplaces をバイパスできます。disableSideloadFlagsを参照してください。Claude Code v2.1.193 以降が必要です |
forceRemoteSettingsRefresh |
true の場合、リモート管理設定が新しく取得されるまで CLI 起動をブロックし、取得に失敗した場合は終了します。フェイルクローズ強制を参照してください |
pluginTrustMessage |
インストール前に表示されるプラグイン信頼警告に追加されるカスタムメッセージ |
sandbox.filesystem.allowManagedReadPathsOnly |
true の場合、管理設定からの filesystem.allowRead パスのみが尊重されます。denyRead はすべてのソースからマージされます |
sandbox.network.allowManagedDomainsOnly |
true の場合、管理設定からの allowedDomains と WebFetch(domain:...) allow ルールのみが尊重されます。許可されていないドメインはユーザーに促すことなく自動的にブロックされます。拒否されたドメインはすべてのソースからマージされます |
strictKnownMarketplaces |
ユーザーが追加およびインストールできるプラグインマーケットプレイスソースを制御します。管理マーケットプレイス制限を参照してください |
strictPluginOnlyCustomization |
ユーザーおよびプロジェクトソースからのスキル、エージェント、フック、および MCP サーバーをブロックして、プラグインまたは管理設定からのみ取得できるようにします。true は 4 つすべてのサーフェスをロックします。["skills", "hooks"] などの配列は、指定されたものだけをロックします。strictPluginOnlyCustomizationを参照してください |
wslInheritsWindowsSettings |
Windows HKLM レジストリキーまたは C:\Program Files\ClaudeCode\managed-settings.json で true の場合、WSL は /etc/claude-code に加えて Windows ポリシーチェーンから管理設定を読み込みます。設定ファイルを参照してください |
disableBypassPermissionsMode は通常、組織ポリシーを強制するために管理設定に配置されますが、任意のスコープから機能します。ユーザーは独自の設定で設定して、自分自身をバイパスモードからロックアウトできます。
設定の優先順位
権限ルールは、他のすべての Claude Code 設定と同じ設定優先順位に従います。
- 管理設定：コマンドライン引数を含む他のレベルでオーバーライドできません
- コマンドライン引数：一時的なセッションオーバーライド
- ローカルプロジェクト設定（
.claude/settings.local.json） - 共有プロジェクト設定（
.claude/settings.json） - ユーザー設定（
~/.claude/settings.json）
ツールがいずれかのレベルで拒否されている場合、他のレベルはそれを許可できません。たとえば、管理設定の deny は --allowedTools でオーバーライドできず、--disallowedTools は管理設定が定義する内容を超えて制限を追加できます。
設定スコープ全体でも同じことが当てはまります。ユーザー設定で権限が許可されており、プロジェクト設定で拒否されている場合、拒否ルールがそれをブロックします。逆も同様です。ユーザーレベルの deny がプロジェクトレベルの allow をブロックします。これは、任意のスコープからの deny ルールが allow ルールの前に評価されるためです。
埋め込みホストは、parentSettingsBehaviorが "merge" に設定されている場合、SDK の managedSettings オプションを介して追加の管理ポリシーを提供できます。埋め込み元の値はポリシーを厳しくできますが、緩和することはできません。
設定例
このリポジトリには、一般的なデプロイメントシナリオのスターター設定が含まれています。これらを出発点として使用し、ニーズに合わせて調整してください。