設定ファイルの仕組み

Claude Code は 4 つの設定ファイルを読み、組織は claude.ai のコンソールから管理設定（managed settings）も配れます。保存した設定が及ぶ範囲（スコープ）は、自分だけ・プロジェクトの全員・組織の全員のどれかです。全キーの型・既定値・適用範囲は 設定キー一覧、環境変数は 環境変数一覧 にあります。

• 設定ファイルは JSON。コメントや末尾のカンマは構文エラーになる
• 同じキーが複数あると、優先度の高い階層の値が使われる：管理設定 > コマンドライン引数 > ローカル > プロジェクト共有 > ユーザー
• 配列（permissions.allow など）は上書きされず、ファイルをまたいで結合される
• ほとんどの編集は、再起動せず実行中のセッションに反映される
• /status の Setting sources 行で、どのファイルが読み込まれたかを確認できる

設定ファイルと適用範囲#

• 「ファイル」の列で、~/.claude はホームディレクトリの .claude フォルダ、頭に ~/ のない .claude はプロジェクト内の .claude フォルダ
• ~/.claude/settings.json は、このマシンのすべてのプロジェクトに及ぶが、チームメイトのマシンやクラウドセッションには及ばない
• プロジェクトの .claude/settings.json は、バージョン管理にコミットしたときだけ、チームメイトの clone やクラウドセッションに届く（コミットするまでは自分のディスク上の普通のファイル）
• .claude/settings.local.json は、そのプロジェクトの自分にだけ及ぶ。初めて書くとき、Claude Code がグローバルの git の除外設定に足すので、コミットに入らない。手で作った場合は自分で .gitignore に足す
• 管理設定は、managed-settings.json のファイル・MDM ポリシー・claude.ai コンソールのサーバー管理設定のどれでも、組織が配った全マシン・全プロジェクトに及ぶ。クラウドセッションに届くのはサーバー管理設定だけ

設定ファイルを見つける・作る#

Claude Code をインストールしても設定ファイルは作られません。すでにあるなら、次のどれかが由来です。

• 管理：組織が配ったもの。自分で作る・編集するものではない
• プロジェクト共有：Claude Code を使っているプロジェクトなら、コミットされていることがある。なければプロジェクトフォルダの .claude/settings.json に作る
• ユーザーとプロジェクトローカル：自分で作る、または Claude Code に作らせる。/config でテーマなどユーザー設定に保存される項目を初めて変えたときに ~/.claude/settings.json が、権限確認で「Yes, and don't ask again」のような恒久の承認を初めて出したときに .claude/settings.local.json が書かれる。「Show tips」など一部の /config の項目は、ユーザーファイルでなく .claude/settings.local.json に保存される

Claude Code は、自分で書く 5 つ目のファイル ~/.claude.json も持ちます（編集不要）。サインインのセッション・MCP サーバーの設定・信頼の判断などプロジェクトごとの状態・/config が書くグローバル設定のキーが入っています。

チームで設定を共有する#

.claude/settings.json をコミットすれば、clone した全員が同じ権限・フック・プラグインを使えます。各自は自分の .claude/settings.local.json で上書きできるので、個人の例外はコミット不要です。

• コミットした内容の一部は、各チームメイトがフォルダを信頼するまで待たされ、いくつかのキーはリポジトリのファイルからは効かない（詳しくは下の「設定が効かないとき」）
• チームのファイルの例は、下の「設定ファイルの例」にある

個人の設定をリポジトリに入れない#

1 つのプロジェクトで自分だけ設定を変えるには、プロジェクト内の .claude/settings.local.json に保存します。コミットされた .claude/settings.json の上にこのファイルが適用されるので、チームのファイルが "model": "claude-sonnet-5" でも、自分のローカルファイルに "model": "claude-opus-5-5" と書けば、自分のセッションだけが変わります。

• Claude Code もこのファイルに書く。Bash コマンドの確認で「Yes, and don't ask again」を選ぶと、その承認が allow ルールとしてここに保存される
• 手で作ったのでなければ、自分で .gitignore に足す必要はない。git リポジトリで、まだ無視されていないとき初めてこのファイルを書くと、**/.claude/settings.local.json をグローバルの git の除外ファイルに足すので、どのリポジトリでもコミットに入らない。そのファイルは、グローバルの git 設定が絶対パスか ~ 始まりのパスで core.excludesFile を設定していればそれ、なければ $XDG_CONFIG_HOME/git/ignore（XDG_CONFIG_HOME が未設定なら ~/.config/git/ignore）
• 追跡されていないあいだ、このファイルの allow ルールは信頼の手順を待たない（自分のファイルでリポジトリのものではないため）。git で追跡されていれば信頼の手順も適用される

git リポジトリでのローカルファイルの場所#

「Yes, and don't ask again」の承認は .claude/settings.local.json に allow ルールとして保存されます。git リポジトリのサブディレクトリで Claude Code を始めても、このファイルはリポジトリのルートで読み書きされ、承認はリポジトリ全体に効きます。worktree ではメインのチェックアウトのルートのファイルを使います。

• ファイルが .claude/settings.json と同じ場所に留まる場合：git リポジトリの外、リポジトリのルートがホームディレクトリ、Windows、リポジトリのルートかその .git・.claude が自分のユーザーのものでないとき
• ファイル内のパスはリポジトリのルートに固定されない：/ で始まる権限ルールや、サンドボックスの相対パスは、セッションのプライマリ作業ディレクトリに固定される
• v2.1.211 より前は、開始ディレクトリにファイルを置いていた。以前のバージョンが残したファイルも、ルートのファイルと並べて読まれる（同じキーはルートの値が効き、権限ルールは両方が適用される）。Agent SDK の resolveSettings() は、常に開始ディレクトリのファイルを読む
• 共有の .claude/settings.json はセッションのプライマリ作業ディレクトリから読まれるので、リポジトリのルートでコミットしたファイルを使うには、そこで Claude Code を始める。/cd でセッションを移すと、両方のプロジェクトファイルが新しいディレクトリから読まれ、ローカルファイルは同じ規則で置かれる（新しいディレクトリからの読み込みは v2.1.246 以降）

組織が強制しているものを確認する#

組織が Claude Code を管理しているなら、一部の設定は自動で決まり、自分のファイルに何を書いても変わりません。どれかは /status の Setting sources 行が、適用される管理元を示します。管理設定は、このマシンの Claude Code が動くすべての場所で適用されます。

管理設定は、主に次の経路で届きます。

• サーバー管理設定：claude.ai の管理コンソールか、セルフホストの Claude apps gateway から Claude Code が取得する
• MDM や OS レベルのポリシー、システムディレクトリの managed-settings.json
• Claude Desktop など組み込み先のホストが、SDK の managedSettings オプションで渡すもの

Claude Desktop アプリで手元のマシンで動く Cowork セッションでは、Claude Code は claude.ai の管理コンソールからサーバー管理設定を取得しません。組織の Claude Desktop の設定が requireCoworkFullVmSandbox を設定していないかぎり、デバイスに配られたポリシーを読みます。管理者向けの手順は 組織への導入と管理設定 を見てください。

設定を変える#

設定は、/config メニュー・設定ファイルの編集・コマンドラインによる 1 セッションだけの指定で変えられます。Claude Code のシステムプロンプトは公開されていません。常設の指示を与えるには CLAUDE.md か --append-system-prompt を使います（CLAUDE.md とメモリ）。

/config メニューを使う#

Claude Code の中で /config を実行し、「Config」タブを開きます。テーマ・エディタモード・verbose の出力など個人向けの短い一覧で、全キーではありません。項目を選ぶと自動で保存されます。

• ほとんどの項目：~/.claude/settings.json
• 「Show tips」など一部の項目：.claude/settings.local.json
• グローバル設定の項目：~/.claude.json
• メニューを使わず 1 つの項目を設定するには key=value を渡す（/config verbose=true）

設定ファイルを編集する#

変えたいスコープの設定ファイルをエディタで開き、キーを足す・変えます。設定ファイルは厳密な JSON です（// のコメントや末尾のカンマは構文エラーで、次の起動で Settings Error として報告される）。例えば、lint とテストのコマンドを確認なしで実行させ、.env ファイルを読ませないには、~/.claude/settings.json に次を足します。

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

• permissions の各項目は、ツールとそれが何をしてよいかを名指しするルール。書き方は 権限ルール
• $schema の行は、公開されている Claude Code 設定の JSON スキーマを指し、VS Code・Cursor など JSON スキーマに対応するエディタで補完とインライン検証が働く。スキーマは最新の CLI のリリースに遅れることがあるので、最近ドキュメントに載ったキーの検証警告が出ても、設定が無効とは限らない
• 保存したら、Claude Code の中で /status を実行して、ファイルが読み込まれたか確認する

1 セッションだけ設定を変える#

保存せずに値を試すには、Claude Code を起動するときに設定します。値はそのセッションにだけ適用され、設定ファイルはそのままです。方法は 3 つあります。

• --settings：キーを JSON（インラインかファイルのパス）で渡す。ユーザー・プロジェクト・ローカルのファイルの上、管理設定の下に適用される。ユーザー設定ファイルが設定できるキーなら何でも設定できるが、Managed や Global config のキーは設定できない

• そのキー用のフラグ：model に --model、effortLevel と modelSettings に --effort など

• 環境変数：キーと対の変数を claude の前に export する（model に ANTHROPIC_MODEL など）

• 各キーの項は、セッションごとの上書きと優先されるものを挙げているので、変えたいキーの項を確認する

• セッション内のコマンドは多くが選択を保存する。/config で変えると設定ファイルに書かれ、/model は新しいセッションの既定としてその値を保存する。/model のピッカーで s を押すと、ユーザーの既定として保存せずにモデルを切り替える。/effort のどの選択が既定として保存されるかは モデル・effort・fast mode を見る

claude --settings '{"model": "claude-opus-5-5"}'

編集がいつ反映されるか#

Claude Code は設定ファイルを監視し、変更されると再読み込みするので、permissions・hooks・apiKeyHelper などの認証情報のヘルパーを含むほとんどの編集は、再起動なしで実行中のセッションに反映されます。セッション中に作った設定ファイルも、そのフォルダがセッション開始時にあれば読み込まれます（プロジェクトの .claude/ フォルダは、同じセッションで作っても読み込まれる）。

• 再読み込みはユーザー・プロジェクト・ローカル・管理設定を覆い、検出した設定ファイルの変更ごとに ConfigChange フックが実行される（MDM や claude.ai コンソールから届く管理設定では実行されない）。MDM や claude.ai コンソールから届く管理設定は、保存時でなくスケジュールで実行中のセッションに届く
• 一部のキーは、セッション開始時に一度だけ読まれるので、編集しても実行中のセッションには届かない。requiredMinimumVersion など管理者側のキーにも再起動を待つものがある。セッション中に編集しそうなもの：model（セッション中の切り替えには /model。モデルごとにプロンプトキャッシュがあるので、切り替えの後の最初のリクエストは会話全体をキャッシュなしで読み直す）、effortLevel と modelSettings（セッション中に effort を変えるには /effort）

読み込まれたものを確認する#

Claude Code の中で /status を実行すると、有効な設定元が分かります。「Status」タブの Setting sources 行が、現在のセッションで読み込んだ設定ファイル（User settings・Project local settings など）を一覧します。管理設定が有効なら、管理設定の項目が、どう届いたかを括弧内に示します。

• この行は、どのファイルを読んだかを示すだけで、どのファイルがどのキーを供給したかは示さない。Claude Code が拒否した項目を一覧するには claude doctor を実行する。プロジェクトや管理設定が設定したモデルは、起動時のヘッダーが設定したファイルを示す
• /status と /config は同じダイアログを別のタブで開く。「Config」タブは settings.json の中身を見るビューではない

壊れた設定ファイルを直す#

JSON の書き間違いや、Claude Code が受け付けない値を設定すると、対話セッションの開始時に知らされます。表示は、ファイルのどこまでが影響を受けるかで変わります。

• Settings Error：ユーザー・プロジェクト・ローカルのファイルが無効な JSON か、スキーマが拒否する値を持つ。対話セッションの開始時に、Claude の助けでファイルを直す・終了する・壊れた設定なしで続ける、を選べるダイアログが出る
• Settings Warning：不正な形式の権限ルールや未知のフックイベント名など、個々の項目だけが失敗する。Claude Code はその値をスキップし、ファイルの残りは有効のまま
• 管理設定：Claude Code はファイルの残りを引き続き強制する。無効な項目は捨てられ、直すまでより厳しい値にフォールバックするキーがある。管理設定の文書が有効な JSON でないときは別
• 構成エラー：~/.claude.json が解析できない。Claude Code は壊れたファイルを ~/.claude/backups/.claude.json.corrupted.<timestamp> にコピーし、終了して手で直すか既定の構成にリセットするかを尋ねる（-p ではエラーを出して終了）。以前の状態に戻すには、~/.claude/backups/ の、書き込みの前に保存される最新 5 つの .claude.json.backup.<timestamp> のどれかをコピーし戻す
• 続けたあと、影響を受けたファイルは /status、各エラーの詳細は claude doctor で見る
• -p の実行ではダイアログは出ない。管理設定の文書が解析できない場合を除き、壊れたファイルや値をスキップして続けるので、-p の実行が設定を無視したら claude doctor で捨てられたものを確認する

設定の優先順位#

同じキーが複数の場所にあると、そのキーを設定している最も高い階層の値が使われます。上位ほど強く、上位のキーはその下のどこの同じキーも上書きします。優先度の高い順に次のとおりです。

1. 管理設定：managed-settings.json のファイル・MDM ポリシー・claude.ai コンソールのサーバー管理設定で組織が配る設定。何を設定しても上書きできず、--settings で渡したキーも同じ管理キーを上書きできず、--model などのフラグは組織が許可するモデルからだけ選べる。管理設定の model は各セッションが始まるモデルを決めるが、/model での切り替えはできる（ロックは availableModels で、/model・--model・自分のファイルの model を制約する）。組織が複数の管理元を配るときは、管理層内の優先順位が各元から何を読むかを決める
2. コマンドライン引数：端末から claude を起動するときに渡す、1 セッションだけのフラグ。--settings <file-or-json> で渡した JSON は、ほかの階層と同じ規則で設定ファイルとマージされる（ここで設定したキーはローカル・プロジェクト・ユーザー設定の同じキーより優先され、省いたキーは下位の値が残る）
3. プロジェクトローカル設定（.claude/settings.local.json）：このプロジェクトでの自分の個人設定
4. プロジェクト共有設定（.claude/settings.json）：チームがソース管理にチェックインした設定
5. ユーザー設定（~/.claude/settings.json）：全プロジェクトでの自分の個人設定

• 環境変数はこの階層に入らない。同じ動作にシェル変数と設定キーの両方があるとき、どちらが適用されるかは階層でなく対ごとに決まる（シェルで export した ANTHROPIC_MODEL はどのファイルの model キーより優先され、ANTHROPIC_DEFAULT_MODEL はどのファイルも model を設定していないときだけ適用される）。どのキーが対を持ち、どちらを先に読むかは 環境変数一覧。設定ファイル内の env ブロックは普通のキーで、上の階層に従う
• いくつかのセキュリティ上重要なキーでは、Claude Code は、下位の階層の厳しい値を管理設定の値より優先して守る（下の「管理設定の優先順位の例外」）

配列は上書きでなく結合される#

permissions.allow のような同じリストのキーを複数のファイルに設定すると、Claude Code は 1 つを選ばずリストを結合するので、各ファイルがほかのファイルの項目を消さずに項目を足せます。モデルのリストやモデルごとの項目を持つ 4 つのキーは、独自の規則に従います。

• fallbackModel：位置に意味のある順序つきの連鎖なので、定義した最も優先度の高いファイルの値全体を取る
• modelPicker：順序つきの行のリストと置き換えフラグを 1 つ持つので、2 つのソースの行をマージしない。管理設定・--settings・ユーザー設定のうち、定義した最上位の値全体を取り、プロジェクトとローカル設定では無視する（v2.1.242 以降）
• availableModels：Claude Code が適用する管理設定が定義していると、そのリストをそのまま適用し、ユーザー・プロジェクト・ローカルで足した項目は無視する（Claude Code を組み込むアプリが独自のモデルリストを与える場合を除く）。管理元をまたいでもマージしない。管理元でないスコープ間は通常どおり配列をマージする
• modelSettings：effortLevel とともに、モデル 1 つずつ解決する

優先順位の例#

Claude の作業中、スピナーの下に「Use /config to change your default permission mode (including Plan Mode)」のような 1 行のヒントが出ます。ヒントを出したくなくて、~/.claude/settings.json で spinnerTipsEnabled を false にしたとします。次の各場面は、それを再びオンにしうるものと、できることです。

• チームの設定が上書きする：チームの .claude/settings.json が true。プロジェクト共有はユーザーより上なので、そのプロジェクトではヒントが出て、ほかでは出ない。そのプロジェクトの .claude/settings.local.json に "spinnerTipsEnabled": false を足せば、自分のセッションでは出なくなり、チームメイトには影響しない（ローカルは共有より上）
• 組織の設定がすべてを上書きする：管理設定が true。ユーザー・プロジェクト・ローカル設定にも --settings にも、オフにする方法はない（管理が最上位）。/status で適用される管理元を確認し、ポリシーを変えるべきなら管理者に頼む
• コマンドラインが 1 セッションだけファイルを上書きする：claude --settings '{"spinnerTipsEnabled": true}' で始めたセッションは、ファイルが false でも、管理設定を除くすべてのファイルより上なのでヒントを出す。--settings は 1 セッションだけで、どのファイルにも書かないので、次のセッションでは元に戻る
• フラグや環境変数が同じものを設定する：キーによっては、どのファイルが設定したかによらず設定の値を上書きするコマンドラインのフラグか環境変数がある（ANTHROPIC_MODEL は model 設定を、--model は 1 セッションで両方を上書きする）。元に戻せるかはキーによる。変数を unset するかフラグを外し、設定キーの項と環境変数の行で、Claude Code がどれを使うか確認する

設定が効かないとき#

キーを設定したのに Claude Code が従わないときは、まず /status で読み込まれたファイルを確認し、次の症状を探します。広い確認（クリーンな構成のテストを含む）は 設定のデバッグ にあります。

設定した値が無視される#

同じキーを別のものが設定している、ファイルがその値を設定できない、ファイルが読み込まれていない、のどれかです。

• 上位の階層が設定している：別の設定ファイル・--settings フラグ・管理元が、自分のものより上でキーを設定している（優先順位は上のとおり）。フラグや環境変数が単独でキーを上書きしていることもある（キーごとに決まる。キーの項がどちらを使うか示し、env の項が管理 env の値とシェルの export の関係を扱う）
• セキュリティのキーが厳しい値を保つ：一部のキーでは、Claude Code はどのファイルの制限的な値も守る（プロジェクトの true の disableClaudeAiConnectors はオンのまま。管理設定の優先順位の例外を見る）
• ファイルがその値を設定できない：permissions.defaultMode の auto と bypassPermissions は、プロジェクト／ローカル設定からは効かない（ユーザーか管理設定に設定するか、1 セッションなら --permission-mode を渡す。v2.1.257 より前は bypassPermissions がどのファイルからも効いた）。env ブロックのテレメトリのエクスポート変数も、いくつかのオフの値を除き、プロジェクト／ローカル設定からは効かない
• ファイルが壊れている：無効な JSON や拒否された値で、Claude Code がファイルや項目をスキップする（上の「壊れた設定ファイルを直す」）

Claude Code で行った変更が新しいセッションで消える#

/model で既定モデルを保存するなど、Claude Code の中で新しいセッション向けの選択を保存すると、ユーザー設定ファイル ~/.claude/settings.json に書かれます。そのファイルに書き込めない（別のツールが生成する、読み取り専用のコピーへリンクしているなど）と、変更は現在のセッションにだけ適用され、次のセッションでは消えます。ファイルを生成するツールでキーを設定するか、書き込めるファイルに置き換えます。ファイルに書き込めるのに変更が続かないなら、変更が 1 セッションだけのものでなかったか、上位の階層が同じキーを設定していないかを確認します。

管理設定の変更が届かない#

管理元は、配布の表のスケジュールで実行中のセッションに届くので、まずセッションを再起動します。それでも /status が管理者が変えたものと違う管理元を示すなら、より優先度の高い管理元が適用されています。

コミットしたキーがチームメイトに届かない#

.claude/settings.json のキーが、clone した全員に適用されない理由は 2 つあります。

• Claude Code がリポジトリのファイルのキーを無視している：設定キー一覧の「適用範囲」に「ユーザー・ローカルか管理設定」「ユーザーか管理設定」「管理設定のみ」「グローバル設定」があるキーは、共有ファイルからは効かない（リポジトリのファイルがオフにできるごく一部を除く）。「グローバル設定」のキーは ~/.claude.json からだけ効く。env キーの中のテレメトリのエクスポート変数も、いくつかのオフの値を除き、共有ファイルからは効かない
• キーが信頼を待っている：permissions.allow ルール・permissions.additionalDirectories・extraKnownMarketplaces・ほとんどの env の値は、各チームメイトがフォルダを信頼した後にだけ適用される。それまでは確認が出て、ファイルが宣言するマーケットプレイスのプラグインも入らない。deny と ask のルールはすぐ適用される

権限ルールの組み合わせが期待と違う#

• 権限確認で「Yes, and don't ask again」を選んだのに、同じツールでまた確認が出る：その選択はローカルファイルに allow ルールを保存したが、そこの allow は、プロジェクトや管理ファイルの ask ルールには勝たない（順序は 権限ルール）。VS Code 拡張では承認カードで保存先のファイル（全員に効くプロジェクトの共有ファイルを含む）を選べるが、CLI ではローカルファイルにだけ書く
• 組織の allow ルールも自分のものと並んで適用される：想定どおり。組織が allowManagedPermissionRulesOnly を設定しないかぎり、Claude Code は permissions.allow をスコープ間でマージする

管理設定の優先順位の例外#

値がセッションを制限するいくつかのキーでは、管理設定を上書きできないスコープからでも、Claude Code は制限的な値を守ります。

Claude Code を自分の中で動かし、CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST を設定するアプリも例外です。Claude Code は、そのアプリのモデル構成を、すべての管理元の model・fallbackModel・modelPicker・modelOverrides と、管理 env ブロックのモデル選択の変数（ANTHROPIC_MODEL と ANTHROPIC_DEFAULT_*_MODEL ファミリー）より優先します。アプリが独自の許可リストを与えないかぎり、管理設定の availableModels は有効のままです。

クラウドセッションでの設定#

クラウドセッションは、自分のマシンでなく、リポジトリの新しい clone があるクラウド環境で動きます。そのため、届く設定が変わります。

• プロジェクト共有設定（.claude/settings.json）：リポジトリ 1 つのセッションでは読まれる（ファイルが clone の一部で、セッションがその中で始まるため）。そこにコミットした設定が、そのセッションで有効になる。複数のリポジトリのセッションは clone の上で始まり、各リポジトリの .claude/settings.json から enabledPlugins と extraKnownMarketplaces のキーだけを読み、権限ルール・フック・env などほかのキーは読まない。この 2 つのキーが宣言するマーケットプレイスとプラグインも、クラウドセッションでは読み込まれない
• ユーザーとプロジェクトローカルの設定（~/.claude/settings.json と .claude/settings.local.json）：読まれない。どちらも手元のマシンにあり、ローカルファイルは clone に入らない
• 管理設定：デバイスの managed-settings.json や MDM プロファイルはクラウドセッションに届かない。組織のサーバー管理設定は届く。セルフホストの環境は、ランナーイメージの管理設定ファイルも読む
• /config：claude.ai/code のブラウザでは、値を変えず、claude.ai の設定の Claude Code のセクションを開く。クラウドセッションの設定を変えるには、環境に環境変数を設定するか、リポジトリ 1 つのセッションならそのリポジトリの .claude/settings.json にキーをコミットする
• CLAUDE.md・スキル・MCP サーバー・プラグイン・認証情報は、クラウド（Web）で使う を見る

設定ファイルの例#

3 つの settings.json の例です。それぞれ 1 人の読者向けのもっともらしいファイルで、形を見て、必要な部分をコピーできます。推奨のベースラインではありません。値の型・既定・設定できる場所は 設定キー一覧 を見てください。コメントは設定ファイルでは受け付けられないので、下はコメントなしでそのまま保存できる形です。

自分の設定#

個人の設定の例です。モデルと effort を選び、ターミナルを調整し、読み取り専用のコマンドとファイル読み取り 1 つを事前承認します。ここにないものは既定のままです。~/.claude/settings.json に置き、開くすべてのプロジェクトに適用されます。

{
  "model": "claude-sonnet-5",
  "modelSettings": {
    "claude-sonnet-5": { "effortLevel": "xhigh" }
  },
  "editorMode": "vim",
  "theme": "light-daltonized",
  "statusLine": {
    "type": "command",
    "command": "jq -r '\"[\\(.model.display_name)] \\(.context_window.used_percentage // 0)% context\"'",
    "padding": 2
  },
  "spinnerTipsEnabled": false,
  "preferredNotifChannel": "terminal_bell",
  "permissions": {
    "allow": [
      "Bash(git diff *)",
      "Read(~/.zshrc)"
    ]
  },
  "autoUpdatesChannel": "stable",
  "cleanupPeriodDays": 20
}

• model：すべてのセッションを Sonnet 5 で始める
• modelSettings：Sonnet 5 を既定の high より上の xhigh で動かす（/effort はモデルごとにレベルを保存し、--effort は 1 セッションだけ設定する）
• editorMode：プロンプトで vim のキーバインド
• theme：色覚に配慮した light のテーマ
• statusLine：プロンプトの下に、モデル名と使ったコンテキストを出すステータスライン
• spinnerTipsEnabled：スピナーの下で回るヒントを隠す
• preferredNotifChannel：完了したタスクや待機中の権限確認の通知で、ターミナルのベルを鳴らす
• permissions.allow：git diff と .zshrc の読み取りを確認なしで許す
• autoUpdatesChannel：stable チャネルから更新を受ける
• cleanupPeriodDays：20 日より古いセッションのトランスクリプトとローカルのセッションデータを削除する

チームの共有設定#

リポジトリにコミットし、clone した全員が同じ権限・フック・プラグインのマーケットプレイスを使えるようにするチームの共有設定です。リポジトリの最上位の .claude/settings.json に置きます。コミットする前に知っておくこと：

• クラウドセッションも読む：クラウドセッションはリポジトリの clone から始まるので、コミットしたファイルもそこで適用される
• テレメトリは管理設定か個人設定に置く：Claude Code は、リポジトリの設定ファイルの OpenTelemetry エクスポーター変数を、テレメトリをオフにするいくつかの値を除いて無視する。組織の管理設定か、各自の ~/.claude/settings.json に置く
• allow ルールは信頼を待つ：allow ルールと extraKnownMarketplaces の項目は、各人がこのフォルダ自体を（親フォルダだけでなく）信頼した後に有効になる。deny と ask のルールは、信頼の有無によらずすべてのセッションで適用される
• フックはリポジトリ内のスクリプト：このファイルのフックは .claude/hooks/block-rm.sh を実行する（フックの書き方は フックの使い方）
• ルールはコマンドとパスを書かれたとおりに照合する：Bash(git push *) は git -C . push に一致しない。Read(./.env) だけでは、ファイルツールと、ファイルを名指しするコマンド（cat .env）は止まるが、ディレクトリに対する grep -r は止まらない。このファイルの sandbox ブロックがその隙間を埋める（サンドボックスは、Read の deny のパスを、サンドボックス内のすべてのコマンドが読めないものに加えるため）

{
  "permissions": {
    "allow": ["Bash(npm run *)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-rm.sh"
          }
        ]
      }
    ]
  },
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": { "source": "github", "repo": "acme-corp/claude-plugins" }
    }
  },
  "enabledPlugins": {
    "code-formatter@acme-tools": true
  },
  "sandbox": {
    "enabled": true,
    "filesystem": { "allowWrite": ["/tmp/build"] },
    "network": { "allowedDomains": ["registry.npmjs.org", "*.example.com"] }
  },
  "plansDirectory": "./plans"
}

• permissions：npm のスクリプトは確認なしで実行、git push の前に確認、env ファイルと secrets フォルダのファイルツールとファイル読み取りコマンドによる読み取りを拒否
• hooks：各 Bash コマンドの前に、リポジトリ内のスクリプトを実行する（コマンドをブロックできる）
• extraKnownMarketplaces：チームのプラグインのマーケットプレイスを、すべての clone に登録する
• enabledPlugins：そのマーケットプレイスの 1 つのプラグインを有効にする（GitHub リポジトリなど外部のソースのプラグインは、各人が 1 回インストールする必要がある）
• sandbox：コマンドをサンドボックスで動かす。書き込み可能なビルドディレクトリ、npm と example.com は事前に許可
• plansDirectory：計画ファイルをリポジトリの中に置く

組織の管理設定#

管理キーの形を、各キーにもっともらしい値で示す managed-settings.json です。推奨のポリシーではありません。要件に合うキーを選び、自分の値を設定してください。この例が設定するキーは次のとおりです。

• forceLoginMethod と forceLoginOrgUUID：ログイン方法と組織を固定する
• availableModels と enforceAvailableModels：セッションが使えるモデルを制限する
• permissions.deny：2 つのファイル読み取りと、Claude が書いたとおりの curl コマンドを拒否し、disableBypassPermissionsMode で bypass の権限モードを外す
• allowManagedPermissionRulesOnly と allowManagedMcpServersOnly：管理設定の権限と MCP の許可リストだけを有効にする
• allowedMcpServers：MCP サーバーを URL で固定する
• strictKnownMarketplaces：プラグインのマーケットプレイスを 1 つだけ許可する
• sandbox：固定のネットワーク許可リストでコマンドをサンドボックスで動かし、サンドボックス外での再試行を許さない。failIfUnavailable キーで、サンドボックスが動かない環境では Claude Code の起動を止められる（サンドボックス）
• requiredMinimumVersion：Claude Code の最小バージョン
• cleanupPeriodDays：セッションのトランスクリプトなどのローカルデータの保持を 7 日に短くする
• companyAnnouncements：起動時にメッセージを出す

管理者は、このようなファイルを managed-settings.json として配るか、同じ JSON を MDM やサーバー管理設定で配ります。配った 1 つのファイルは、届くすべてのマシンやアカウントに適用されます。グループごとに別の値にするには、そのグループに別のファイルかプロファイルを配ります（サーバー管理設定はまだグループごとのポリシーに対応していない）。組織の UUID・サーバー URL・マーケットプレイスの例は、自分のものに置き換えます。

{
  "forceLoginMethod": "claudeai",
  "forceLoginOrgUUID": ["xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"],
  "availableModels": ["opus", "sonnet"],
  "enforceAvailableModels": true,
  "permissions": {
    "deny": ["Bash(curl *)", "Read(./.env)", "Read(./secrets/**)"],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" }
  ],
  "allowManagedMcpServersOnly": true,
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "acme-corp/approved-plugins" }
  ],
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": ["registry.npmjs.org", "github.com"],
      "allowManagedDomainsOnly": true
    }
  },
  "requiredMinimumVersion": "2.1.150",
  "cleanupPeriodDays": 7,
  "companyAnnouncements": [
    "Welcome to Acme Corp! Review our code guidelines at docs.example.com"
  ]
}

• ログインは claude.ai アカウントだけ、かつこの組織だけ
• モデルは Opus と Sonnet だけ。enforceAvailableModels で「Default」の行もこのリストに従う
• permissions.deny：全マシンで、curl コマンドとプロジェクトの .env と secrets フォルダの読み取りを拒否。disableBypassPermissionsMode で全セッションから bypass の権限モードを外す
• allowManagedPermissionRulesOnly：ユーザー・プロジェクト・ローカル設定の権限ルールを無視する
• allowedMcpServers：GitHub の MCP サーバーだけを、名前でなく URL で照合する（ユーザーは任意のサーバーを「github」と名付けられるため）。一致しないユーザー追加のサーバーは読み込まれない（リストに URL の項目しかないとき、stdio のサーバーもすべて含む）。allowManagedMcpServersOnly により、この管理リストが唯一の許可リストになる
• strictKnownMarketplaces：プラグインはこのマーケットプレイスからだけ入れられる
• sandbox：Claude が実行するすべてのコマンドをサンドボックスに入れ、サンドボックスが準備できなければ起動を拒否し、ブロックされたコマンドをサンドボックス外で再試行させない。ネットワークは npm と GitHub に限り、ユーザーはドメインを足せない
• requiredMinimumVersion：2.1.150 より古いバージョンでは起動を拒否する
• cleanupPeriodDays：セッションのトランスクリプトとローカルのセッションデータを 7 日後に削除する
• companyAnnouncements：全ユーザーが起動時に見るメッセージ

関連ページ#

• 設定キー一覧：全キーと、置ける場所・例
• 権限ルール：allow・ask・deny のルールの書き方
• 環境変数一覧：Claude Code が読む変数と env ブロック
• 設定のデバッグ：設定が効かないとき
• .claude ディレクトリの中身：サブエージェント・MCP サーバー・プラグイン・CLAUDE.md を含む、Claude Code が読むすべてのファイル
• 組織への導入と管理設定：何を強制するかの決め方