【Claude Code】settings.jsonのpermissions設定をわかりやすく解説

Claude Codeの`settings.json`を活用し、開発環境を安全かつ効率的に使う方法を解説します。操作の許可・確認・拒否を設定する`permissions`、自動承認で作業を効率化する`defaultMode`、そして複数の設定ファイルの優先順位とマージの仕組みを初心者向けにわかりやすく説明します。

作成日: 2026年09月29日更新日: 2026年09月29日

開発環境

OS: Windows10（WSL2 / Ubuntu）
Editor: Visual Studio Code
Node.js: v22.22.2
claude-code: 2.1.118
作業ディレクトリ: ~/dev/settings-demo（新規作成して使う）

settings.json とは？

settings.json は、Claude Code の動作を設定するためのファイルです。これは「JSON形式」という、情報を整理して記述するための形式で書かれています。

このファイルには様々な設定項目を書くことができますが、まず最初に知っておくべき、そして触れるべき項目は permissions（許可ルール） です。

permissions … これは、Claude Code が特定のツールやコマンド（命令）を使う際に、「許可する」「毎回確認する」「拒否する」のいずれかを決定するための設定です。
この設定をしておくことで、操作中に許可を求めるメッセージが何度も表示されることを防ぐことができます。また、意図しない危険な操作が行われるのを確実に停止させることも可能になります。

公式ドキュメント

settings の全項目: https://code.claude.com/docs/ja/settings
permissions（許可ルール）: https://code.claude.com/docs/ja/permissions
permission モード: https://code.claude.com/docs/ja/permission-modes

注意: 「settings.json」と「settings**.local**.json」は別のファイルです（これについては後の項目で詳しく説明します）。まずは permissions という設定項目があること、そしてそれが許可ルールを決めるものだと理解しておけば大丈夫です。

作業ディレクトリを用意する

まず、練習用のディレクトリを作成し、そのディレクトリの中でClaude Codeというツールを起動する手順についてご説明します。

システム開発を行う際には、関連するファイルや設定を整理するために、特定の作業用の場所（ディレクトリ）を用意することが一般的です。ここでは、settings-demoという名前のディレクトリを作成して、今後の作業の拠点とします。


1mkdir -p ~/dev/settings-demo
2cd ~/dev/settings-demo
3claude

上記のコマンドについて詳しく見ていきましょう。

mkdir -p ~/dev/settings-demo
- mkdirコマンドは、新しいディレクトリ（フォルダー）を作成するために使用します。
- -pオプションは、指定したパスの途中に存在する親ディレクトリ（この例では~/dev）がまだない場合でも、自動的にそれらの親ディレクトリも一緒に作成してくれる便利なオプションです。また、もし指定したディレクトリが既に存在していてもエラーになりません。
- ~（チルダ）は、ユーザーのホームディレクトリ（例えばWindowsならC:\Users\あなたのユーザー名、macOSやLinuxなら/home/あなたのユーザー名）を表します。
- このコマンドを実行すると、ホームディレクトリの下にdevというディレクトリが作られ、その中にさらにsettings-demoというディレクトリが作成されます。
cd ~/dev/settings-demo
- cdコマンドは、「Change Directory（ディレクトリの変更）」の略で、現在の作業ディレクトリを別の場所へ移動するために使います。
- このコマンドを実行することで、現在の作業場所が、先ほど作成した/home/あなたのユーザー名/dev/settings-demo（または同等のパス）に切り替わります。これ以降の作業はこのディレクトリ内で進めることになります。
claude
- このコマンドは、Claude Codeという開発ツールを起動するために使用します。
- cdコマンドで移動したsettings-demoディレクトリが、このClaude Codeの起動時の作業ディレクトリとなります。

上記のコマンドを順に実行すると、ターミナルには以下のような出力が表示されます。

出力結果
1Welcome to Claude Code
2
3cwd: /home/youruser/dev/settings-demo
4>

出力結果について説明します。

Welcome to Claude Code は、Claude Codeが正常に起動したことを示すメッセージです。
cwd: /home/youruser/dev/settings-demo は、「Current Working Directory（現在の作業ディレクトリ）」の略で、今Claude Codeがどのディレクトリで作業しているかを表示しています。cdコマンドで移動したディレクトリと同じパスが表示されていることを確認してください。
> は、Claude Codeのプロンプト（コマンド入力待ちの状態）を示しています。これで、Claude Code内で作業を開始できる準備が整いました。

注意: settings.json はプロジェクトのルート（起動したディレクトリ）に作る .claude/settings.json が基本。

この注意点は、設定ファイル（settings.json）の配置場所について説明しています。

settings.jsonは、Claude Codeやプロジェクト全体に関する様々な設定を記述するためのファイルです。
「プロジェクトのルート」とは、今回claudeコマンドを起動したsettings-demoディレクトリのことを指します。
設定ファイルをプロジェクトのルートにある.claude/settings.jsonというパスに配置することが、一般的な推奨方法となります。.claudeというディレクトリは、通常、特定のツールやプロジェクトの設定ファイルを格納するために使用される隠しディレクトリです。このように配置することで、プロジェクト固有の設定を分かりやすく管理することができます。

まず /permissions で今の状態を見る

システムの設定を変更する前に、まずは現在の状態を確認することが重要です。いきなり設定ファイル（JSON形式のファイル）を直接編集するのではなく、今どのような設定になっているのかを把握することから始めましょう。

Claude Codeという環境で、以下のコマンドを実行します。


1/permissions

このコマンドを実行すると、次のような結果が表示されます。

出力結果
1Permissions
2  Allow   (まだ何も登録されていない、または既定のルール)
3  Ask
4  Deny
5
6  ↑↓ to navigate · Enter to edit · Esc to close

この表示から、現在設定されているallow（許可）、ask（確認）、deny（拒否）といった権限の内容を一覧で確認することができます。また、この画面では、キーボードの↑（上）や↓（下）キーで項目を選び、Enterキーを押すことで、これらの設定内容を直接追加したり、削除したりする操作も可能です。Escキーを押すと画面を閉じることができます。

注意: /permissions コマンドを使って追加した設定内容は、自動的に .claude/settings.local.json というファイルに保存されることがあります。これは、個人の設定を記録するファイルです。そのため、自分で意識していなかったのに「いつの間にか何かの操作が許可されていた」といった状況になった場合、この自動保存が原因であることが考えられます。

allow / ask / deny の3つの役割

システムやツールにおいて、ユーザーの操作を制御し、安全性を高めるために使われるのが、allow、ask、deny という3つの役割です。これらの設定を適切に利用することで、意図しない操作や危険な操作を防ぎ、作業をより安全に進めることができます。

キー	意味	使いどころ
`allow`	確認なしで実行を許可する	いつもの安全なコマンド（テスト・lintなど）
`ask`	実行前に毎回確認する	念のため目視したい操作（git pushなど）
`deny`	絶対に実行させない（確認すら出さない）	危険・秘密に関わる操作（.env閲覧、rmなど）

各キーの詳細

`allow`

allow は、「確認なしで実行を許可する」という意味を持ちます。この設定がされている操作は、システムが「安全である」と判断し、あなたに何も尋ねることなくすぐに実行されます。

例えば、プログラムのテスト実行や、コードのスタイルをチェックする「lint」のような、頻繁に行うけれどほとんど危険がないコマンドに使われます。普段使いの、安心して使える機能に設定すると便利です。

`ask`

ask は、「実行前に毎回確認する」という意味を持ちます。この設定がされている操作は、実行する前にシステムが「本当に実行しますか？」と、あなたに確認を求めます。

例えば、コードをリモートのリポジトリにアップロードする「git push」のような操作に使われます。これは一度実行すると取り消しが難しい場合があるので、最後に自分で確認することで、間違いを防ぐことができます。少し注意が必要な操作に対して設定すると良いでしょう。

`deny`

deny は、「絶対に実行させない（確認すら出さない）」という意味を持ちます。この設定がされている操作は、システムが「この操作は絶対に実行してはいけません」と判断し、実行をブロックします。確認のメッセージすら表示されません。

非常に危険な操作や、機密情報に関わる操作に使われます。例えば、環境設定ファイル（.env）の中身を不用意に見ることを防いだり、ファイルを完全に削除する「rm」コマンドのような、一度実行すると取り返しのつかないコマンドの実行を禁止するのに使われます。誤操作による重大なトラブルを防ぐための、最も強力な安全策です。

優先順位と考えるコツ

これらの設定には優先順位があり、deny が最も強力です。もし、ある操作が allow で許可されていても、同時に deny でもブロック対象になっていた場合、deny の設定が優先され、その操作は実行されません。これは、「安全を最優先する」という考え方に基づいています。

これらの設定を効果的に使うためのコツは、「まず、絶対に実行してほしくない危険な操作を deny で確実にブロックすること」です。そうすることで、他の操作については「これは安全だから allow に設定しよう」というように、安心して許可範囲を広げることができます。この考え方をすることで、安全性を確保しながら、作業効率も高めることができます。

ルールを書いてみる（基本の形）

システム開発において、ツールに「何をして良いか」「何をする前に確認が必要か」といった指示を与えることはとても重要です。ここでは、その指示（ルール）を記述する基本的な方法について説明します。

まず、.claude/settings.json というファイルを作成します。このファイルは、主にコードアシスタントツール（この場合はClaudeという名前のツール）が、プロジェクト内でどのような操作を実行できるかを定義するための設定ファイルです。

このファイルの中に、最初のルールを記述します。ルールの書き方は、ツール名(対象) という形が基本となります。


1{
2  "$schema": "https://json.schemastore.org/claude-code-settings.json",
3  "permissions": {
4    "allow": [
5      "Bash(npm run lint)",
6      "Bash(npm run test)",
7      "Bash(npm run test *)",
8      "Edit(./src/**)"
9    ],
10    "ask": [
11      "Bash(git push)",
12      "Bash(git push *)"
13    ]
14  }
15}

上記のJSON（ジェイソン）形式のコードは、設定の内容をコンピュータが理解しやすい形で記述したものです。

ここでは特に、"permissions"（パーミッションズ：権限）という部分に注目してください。この中には、「allow（許可する）」と「ask（尋ねる）」という2つの項目があります。

それぞれのルールの意味は次の通りです。

Bash(npm run lint) これは「npm run lint」というコマンドを、ターミナル（コマンドを実行する画面）で実行することを許可するという意味です。このぴったりのコマンドだけが、確認なしで実行できます。
Bash(npm run test) と Bash(npm run test *)
- Bash(npm run test) は、引数（コマンドに渡す追加情報）が何も付いていない npm run test というコマンド単体を許可するという意味です。
- Bash(npm run test *) は、npm run test -- foo のように、npm run test の後に引数（* の部分）が付いたときに、そのコマンドを許可するという意味です。これら両方を記述することで、「npm run test に関連するすべてのコマンド（引数の有無にかかわらず）を許可する」という設定になります。
Edit(./src/**) これは、「./src/ フォルダ配下（srcフォルダの中にあるすべてのファイルや、さらにその中のフォルダにあるファイルも含む）の編集」を許可するという意味です。** は、指定した場所のすべての階層のファイルやフォルダを指します。
ask の Bash(git push) と Bash(git push *) これは、「git push というコマンド（引数なし、または引数付きのどちらも）」を実行しようとした際に、実行する前に毎回確認を求めるという意味です。重要な操作なので、誤って実行しないように確認する設定です。

注意: ワイルドカードは * を使用します。この * は「どんな文字でも良い」という意味を持ちます。 * の前にスペースを入れる（例: Bash(npm run test *)）と、「単語の区切り」として認識されます。これにより、npm run test の後に続く引数にのみマッチし、npm run testfoo のような全く別のコマンドを誤って許可してしまうことを防ぎます。ただし、この形（Bash(npm run test *)）は引数付きのコマンドにしかマッチしません。そのため、引数なしの npm run test という単体コマンドも許可したい場合は、Bash(npm run test) を別途並べて記述する必要があります。

settings.json ファイルを保存すると、現在実行中のセッション（ツールの作業状態）にも、設定したルールがすぐに反映されます。設定したルールが正しく反映されているかを確認するには、以下のコマンドを試してみてください。


1/permissions

このコマンドを実行すると、次のような出力結果が表示されます。

出力結果
1Permissions
2  Allow
3    Bash(npm run lint)
4    Bash(npm run test)
5    Bash(npm run test *)
6    Edit(./src/**)
7  Ask
8    Bash(git push)
9    Bash(git push *)
10  Deny

この出力結果を見ると、あなたが settings.json に記述したルールが、「Allow（許可）」と「Ask（確認）」のカテゴリに分かれて正しく表示されていることがわかります。Deny（拒否）の項目は、今回明示的に拒否するルールを設定していないため、何も表示されていません。

deny で危険操作を確実に止める

システム開発において、誤って実行されると困る操作はたくさんあります。その中でも特に重要なのが、「うっかり実行されたら困るもの」をdenyという設定で確実に止めておくことです。

特に、.envファイル（APIキーなどの秘密の情報が入ったファイル）の閲覧と、rmコマンドによるファイルの削除は、システムに大きな損害を与える可能性があるため、最初に禁止設定をしておくことが大切です。

この設定の読み方は以下の通りです。


1{
2  "permissions": {
3    "deny": [
4      "Read(./.env)",
5      "Read(./.env.*)",
6      "Read(./secrets/**)",
7      "Bash(rm *)"
8    ]
9  }
10}

Read(./.env) と Read(./.env.*) … これは、プロジェクトのルートディレクトリにある.envファイルや、.env.localなどの関連ファイルへの読み取りアクセスを禁止する設定です。これらのファイルには、APIキーやデータベースの接続情報といった非常に重要な秘密の情報が書かれていることが多いため、第三者や意図しないシステムにこれらの情報が渡ってしまうことを防ぎます。
Read(./secrets/**) … これは、secretsという名前のフォルダとその中にあるすべてのファイル、さらにそのサブフォルダの中のファイルも含めて、まるごと読み取りを禁止する設定です。**は、指定したフォルダの直下だけでなく、その中のすべての階層のファイルやフォルダを指します。
Bash(rm *) … これは、rmコマンド（ファイルを削除するコマンド）をまとめて禁止する設定です。例えば、rm file.txtのような特定のファイルを削除するコマンドや、rm -rf fooのようにフォルダを強制的に削除するコマンドなど、どのようなrmコマンドであっても実行を阻止します。誤って大切なファイルを削除してしまうことを防ぐために非常に重要です。

注意: denyは、「この操作は絶対に許さない」という非常に強い指示です。そのため、操作を許可するallowという設定よりも優先されます。危険な操作は、まずdenyで確実にブロックすることが、システムの安全を守る上で最も重要な考え方です。

外部ツール（ウェブブラウザの操作など）をシステムに追加して利用する際、多くの場合、その操作を行うたびに「本当に実行しますか？」といった確認メッセージが表示されます。これは、システムが意図しない操作を行わないようにするための安全対策です。

これらの外部ツールは、mcp__サーバー名__ツール名 という特定の命名規則を持っています。この名前を使って、システムの設定ファイルでツールの利用を許可したり、拒否したりすることができます。

基本的に、システムエンジニアとして設定を行う際には、「使用したいMCPツールだけを allow という設定項目に記述して許可する」のが安全で推奨される方法です。

上記のJSON形式の設定を読み解くと、以下のようになります。

mcp__playwright__browser_navigate とは、Playwrightというツールが提供する機能のうち、「ページの移動」という特定の操作だけを許可するという意味です。これにより、Playwrightの他の機能は許可されず、セキュリティを保ちつつ必要な機能のみを利用できます。
mcp__github__get_* とは、GitHubというサーバーが提供するツールの中で、「get_」で始まるすべてのツールをまとめて許可するという意味です。このように、ツール名の部分（__ の後）にはワイルドカードとして * を使用できます。これにより、get_pull_request や get_issue など、複数の類似したツールを一度に許可することが可能になります。

注意: 許可に関するルールは、システム内で deny（拒否）→ ask（確認）→ allow（許可）の順で評価されます。この評価順序において deny が最も優先されます。もし「allow に特定のツールを記述して許可している」にもかかわらず、「すべてのMCPツールを停止する deny: ["mcp__*"]」という設定を同時に記述してしまうと、allow で許可したはずのツールまでブロックされてしまい、利用できなくなります。特別な理由がない限り、基本的には allow だけで設定を行うようにしてください。

もし特定のサーバー全体をシステムで使わせたくない場合は、そのサーバーを deny 設定に記述します。この場合、そのサーバーに関連するツールは allow には記述しません。

上記の例では、Playwrightサーバーに関連するすべてのツールや機能の利用を拒否しています。

注意: allow でワイルドカードを用いて許可できるのは、mcp__サーバー名__* の形、つまりツール名の部分だけです。「mcp__*」のように、すべてのMCPツールをまとめて許可するようなワイルドカードの使い方は allow ではできません。一方で、deny や ask の設定では、「mcp__*」と記述することで、すべてのMCPツールをまとめて拒否したり、確認の対象にしたりすることが可能です。この違いを理解しておくことが重要です。

MCPで増えたツールをまとめて許可する

外部ツール（ブラウザ操作など）を追加すると、その操作のたびに確認が出る。これらのツールは mcp__サーバー名__ツール名 という名前を持っているので、permissions でも同じ名前で指定できる。

基本は「使うMCPツールだけ allow に入れる」。

読み方はこちら。


1{
2  "permissions": {
3    "allow": [
4      "mcp__playwright__browser_navigate",
5      "mcp__github__get_*"
6    ]
7  }
8}

mcp__playwright__browser_navigate … Playwrightの「ページ移動」だけを許可
mcp__github__get_* … GitHubサーバーの get_ で始まるツールをまとめて許可（__ のあとはワイルドカード * が使える）

注意: 許可ルールは deny → ask → allow の順で評価され、deny が最優先。「allow に入れたツール」と「全部を止める deny: ["mcp__*"]」を同時に書くと、allow したものまでブロックされる。基本は allow だけでOK。

特定のサーバーをまるごと使わせたくないときだけ、そのサーバーを deny に入れる（allow には入れない）。

注意: allow でワイルドカード許可できるのは mcp__サーバー名__* の形（ツール名の部分）だけ。mcp__* のような「全MCPまとめて許可」は allow ではできない。一方、deny / ask では mcp__* で全MCPをまとめて対象にできる。


1{
2  "permissions": {
3    "deny": [
4      "mcp__playwright"
5    ]
6  }
7}

defaultMode で「編集は自動承認」にする

あるツールやシステムが、ファイルを編集したり、新しいファイルを作ったり、ファイルを削除したりする際に、毎回「本当に実行しますか？」と確認してくるのは、少し手間に感じることがありますよね。そのようなときに、特定の操作については「いちいち聞かずに自動で進めてね」と設定できるのが defaultMode です。これは、そのツールが起動したときに、最初にどのような許可のルールで動くかを決める設定のことです。

この例では、「acceptEdits」というモードを「defaultMode」として設定しています。これは、起動時にファイル編集を自動で承認する状態になる、という意味です。

主なモードはこちらです。


1{
2  "permissions": {
3    "defaultMode": "acceptEdits"
4  }
5}

モード	意味
`default`	通常（必要なものは確認する）
`acceptEdits`	ファイル編集に加え、作業ディレクトリ内の `mkdir` / `touch` / `rm` / `rmdir` / `mv` / `cp` / `sed` といった一般的なファイル操作コマンドも確認なしで自動承認。それ以外のコマンド実行などは従来どおり確認
`plan`	まず計画だけ立てて、勝手に変更しない（読み取り中心）

各モードについて詳しく見ていきましょう。

default
- このモードは一番基本的な設定です。ファイルの内容を変更するような重要な操作をする時には、必ず「本当に実行しますか？」と確認してくれます。安全性が高いですが、操作のたびに確認が多くなることがあります。
acceptEdits
- このモードは、ファイルを編集したり、作業しているフォルダーの中で新しいフォルダーを作ったり（mkdir）、ファイルを作ったり（touch）、ファイルを削除したり（rm）、フォルダーを削除したり（rmdir）、ファイルを移動したり（mv）、ファイルをコピーしたり（cp）、ファイルの内容を一部変更したり（sed）といった、よく使うファイル操作については、確認なしで自動的に実行してくれます。ただし、これらの操作以外の、もっと複雑なコマンドの実行などについては、これまで通り確認が入ります。日常的な作業をスムーズに進めたいときに便利なモードです。
plan
- このモードは、ツールに「こういうことをしたい」と指示しても、実際にファイルなどを変更する前に、まず「こういう変更を行いますよ」という計画だけを教えてくれます。実際には何も変更しないので、ファイルの内容を読み込んだり、変更する内容を確認したりする時に使われます。誤って重要なファイルを変更してしまう心配がないため、安全に内容を確認したいときに役立ちます。

注意: acceptEdits は rm などの削除も自動承認の対象。だからこそ、先に Bash(rm *) を deny へ入れておくのが効いてくる（deny が最優先なので、acceptEdits でも rm は止まる）。

acceptEdits モードを使うときに特に注意が必要な点があります。それは、rm コマンドのようなファイルを削除する操作も、確認なしで自動的に承認されてしまうことです。これは非常に危険な場合があります。そのため、もし「ファイルを削除する操作だけは絶対に自動で実行させたくない」という場合は、事前に「rm コマンドを使った削除操作は許可しない（deny）」という特別な設定をしておくことが大切です。なぜなら、「許可しない（deny）」という設定は、他のどんな設定よりも優先されるため、acceptEdits モードが設定されていても、rm による削除は必ず止まって確認されるようになるからです。

注意: bypassPermissions（全部素通り）というモードもあるが、デフォルトにするのは危険。まずは acceptEdits がちょうどいいバランス。

もう一つ、「bypassPermissions」というモードもあります。これは、どんな操作であっても「全て許可し、何も確認しない」という設定です。しかし、このモードを普段使いのデフォルト設定にするのは、誤ってシステムに大きな変更を加えてしまう可能性があるため、大変危険です。最初は、日常的な作業の効率を上げつつ、重要な操作は確認してくれる「acceptEdits」モードを使うのが、安全性と利便性のバランスが取れていて、初心者の方にはちょうど良い選択肢となります。

3つの保存場所（user / project / local）

settings.json は、プロジェクトの動作やルールを決める大切な設定ファイルです。このファイルは、大きく分けて3つの場所に置くことができ、それぞれの設定が持つ影響範囲や優先順位が異なります。より近い場所にある設定ほど、優先的に適用されます。

置き場所	パス	用途	Git管理
プロジェクト共有	`.claude/settings.json`	チーム全員で共有したいルール	コミットする
個人のプロジェクト用	`.claude/settings.local.json`	自分だけの上書き（自動でgitignore）	しない
全プロジェクト共通	`~/.claude/settings.json`	自分の全プロジェクトに効かせたい設定	しない

各保存場所の解説

プロジェクト共有 (.claude/settings.json) このファイルは、プロジェクトのルートディレクトリにある .claude フォルダの中に置かれます。主に、チームのメンバー全員で共有したい共通のルールや設定を記述するために使用します。例えば、「このプロジェクトでは、特定のコマンドの使用を禁止する」といった、チームで守るべき規則を設定する場合に適しています。Gitで管理し、チーム全員で同じ設定が適用されるようにします。
個人のプロジェクト用 (.claude/settings.local.json) こちらもプロジェクトのルートディレクトリにある .claude フォルダの中に置かれますが、ファイル名が settings.local.json となります。このファイルは、主に自分だけが使う一時的な変更や、プロジェクト共有の設定を自分専用に上書きしたい場合に利用します。この設定はGitで管理されないため、他の人には影響を与えずに、自分だけの設定を適用できます。
全プロジェクト共通 (~/.claude/settings.json) このファイルは、ご自身のユーザーディレクトリ（~ はホームディレクトリを指します）にある .claude フォルダの中に置かれます。この設定は、特定のプロジェクトに限らず、ご自身の環境で関わる全てのプロジェクトに共通して適用したい設定を記述するために使用します。例えば、「常に特定のオプションを有効にしたい」といった、自分だけの共通設定をここに記述できます。これもGitでは管理されません。

設定の優先順位

優先順位（強い順）は local > project > user です。

これは、もし同じ設定項目について複数の場所で異なる設定が書かれていた場合、優先順位がより高い場所の設定が採用されることを意味します。例えば、local（個人のプロジェクト用）で設定された内容は、project（プロジェクト共有）や user（全プロジェクト共通）の設定よりも優先されます。

注意: ただし「優先順位＝上書きで消える」ではない。permissions の allow / deny のような配列は、3か所の中身がマージされて全部効く。たとえば project の deny に .env 禁止が入っていれば、local で何を許可しても .env は止まったまま。

この注意点は非常に重要です。一般的な設定項目は優先順位の高いものが低いものを上書きしますが、permissions 内の allow や deny のように、複数の値を持つことができる「配列」の項目については、すべての場所の設定内容が結合（マージ）されて適用されます。

具体的には、project（プロジェクト共有）の settings.json で特定の操作（例: .env ファイルへのアクセス）が deny（禁止）されている場合、たとえ local（個人のプロジェクト用）の settings.local.json でその操作を allow（許可）しようとしても、先に設定された deny の効果が優先され、その操作は禁止されたままとなります。

この仕組みを理解し、以下のように使い分けることができます。

チームで守らせたい deny（例えば、.env ファイルの編集禁止など、セキュリティ上重要な制約）は、project（プロジェクト共有）の settings.json に記述します。これにより、誰かの個人設定で誤って許可されてしまうことを防げます。
自分だけDockerコマンドを許可したいなど、個人に特化した許可設定は local（個人のプロジェクト用）の settings.local.json に記述します。


1{
2  "permissions": {
3    "allow": [
4      "Bash(docker *)"
5    ]
6  }
7}

注意: .claude/settings.local.json は、Claude Code が初めて書き込むときにグローバルの git 除外ファイルへ追加されるため、コミット対象から外れる。自分で手作業で作った場合は除外されないので、自分で .gitignore に追加する。

Claude Code がこのファイルを初めて書き込むとき、グローバルの git 除外ファイル（core.excludesFile の指定先、または ~/.config/git/ignore）に **/.claude/settings.local.json が追加されます。リポジトリの .gitignore が書き換わるわけではありませんが、この除外設定によってコミット対象から外れます。

一方、Claude Code が書き込む前に自分でこのファイルを作成した場合は、この除外設定が行われません。その場合は、自分で .gitignore に .claude/settings.local.json を追加してください。個人用の設定や、APIキーのような秘密情報を扱う際には、git status で追跡対象に入っていないことを確認してから利用してください。

おわりに

本記事では、Claude Codeのsettings.jsonを用いて、開発環境を安全かつ効率的に使う方法を解説しました。特にpermissions設定では、allow、ask、denyの3つの役割を理解し、denyで危険なrmコマンドや.envファイルの読み取りを確実にブロックすることが重要です。また、defaultModeをacceptEditsに設定することでファイル編集作業を効率化しつつ、denyとの組み合わせで安全性を確保できます。複数の設定ファイルはlocal > project > userの優先順位で適用されますが、permissionsはマージされるため、チーム全体のルールと個人の設定を両立できることを理解することが大切です。