Claude Codeのsettings.jsonが反映されない原因｜User・Project・Localの優先順位

Claude Codeのsettings.jsonを変更したのに、権限設定やHook、環境変数、モデル設定などが反映されないことがあります。

たとえばUser設定でBashコマンドを許可したのに毎回確認される、Project側で設定したHookが動かない、.claude/settings.jsonを修正したのに以前の設定が使われ続ける、といったケースです。

この場合、Claude Codeがsettings.jsonを読んでいないとは限りません。

Claude CodeにはUser、Project、Local、Managedなど複数の設定Scopeがあり、同じキーが複数の場所に存在すると優先順位に従って値が決まります。優先順位の考え方自体や権限のdeny/ask/allow評価はClaude Code settings.json完全ガイドやClaude Code 権限・パーミッション設定完全ガイドで詳しく解説しているため、この記事では「設定したのになぜ反映されないのか」という診断にしぼって解説します。

ただし、すべての設定が単純に上書きされるわけではありません。配列型の設定はScopeをまたいで結合されるものがあり、Permissionsではdeny、ask、allowの評価ルールも関係します。

この記事では、Claude Codeのsettings.jsonが反映されないときに確認したいUser、Project、Localの違いと、設定の優先順位、配列のマージ、Managed設定、CLIオプションや環境変数による上書きを解説します。

Claude Codeには複数のsettings.jsonがある

Claude Codeでは、設定を1つのsettings.jsonだけで管理するわけではありません。

個人用のグローバル設定は、

~/.claude/settings.json

へ保存します。Windowsでは通常、

%USERPROFILE%\.claude\settings.json

に相当します。

プロジェクト全員で共有する設定は、Repository内の、

.claude/settings.json

へ保存します。自分だけに適用したいプロジェクト固有設定は、

.claude/settings.local.json

です。

Anthropicの公式ドキュメントでは、User Scopeは全Projectへ適用する個人設定、Project ScopeはGitで共有するチーム設定、Local ScopeはGitへCommitしない個人用Project設定として位置付けられています。

つまり、同じRepositoryであってもClaude Codeは複数の設定ファイルを読み込む可能性があります。

settings.jsonの優先順位はLocalがProjectより高い

Claude Codeで最初に覚えておきたいのが設定Scopeの優先順位です。

通常の設定は、高い順に次のように扱われます。

Managed
↓
Command line arguments
↓
Local
↓
Project
↓
User

User設定よりProject設定が優先され、Project設定よりLocal設定が優先されます。

たとえばUser側のincludeGitInstructions: trueに対してProject側でfalseとしていれば、Project側のfalseが適用されます。さらにLocal側でtrueとしていれば、今度はLocal側が優先されます。

各Scopeの正確なファイルパスや、設定項目ごとの詳しい挙動は前述のガイドにまとめています。

settings.jsonを直してもsettings.local.jsonが勝っていることがある

「.claude/settings.jsonを何度変更しても反映されない」という場合に、特に確認したいのが.claude/settings.local.jsonです。

settings.jsonの値が無視されているように見える代表的な原因として、同じキーがsettings.local.jsonへ設定されているケースが挙げられます。

たとえばProject設定が、

{
  "permissions": {
    "defaultMode": "default"
  }
}

になっていても、Local設定が、

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

なら、Local側が適用されます。

Project側の設定だけを確認していると、settings.jsonを書き換えたのにClaude Codeが変わらないように見えます。

特定のPCだけ挙動が違う場合は、.claude/settings.local.jsonを最初に確認する価値があります。

settings.local.jsonはGitに入らない

settings.local.jsonは個人用設定として設計されています。

Claude Codeがこのファイルを作成した場合、Gitで共有されないようIgnore設定が行われます。

そのため、自分のPCでは動く設定をGitへPushしても、別PCでは動かないというケースが発生します。

たとえばHookを.claude/settings.local.jsonに書いていると、自分の環境では動きますが、別の開発者には共有されません。

チーム全員で使用するHookやPermission設定なら.claude/settings.jsonへ移す必要があります。一方、自分のPCだけで必要なPATHや実験中の設定ならLocal Scopeが適しています。

~/.claude/settings.jsonは全プロジェクトへ適用される

User Scopeの~/.claude/settings.jsonは、Claude Codeを利用するすべてのProjectへ適用されます。

たとえば、

{
  "permissions": {
    "allow": ["Bash(git status)"]
  }
}

と書けば、個人のGlobal Permissionとして利用できます。しかしProject側に同じ設定キーが存在する場合は、Project Scopeのほうが優先されます。

ここで注意したいのが、~/.claude/settings.jsonと~/.claude.jsonは別ファイルだという点です。

~/.claude.jsonにpermissionsを書いても反映されない

Claude Codeにはホームディレクトリに~/.claude.jsonという別のConfiguration Fileも存在します。この2つは同じものではありません。

通常のClaude Code設定は~/.claude/settings.jsonへ書きます。一方~/.claude.jsonには、OAuth Session、UI設定、Projectごとの状態、一部のMCP設定など別のデータが保存されます。

したがって、

{
  "permissions": {
    "allow": ["Bash(npm test)"]
  }
}

を~/.claude.jsonへ書いても、期待どおりのPermission設定にはなりません。

この2ファイルの役割分担や、それぞれに保存される具体的な項目はClaude Code トラブルシューティング完全ガイドで詳しく整理されています。Global Settingなら~/.claude/settings.jsonへ記述してください。

MCPの設定場所もsettings.jsonとは違う

Claude Codeの設定ファイルが複数あることで、MCP周辺も混同しやすくなります。

Project全員で共有するMCP Serverは.mcp.jsonへ保存されます。一方、Claude Codeの一般的なProject設定は.claude/settings.jsonです。

さらにMCPの「local」Scopeは一般設定のLocal Scopeとも保存場所が異なり、.claude/settings.local.jsonではなく、Projectごとの情報として~/.claude.json側(そのProjectのパスに対応する項目)へ保存されます。MCPの「local」という用語は、一般的な.claude/settings.local.jsonとは別物として扱う必要があります。

つまり、MCP Serverを追加したいのに.claude/settings.jsonへ独自にmcpServersを書いたり、Permissionを設定したいのに.mcp.jsonへ書いたりすると、期待した動作になりません。機能ごとにConfiguration Fileを確認する必要があります。

配列設定は高いScopeが丸ごと置き換えるとは限らない

Claude CodeのSettings Priorityで特に勘違いしやすいのがArrayです。

Scalar値なら高いScopeの値が低いScopeを上書きしますが、配列型設定はScope間で結合されるものがあります。permissions.allowやsandbox.filesystem.allowWriteなどの配列値は複数ScopeからConcatされ、重複を除去して最終設定が作られます。

そのため、「Project側でallow配列を書き換えたのにUser側のPermissionが残っている」という現象は、必ずしも設定が反映されていないわけではなく、配列設定のMerge仕様によるものです。配列の正確なマージルールや設定項目ごとの違いはClaude Code settings.json完全ガイドで確認できます。

Permissionではdenyがallowより強い

Permission関連ではScopeの優先順位だけでなく、Permission Rule自体の評価順序も重要です。

Claude CodeのPermissionは、

deny
↓
ask
↓
allow

の順に評価され、最初に一致したRuleが適用されます。

たとえばUser側でBash(npm run *)を許可していても、Project側などにBash(npm run deploy *)のdenyがあれば、Deploy Commandは拒否されます。

「User設定でallowしたのに反映されない」と感じても、別Scopeのdenyが一致している可能性があります。deny/ask/allowの評価順序とツールパターンの書き方はClaude Code 権限・パーミッション設定完全ガイドで詳しく解説しています。

Localでdenyを打ち消すことはできないケースがある

配列型PermissionがScopeをまたいでMergeされることを考えると、「ProjectのdenyをLocalのallowで上書きしたい」という発想もうまくいかない場合があります。

たとえばProject Scopeに、

{
  "permissions": {
    "deny": ["Read(./.env)"]
  }
}

があり、Local Scopeに、

{
  "permissions": {
    "allow": ["Read(./.env)"]
  }
}

を書いたとします。

Permission評価ではdenyが先に確認されるため、.envへのReadをLocalのallowで単純に復活させることはできません。

これは「LocalのほうがProjectより優先度が高い」という説明だけでは判断できない部分です。Permission ArrayはMergeされ、その後Permission Ruleの優先順に評価されるという2段階で考える必要があります。

コマンドライン引数がsettings.jsonより優先される

User、Project、Localをすべて確認しても設定が合わない場合は、Claude Codeの起動Commandも確認してください。

Command Line ArgumentはLocal設定より高い優先順位を持ちます。

たとえばsettings.jsonにdefaultMode: "default"と書いていても、

claude --permission-mode plan

で起動すれば、そのSessionではCommand Line側の設定が優先されます。

同様に、

claude --settings ./my-settings.json

を指定すると、このFileやInline JSONで設定したKeyは通常のUser、Project、Local設定より優先されます。--settingsで指定した値は、同じKeyのFile-based SettingをSession中だけ上書きします。

–settingsで一部だけ上書きしているケース

--settingsを使う場合、すべてのConfigurationを置き換えるわけではありません。

たとえば通常のProject設定が、

{
  "includeGitInstructions": true,
  "permissions": {
    "defaultMode": "default"
  }
}

で、

claude --settings '{"includeGitInstructions":false}'

として起動した場合、指定したincludeGitInstructionsだけが上書きされます。

permissions.defaultModeのように指定していない設定は下位Scopeの値が残ります。--settingsで指定されたKeyはLocal、Project、Userの同じKeyを上書きし、指定しなかったKeyは下位Layerから引き継がれます。

「CLIからsettingsを渡しているからFile側は全部無視される」と考えるのも正しくありません。

Managed設定は最優先でLocalでも上書きできない

会社や組織でClaude Codeを使っている場合はManaged Settingsも確認する必要があります。

Managed Settingsは、User・Project・Local・CLIよりさらに高いPriorityを持ちます。現在のClaude CodeではManaged設定が最上位で、Command Line Argumentからも上書きできません。

たとえば会社側が危険なCommandをManaged Settingsで禁止している場合、自分の.claude/settings.local.jsonへAllow設定を書いても解除できません。これはSecurity Policyとして意図された動作です。

「何を設定しても同じPermissionで拒否される」という場合はManaged Policyが有効になっていないか確認してください。

Managed設定は複数の場所から配信される

Managed Settingsは単純なmanaged-settings.jsonだけとは限りません。

現在のClaude Codeでは、Server-managed、MDMやOS Policy、File-based Managed Settings、Windows Registryなど複数のManaged Sourceを利用できます。

Managed Tier内部にも優先順位があります。2026年9月時点の公式仕様では、Server-managedが最も高く、その後にMDM/OS-level Policy、File-based Managed Settings、Windowsの場合はHKCU Registryと続きます。

ただしManaged Source同士は通常のUser、Project、Localのようにすべてを横断してMergeするわけではなく、最も優先順位の高い、存在するSourceだけが有効になります。

企業PCで原因不明の設定が適用されているなら、自分のRepositoryだけを調べても見つからない可能性があります。

/statusで実際に読み込まれた設定Sourceを確認する

設定が反映されない場合に、最も早く確認できるのが/statusです。

Claude Code内で/statusを実行すると、現在のSessionがどの設定Sourceを読み込んでいるか確認できます。たとえばUser settings、Project settings、Project local settingsなどが表示されます。

Managed Settingsが存在する場合は、Enterprise managed settings (remote)やEnterprise managed settings (file)など、そのSourceも表示されます。

設定ファイルに不正なJSONやValidation Errorがある場合も/statusから確認できます。

つまり、settings.jsonが反映されないと感じたら、まずFileを何度も編集するより、/statusでそのSource自体が読み込まれているか確認すると効率的です。

/statusは個別キーの出所までは表示しない

/statusは便利ですが、注意点もあります。

現在の公式仕様では、Setting sourcesからUser設定・Project設定・Local設定が読み込まれていることは確認できます。しかし、includeGitInstructionsはどのファイルから来たかという個別Key単位のSourceまでは表示しません。

そのためLocal Sourceが表示されていて、特定設定だけ想定と違う場合は、~/.claude/settings.json・.claude/settings.json・.claude/settings.local.jsonから該当Keyを検索する必要があります。

/doctorでJSONやSchemaエラーを確認する

設定ファイルのSyntax自体が間違っている可能性もあります。その場合は/doctorが便利です。

/doctorによってConfiguration FileをValidationし、不正なKeyやSchema Errorなどを検出できます。/doctorが検出できる項目全般や、インストール状態の診断まで含めた使い方はClaude Code トラブルシューティング完全ガイドで解説しています。

たとえばJSONでありがちな、

{
  "includeGitInstructions": false,
}

のようなTrailing Commaは、通常のJSONとしては不正です。JavaScript Objectでは許される記法でも、settings.jsonはJSONなので注意してください。

$schemaを追加すると入力ミスを見つけやすい

Claude Codeのsettings.jsonには公式JSON Schemaを指定できます。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": ["Bash(npm test)"]
  }
}

VS CodeなどJSON Schemaに対応したEditorなら、存在しない設定名や型の間違いを入力中に検出できます。

ただし公開Schemaの更新が最新Claude Code CLIより遅れることもあるため、最近追加された正式なSettingにEditorがWarningを出す可能性があります。Schema Warningだけを見て「その設定は使えない」と決めつけず、現行のClaude Code Documentationも確認してください。

設定Keyを間違えていると反映されない

JSON自体がValidでも、設定名が間違っていれば期待した動作にはなりません。

たとえばHookを独自にhookと書いても、Claude Codeが期待しているのはhooksです。

同様にHook設定を.claude/hooks.jsonへ分離したくなるかもしれませんが、現在のClaude Codeには通常のHook用の独立したhooks.jsonはありません。Hookはhooksとしてsettings.json内に記述します。

Hookが動かない代表例として、Standaloneの.claude/hooks.jsonへ書いてしまっているケースが挙げられます。

Hookだけ反映されない場合はmatcherも確認する

settings.json自体は読み込まれているのにHookだけ動かないケースもあります。この場合はSettings Scopeではなく、Hook定義の問題かもしれません。

たとえば複数Toolへ適用したい場合に、

{
  "matcher": ["Edit", "Write"]
}

と配列を書いているとSchema Errorになります。

現在のClaude Codeでは、複数ToolをMatcherで指定する場合は、

{
  "matcher": "Edit|Write"
}

のように1つのStringとして記述します。さらにTool名はCase Sensitiveです。bashではなくBashを使います。

「settings.json全体が反映されていない」と思っていたら、実際にはHook EntryだけValidationで落ちている場合があります。

settings.jsonの変更は再起動なしで反映される設定もある

Claude Codeの設定変更後、毎回完全に再起動しなければならないわけではありません。

たとえばHookについて、settings.jsonを編集すると、短いFile Stability Delayの後に実行中Sessionへ反映されます。

そのためHookを編集したあと、「Claude Codeを再起動していないから古いまま」とは限りません。一方で設定の種類によって反映タイミングが異なる可能性があるため、挙動が不明な場合は新しいSessionで再現するか確認すると切り分けやすくなります。

環境変数がsettings.jsonより強い設定もある

Claude Codeには、settings.jsonだけでなくEnvironment Variableで変更できる設定もあります。設定によってはEnvironment Variableの値がsettings.jsonより優先されます。

たとえばincludeGitInstructionsについては、

CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS

環境変数が設定値より優先されます。

そのため、includeGitInstructions: trueなのに動作が変わらない場合、ShellやCI、IDE起動環境に対応するEnvironment Variableが設定されていないか確認する必要があります。

環境変数によるOverrideはすべてのSettingに共通する一律ルールではないため、対象Keyの公式リファレンスを確認するのが安全です。

settings.json内のenvも設定Scopeの影響を受ける

Claude Codeでは、

{
  "env": {
    "MY_VARIABLE": "value"
  }
}

のようにSession用Environment Variableを設定できます。このenvも~/.claude/settings.jsonや.claude/settings.jsonなどへ配置できます。

しかし同じ変数名を複数Scopeで設定している場合は、どの値が最終的に使用されているのか確認する必要があります。またClaude Codeを起動したShell自体のEnvironment Variableや、CLIで利用する機能固有のEnvironment Variableが影響する場合もあります。

「envを書いたのにToolから見えない」という場合も、~/.claude.jsonではなくsettings.jsonへ書いているか確認してください。

Project settingsはCLAUDE.mdと探索範囲が同じとは限らない

CLAUDE.mdの探索ルールを、そのままsettings.jsonにも当てはめるのは注意が必要です。

CLAUDE.mdはCurrent Working Directoryと親Directoryをたどって読み込まれる仕組みがありますが、Claude Code Agent SDKの現在の仕様では、Project settings.jsonとHookは<cwd>/.claude/から読み込まれ、親DirectoryへのFallbackは行われません。

そのため自作ツールやAgent SDKからClaude Codeを利用している場合は、cwdの設定が特に重要です。たとえばSDKのcwdをサブディレクトリにしていると、期待していたRootのProject Settingが読み込まれない構成になる可能性があります。

通常のClaude Code CLIだけを利用している場合とSDK利用時では、Current Working Directoryを含む設定探索条件を確認したほうがよいでしょう。CLAUDE.md自体の探索範囲はClaude CodeがCLAUDE.mdを読まない原因で解説しています。

–setting-sourcesでProjectやLocalを除外している可能性がある

Claude Codeには--setting-sourcesというCLIオプションがあります。

たとえば、

claude --setting-sources user,project

とすると、Local Sourceを読み込まない構成にできます。逆に、

claude --setting-sources user

のように起動していれば、.claude/settings.jsonや.claude/settings.local.jsonが読み込まれません。

通常の起動ではUser、Project、Localが利用されますが、ScriptやAlias、Agent SDK経由で特殊な起動オプションを使っている場合は確認してください。

–add-dirした先のsettings.jsonは全部読み込まれるわけではない

Claude Codeではclaude --add-dir ../sharedのように追加DirectoryへのAccessを許可できます。

しかし、追加したDirectory内に.claude/settings.jsonがあるからといって、そのすべてのConfigurationが自動的に現在のProjectへ適用されるわけではありません。

--add-dirで追加したDirectoryから読み込める.claude関連設定は限定され、Hooksなど多くの設定はCurrent Working DirectoryやUser ScopeなどからのみDiscoveryされます。

「共有Directoryを追加したから、そこのsettings.jsonも有効なはず」と考えないよう注意してください。

VS CodeでもCLIでも優先順位は同じ

VS Code ExtensionからClaude Codeを使ったときだけ設定が変わったように感じる場合があります。

現在のClaude Code公式仕様では、Managed、CLI、Local、Project、Userという基本的なSetting Priorityは、CLI、VS Code Extension、JetBrains IDEで共通です。

それでもIDEだけ挙動が違うなら、どのDirectoryをWorkspace Rootとしているか、どのEnvironment Variableを継承して起動しているかを確認したほうがよいでしょう。特にTerminalから起動したClaude CodeとGUI ExtensionではCurrent Working DirectoryやEnvironmentが異なるケースがあります。

設定が反映されないときは最小構成にすると分かりやすい

巨大なsettings.jsonで原因が分からない場合は、一度検証したい設定だけに減らす方法が有効です。

たとえばPermission Modeを調べるなら、

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "plan"
  }
}

程度まで単純化します。

それでもPlan Modeにならなければ、別ScopeやCLI Argument、Managed SettingなどによるOverrideを疑えます。逆にこれで反映されるなら、元のConfiguration内部の別KeyやValidation Errorを調べます。

ただし既存の設定ファイルを不用意に削除するのではなく、バックアップを取ったうえで検証してください。Claude Code自体もConfiguration FileについてTimestamp付きBackupを作成し、最近のBackupを保持する仕組みを持っています。

同じキーをプロジェクト全体から検索する

設定が反映されない原因の多くは、同じKeyが複数Scopeへ書かれていることです。

たとえばdefaultModeが問題なら、~/.claude/settings.jsonだけでなく.claude/settings.json、.claude/settings.local.jsonにも同じKeyがないか確認します。Managed EnvironmentならManaged Policyも対象です。

さらにClaude Codeを起動しているScriptやShell Aliasに--permission-mode、--settings、--setting-sourcesなどが付いていないか確認します。

この順番で調べると、「設定が無視されている」のではなく「別の設定が勝っている」ケースを見つけやすくなります。

settings.jsonが反映されないときに関するよくある質問

settings.jsonが反映されないときは/statusから確認する

Claude Codeのsettings.jsonが反映されない場合、最初に確認したいのは設定の優先順位です。

通常はManaged、Command line、Local、Project、Userの順に優先されます。特に見落としやすいのが.claude/settings.local.jsonで、Local Scopeに同じScalar Settingが存在すると、Projectの.claude/settings.jsonを書き換えてもLocal側が優先されます。

ただしPermissionやSandbox PathのようなArray Settingでは、上位Scopeが下位Scopeを丸ごと置き換えるとは限らず、複数ScopeのArrayが結合されます。そのうえPermissionsではdeny、ask、allowの順にRuleが評価されます。

そのため設定問題を調べるときは、「優先度が高いファイルだけを見る」のではなく、最終的なMerge結果を意識する必要があります。

まずClaude Codeで/statusを実行し、User、Project、Local、ManagedのどのSetting Sourceが現在読み込まれているか確認してください。JSONやSchemaに問題がありそうなら/doctorも利用できます。

さらに~/.claude/settings.jsonと~/.claude.jsonを混同していないか、CLI起動時に--settingsや--permission-modeを指定していないか、対象Settingを上書きするEnvironment Variableがないかを確認します。

Claude Codeの設定トラブルでは、「settings.jsonを読んでいない」と考える前に、どのScopeが読み込まれ、どのScopeまたは起動オプションが最終値を決めているのかを確認することが最も重要です。各Scopeの詳細な仕様はClaude Code settings.json完全ガイド、Permissionの評価順序はClaude Code 権限・パーミッション設定完全ガイド、その他のトラブルシューティング全般はClaude Code トラブルシューティング完全ガイドもあわせて参考にしてください。