/config コマンドを実行することで Claude Code を構成できます。これにより、ステータス情報を表示し、構成オプションを変更できるタブ付き設定インターフェースが開きます。v2.1.181 以降では、/config に key=value を渡すことで、インターフェースを開かずに単一のオプションを変更できます。例えば /config verbose=true のようにします。
構成スコープ
Claude Code は、スコープシステムを使用して、構成がどこに適用され、誰と共有されるかを決定します。スコープを理解することで、個人使用、チーム協力、またはエンタープライズデプロイメント用に Claude Code を構成する方法を決定するのに役立ちます。利用可能なスコープ
各スコープを使用する場合
Managed スコープは以下の用途です:- 組織全体で強制する必要があるセキュリティポリシー
- オーバーライドできないコンプライアンス要件
- IT/DevOps により展開される標準化された構成
- すべての場所で必要な個人設定(テーマ、エディター設定)
- すべてのプロジェクト全体で使用するツールとプラグイン
- API キーと認証(安全に保存)
- チーム共有設定(権限、hooks、MCP サーバー)
- チーム全体が持つべきプラグイン
- コラボレーター全体でのツール標準化
- 特定のプロジェクトの個人的なオーバーライド
- チームと共有する前に構成をテストする
- 他のユーザーには機能しないマシン固有の設定
スコープの相互作用
同じ設定が複数のスコープで構成されている場合、Claude Code は優先順位の順序でそれらを適用します:- Managed(最高) - 何によってもオーバーライドできない
- コマンドライン引数 - 一時的なセッションオーバーライド
- Local - プロジェクトとユーザー設定をオーバーライド
- Project - ユーザー設定をオーバーライド
- User(最低) - 他に何も設定を指定しない場合に適用
spinnerTipsEnabled が true に設定されており、プロジェクト設定で false に設定されている場合、プロジェクト値が適用されます。権限ルールはオーバーライドするのではなく、スコープ全体でマージされるため、異なる動作をします。設定の優先順位を参照してください。
スコープを使用する機能
スコープは多くの Claude Code 機能に適用されます:
Windows では、
~/.claude として表示されるパスは %USERPROFILE%\.claude に解決されます。
設定ファイル
settings.json ファイルは、階層的な設定を通じて Claude Code を構成するための公式メカニズムです:
-
ユーザー設定は
~/.claude/settings.jsonで定義され、すべてのプロジェクトに適用されます。 -
プロジェクト設定はプロジェクトディレクトリに保存されます:
-
.claude/settings.jsonソース管理にチェックインされ、チームと共有される設定用 -
.claude/settings.local.jsonチェックインされない設定用。個人設定と実験に役立ちます。Claude Code は作成時に.claude/settings.local.jsonを無視するように git を構成します。自分でファイルを作成する場合は、gitignore に手動で追加してください。 このファイルはリポジトリのものではなく、あなたのものであるため、その権限allowルールは、.claude/settings.jsonallow ルールが必要とするワークスペース信頼ステップなしで有効になります。リポジトリがファイルを提供する場合(たとえば、コミットすることで)、ワークスペース信頼は引き続き適用されます。
-
-
Managed 設定:集中管理が必要な組織向けに、Claude Code は managed 設定の複数の配信メカニズムをサポートしています。すべて同じ JSON 形式を使用し、ユーザー設定またはプロジェクト設定でオーバーライドできません:
- サーバー管理設定:Anthropic のサーバーから Claude.ai 管理コンソール経由で配信されるか、自己ホスト型の Claude apps gatewayから配信されます。サーバー管理設定を参照してください。
-
MDM/OS レベルのポリシー:macOS と Windows のネイティブデバイス管理を通じて配信されます:
- macOS:
com.anthropic.claudecodemanaged preferences ドメイン。plist のトップレベルキーはmanaged-settings.jsonをミラーリングし、ネストされた設定は辞書として、配列は plist 配列として機能します。Jamf、Iru(Kandji)、または同様の MDM ツールの構成プロファイルを通じて展開します。 - Windows:
HKLM\SOFTWARE\Policies\ClaudeCodeレジストリキーと JSON を含むSettings値(REG_SZ または REG_EXPAND_SZ)。グループポリシーまたは Intune を通じて展開します - Windows(ユーザーレベル):
HKCU\SOFTWARE\Policies\ClaudeCode(最低ポリシー優先度、管理者レベルのソースが存在しない場合のみ使用)
- macOS:
-
ファイルベース:
managed-settings.jsonとmanaged-mcp.jsonをシステムディレクトリに展開:- macOS:
/Library/Application Support/ClaudeCode/ - Linux と WSL:
/etc/claude-code/ - Windows:
C:\Program Files\ClaudeCode\
managed-settings.jsonと同じシステムディレクトリ内のmanaged-settings.d/ドロップインディレクトリもサポートしています。これにより、別々のチームが単一ファイルの編集を調整することなく、独立したポリシーフラグメントを展開できます。 systemd 規則に従い、managed-settings.jsonが最初にベースとしてマージされ、その後、ドロップインディレクトリ内のすべての*.jsonファイルがアルファベット順にソートされてマージされます。スカラー値の場合、後のファイルが前のファイルをオーバーライドします。配列は連結され、重複排除されます。オブジェクトはディープマージされます。.で始まる隠しファイルは無視されます。 マージ順序を制御するには、数値プレフィックスを使用します。たとえば、10-telemetry.jsonと20-security.jsonです。 - macOS:
Managed デプロイメントは、strictKnownMarketplacesを使用してプラグインマーケットプレイスの追加を制限することもできます。詳細については、Managed マーケットプレイス制限を参照してください。 -
その他の構成は
~/.claude.jsonに保存されます。このファイルには、OAuth セッション、MCP サーバーユーザーおよびローカルスコープの構成、プロジェクトごとの状態(許可されたツール、信頼設定)、およびさまざまなキャッシュが含まれます。プロジェクトスコープの MCP サーバーは.mcp.jsonに別途保存されます。
Claude Code は構成ファイルのタイムスタンプ付きバックアップを自動的に作成し、データ損失を防ぐために最新の 5 つのバックアップを保持します。
Example settings.json
$schema 行は、Claude Code 設定の公式 JSON スキーマを指しています。これを settings.json に追加すると、VS Code、Cursor、および JSON スキーマ検証をサポートする他のエディターでオートコンプリートとインライン検証が有効になります。
公開されたスキーマは定期的に更新され、最新の CLI リリースで追加された設定を含まない場合があるため、最近ドキュメント化されたフィールドの検証警告は、必ずしも構成が無効であることを意味しません。
編集がいつ有効になるか
Claude Code は設定ファイルを監視し、変更時に再読み込みするため、ほとんどのキーへの編集は再起動なしで実行中のセッションに適用されます。これにはpermissions、hooks、および apiKeyHelper などの認証情報ヘルパーが含まれます。再読み込みはユーザー、プロジェクト、ローカル、および managed 設定をカバーし、ConfigChange hookが検出された各変更に対して発火します。
いくつかのキーはセッション開始時に 1 回読み込まれ、次の再起動時に適用されます:
model:セッション中に切り替えるには/modelを使用しますoutputStyle:システムプロンプトの一部。/clearまたは再起動時に再構築されます
Managed 設定の無効なエントリ
Managed 設定は寛容に解析されます。managed 構成にスキーマ検証に失敗するエントリが含まれている場合、Claude Code はそのエントリを削除し、警告を記録し、残りのすべての有効なポリシーを強制します。単一のタイプミスが組織のポリシーの残りを無効にすることはできません。/doctorを実行して、削除されたエントリをそのソースファイルとフィールドとともにリストします。
この動作は、3 つすべての配信メカニズム全体で一貫しています:サーバー管理設定、MDM を通じてデプロイされた plist およびレジストリポリシー、および managed-settings.json ファイル。Claude Code v2.1.169 以降が必要です。
セキュリティ強制フィールドは、存在するが無効な場合、全体的に削除されるのではなく、フィールドごとに処理されます:
requiredMinimumVersion と requiredMaximumVersion は設計上失敗して開きます:無効な値は強制されるのではなく削除されるため、不正なポリシープッシュが Claude Code の起動を防ぐことはできません。
検証エラーは 3 つの場所に表示されます:
- インタラクティブセッションは起動時に無効なエントリをリストするダイアログを表示します。
-pを使用したヘッドレス実行は stderr にサマリーを出力します。claude doctorは各無効なエントリをそのソースとフィールドとともにリストします。
claude doctor を実行して検証してから、フロート全体に展開します。
この寛容さは managed 設定にのみ適用されます。ユーザー、プロジェクト、およびローカル設定ファイルは厳密なままです:検証に失敗するファイルは全体として拒否され、報告されます。
利用可能な設定
settings.json は多くのオプションをサポートしています:
グローバル構成設定
これらの設定はsettings.json ではなく ~/.claude.json に保存されます。これらを settings.json に追加すると、スキーマ検証エラーがトリガーされます。
v2.1.119 より前のバージョンでは、
theme、verbose、editorMode、autoCompactEnabled、および preferredNotifChannel も settings.json ではなくここに保存されます。Worktree 設定
--worktree が git worktrees を作成および管理する方法を構成します。
gitignored ファイル(
.env など)を新しい worktrees にコピーするには、設定の代わりにプロジェクトルートの .worktreeinclude ファイルを使用します。
権限設定
権限ルール構文
権限ルールはTool または Tool(specifier) の形式に従います。ルールは順序で評価されます:最初に拒否ルール、次に ask、次に allow。最初に一致するルールが優先されます。権限ルール評価順序を参照してください。
クイック例:
ワイルドカード動作、Read、Edit、WebFetch、MCP、および Agent ルール用のツール固有パターン、および Bash パターンのセキュリティ制限を含む完全なルール構文リファレンスについては、権限ルール構文を参照してください。
サンドボックス設定
高度なサンドボックス動作を構成します。サンドボックスは bash コマンドをファイルシステムとネットワークから分離します。詳細については サンドボックスを参照してください。サンドボックスパスプレフィックス
filesystem.allowWrite、filesystem.denyWrite、filesystem.denyRead、filesystem.allowRead、および credentials.files のパスは、これらのプレフィックスをサポートしています:
古い
//path プレフィックスは絶対パスに対して引き続き機能します。以前に単一スラッシュ /path を使用してプロジェクト相対解決を期待していた場合は、./path に切り替えてください。この構文は Read および Edit 権限ルールと異なります。これは //path を絶対パスに、/path をプロジェクト相対に使用します。サンドボックスファイルシステムパスは標準的な規則を使用します:/tmp/build は絶対パスです。
構成例:
sandbox.filesystem設定(上記):OS レベルのサンドボックス境界でパスを制御します。これらの制限は、Claude のファイルツールだけでなく、すべてのサブプロセスコマンド(例:kubectl、terraform、npm)に適用されます。- 権限ルール:
Editallow/deny ルールを使用して Claude のファイルツールアクセスを制御し、Readdeny ルールを使用して読み取りをブロックし、WebFetchallow/deny ルールを使用してネットワークドメインを制御します。これらのルールからのパスもサンドボックス構成にマージされます。
属性設定
Claude Code は git コミットとプルリクエストに属性を追加します。これらは個別に構成されます:- コミットはデフォルトでgit トレーラー(
Co-Authored-Byなど)を使用し、カスタマイズまたは無効にできます - プルリクエストの説明はプレーンテキストです
デフォルトコミット属性:
attribution 設定は非推奨の includeCoAuthoredBy 設定よりも優先されます。すべての属性を非表示にするには、commit と pr を空の文字列に設定し、sessionUrl を false に設定します。ファイル提案設定
@ ファイルパスオートコンプリート用のカスタムコマンドを構成します。組み込みファイル提案は高速ファイルシステムトラバーサルを使用しますが、大規模なモノレポは事前構築されたファイルインデックスやカスタムツールなどのプロジェクト固有のインデックスから利益を得る可能性があります。
CLAUDE_PROJECT_DIR を含む)で実行されます。query フィールドを含む JSON を stdin 経由で受け取ります:
フッターリンクバッジ
footerLinksRegexes 設定は、入力ボックスの下のフッターに追加のクリック可能なバッジをレンダリングします。プロジェクト CLI によって出力される ID(レビューツールと問題トラッカーなど)をセッションリンクに変換するために使用します。
各エントリの pattern 正規表現はターン出力に対してマッチされます:ツール結果(ファイルコンテンツとフェッチされたページを含む)および Claude 自身の応答。url と label の {name} プレースホルダーはパターンの名前付きキャプチャグループから入力されます。
次の例は、PROJ-1234 のような問題キーがターン出力に表示されるたびにバッジをレンダリングします。(?<key>...) 名前付きグループはキーをキャプチャし、{key} は URL とラベルに置き換えられます:
~/.claude/settings.json
PROJ-1234 がツール結果または Claude の返信に表示されると、PROJ-1234 チップがフッターに表示され、https://issues.example.com/browse/PROJ-1234 にリンクされます。
各エントリに以下の制約が適用されます:
ターンが完了すると、Claude Code はメインスレッドでターン出力に対して各エントリの
pattern 正規表現をマッチします。そのため、遅い正規表現は UI をブロックしてセッションを凍結するまでブロックします。(a+)+$ などのネストされた量指定子は、特定の入力に対して指数関数的に長くかかる可能性があるため、各 pattern を線形に保ち、+ または * の ネストを避けます。
フッターバッジは、構成されている場合、カスタムステータスラインと並んでレンダリングされます。どちらも他方を置き換えません。セッションデータから独自のコンテンツを計算するスクリプト駆動行にはステータスラインを使用し、スクリプトなしで会話から ID をリンクに変換するにはフッターバッジを使用します。
Hook 構成
これらの設定は、どの hooks が実行を許可されるか、および HTTP hooks がアクセスできるものを制御します。allowManagedHooksOnly 設定は managed 設定でのみ構成できます。URL と環境変数ホワイトリストは任意の設定レベルで設定でき、ソース全体でマージされます。
allowManagedHooksOnly が true の場合の動作:
- Managed hooks と SDK hooks が読み込まれます
- managed 設定
enabledPluginsで強制的に有効にされたプラグインからの Hooks が読み込まれます。これにより、管理者は組織マーケットプレイスを通じて検証済みの hooks を配布しながら、他のすべてをブロックできます。信頼は完全なplugin@marketplaceID によって付与されるため、別のマーケットプレイスからの同じ名前のプラグインはブロックされたままです - ユーザー hooks、プロジェクト hooks、およびその他すべてのプラグイン hooks はブロックされます
* をサポートします。配列が定義されている場合、一致しない URL をターゲットにする HTTP hooks はサイレントにブロックされます。ホスト名マッチングは大文字と小文字を区別せず、末尾の FQDN ドットを無視し、DNS セマンティクスに一致します。
allowedEnvVars はこの設定との交差です。
ポリシーヘルパーで managed 設定を計算
policyHelper 設定は、起動時に managed 設定を動的に計算する実行可能ファイルを指しています。管理者は、静的ファイルの代わりに、デバイスの状態、ID、またはリモートサービスからポリシーを導出できます。MDM またはシステム managed-settings.json ファイルから構成します。Claude Code は、ユーザー設定、プロジェクト設定、HKCU レジストリハイブ、および サーバー管理設定を含む他のスコープに表示される policyHelper を無視します。
設定は以下のキーを受け入れます:
ヘルパーは JSON エンベロープを stdout に書き込みます。設定をトップレベルではなく
managedSettings キーの下に配置します。ベアの設定オブジェクトは managedSettings が未定義で解析され、何も適用されないためです:
managedSettings を出力すると、そのオブジェクトは実行のためにファイルベースの managed 設定を置き換えます。ヘルパーが起動時にゼロ以外で終了すると、Claude Code はエラーを出力し、起動を拒否します。そのため、停止復旧が必要なヘルパーは独自のキャッシュから提供し、0 で終了する必要があります。
設定の優先度
設定は優先度の順に適用されます。最高から最低:-
Managed 設定(サーバー管理、MDM/OS レベルのポリシー、または managed 設定)
- IT がサーバー配信、MDM 構成プロファイル、レジストリポリシー、または managed 設定ファイルを通じて展開するポリシー
- コマンドラインの引数を含む他のレベルでオーバーライドできません
- managed ティア内では、優先度は:
policyHelper出力(構成されている場合は唯一の managed ソースとして使用)> リモート(claude.ai サーバー管理または Claude apps gateway配信)> MDM/OS レベルのポリシー > ファイルベース(managed-settings.d/*.json+managed-settings.json)> HKCU レジストリ(Windows のみ)です。1 つの managed ソースのみが使用されます。ソースはマージされません。ただし、サンドボックスロックキーsandbox.network.allowManagedDomainsOnlyとsandbox.filesystem.allowManagedReadPathsOnly、それらの関連ホワイトリスト、allowAllClaudeAiMcps、およびサンドボックスバイナリパスsandbox.bwrapPathとsandbox.socatPathは、管理者制御の managed ソースがそれらを設定する場合に尊重されます。ユーザー書き込み可能な HKCU ティアは除外されます。ファイルベースティア内では、ドロップインファイルとベースファイルがマージされます。 - Agent SDK または IDE 拡張機能などの埋め込みホストプロセスによってプログラム的に提供される managed 設定。デフォルトではこれは管理者デプロイ済みの managed ティアが存在する場合は無視されます:サーバー管理設定、MDM または OS レベルのポリシー、または managed 設定ファイル。ユーザー書き込み可能な HKCU レジストリフォールバックは管理者デプロイ済みソースとしてカウントされません。管理者は
parentSettingsBehaviorを"merge"に設定することでオプトインできます。埋め込み側の値はフィルタリングされるため、managed ポリシーを厳しくできますが、緩くすることはできません。
-
コマンドラインの引数
- 特定のセッションの一時的なオーバーライド。JSON は
--settings <file-or-json>を通じて渡され、ファイルベース設定と同じルールを使用して他のレイヤーとマージされます:ここで設定されたキーはローカル、プロジェクト、またはユーザー設定の同じキーをオーバーライドし、キーを省略すると下位レイヤーの値が保持されます
- 特定のセッションの一時的なオーバーライド。JSON は
-
ローカルプロジェクト設定(
.claude/settings.local.json)- 個人的なプロジェクト固有の設定
-
共有プロジェクト設定(
.claude/settings.json)- ソース管理内のチーム共有プロジェクト設定
-
ユーザー設定(
~/.claude/settings.json)- 個人的なグローバル設定
permissions.defaultMode を acceptEdits に設定しているが、プロジェクトの共有設定がそれを default に設定している場合、プロジェクト値が適用されます。以下の例は、配列値の設定(権限ルールなど)がどのように結合されるかについて説明しています。
配列設定はスコープ全体でマージされます。 同じ配列値の設定(
sandbox.filesystem.allowWrite や permissions.allow など)が複数のスコープに表示される場合、配列は連結および重複排除され、置き換えられません。これは、低優先度のスコープが高優先度のスコープで設定されたエントリをオーバーライドすることなくエントリを追加でき、その逆も同様です。たとえば、managed 設定が allowWrite を ["/opt/company-tools"] に設定し、ユーザーが ["~/.kube"] を追加する場合、両方のパスが最終構成に含まれます。2 つの配列設定はこのようにマージされません:fallbackModelは位置が意味を持つ順序付きチェーン:これを定義する最高優先度ファイルが全体の値を提供します。availableModels:最高優先度の managed ソースがこれを定義する場合、そのリストはそのまま適用され、ユーザー、プロジェクト、およびローカルエントリはそれを拡張できません。非 managed スコープ全体では、配列は通常どおりマージされます。マージ動作を参照してください。
アクティブな設定を確認
Claude Code 内で/status を実行して、どの設定ソースがアクティブであるかを確認します。メニュー内の Status タブには、Setting sources 行が含まれており、このセッション用に Claude Code が読み込んだ各レイヤーをリストします。User settings または Project local settings などのレイヤーが表示される場合、そのソースはそのセッション用に読み込まれています。managed 設定が有効な場合、エントリは配信チャネルを括弧内に表示します。たとえば、Enterprise managed settings (remote)、(plist)、(HKLM)、(HKCU)、または (file) などです。remote チャネルは claude.ai サーバー管理設定と Claude apps gateway配信ポリシーの両方をカバーしています。レイヤーは、そのソースが少なくとも 1 つのキーで読み込まれた場合にのみリストに表示されるため、空のリストは設定ソースが見つからなかったことを意味します。
Setting sources 行は、どのソースが読み込まれているかを確認します。各個別キーがどのレイヤーから供給されたかは表示されません。同じダイアログの Config タブは、テーマや詳細出力などの固定されたトグルセットのエディターであり、settings.json コンテンツのビューではありません。
設定ファイルに無効な JSON やバリデーションに失敗する値などのエラーが含まれている場合、/status は影響を受けたファイルをリストします。各エラーの詳細については /doctor を実行してください。
構成システムの重要なポイント
- メモリファイル(
CLAUDE.md):Claude が起動時に読み込む命令とコンテキストを含みます - 設定ファイル(JSON):権限、環境変数、およびツール動作を構成します
- Skills:
/skill-nameで呼び出すか、Claude によって自動的に読み込むことができるカスタムプロンプト - MCP サーバー:追加のツールと統合で Claude Code を拡張します
- 優先度:高レベルの構成(Managed)が低レベルの構成(User/Project)をオーバーライドします
- 継承:設定はマージされ、スカラー値はより高い優先度のスコープからオーバーライドされ、配列は連結されます。例外:
fallbackModelは位置が意味を持つ順序付きチェーン:これを定義する最高優先度ファイルが全体の値を提供します。v2.1.175 以降、availableModelsは managed またはポリシー値が低優先度エントリを完全に置き換えます
システムプロンプト
Claude Code の内部システムプロンプトは公開されていません。カスタム命令を追加するには、CLAUDE.md ファイルまたは --append-system-prompt フラグを使用します。
機密ファイルを除外
API キー、シークレット、環境ファイルなどの機密情報を含むファイルへの Claude Code アクセスを防ぐには、.claude/settings.json ファイルの permissions.deny 設定を使用します:
ignorePatterns 構成に置き換わります。これらのパターンに一致するファイルはファイル検出と検索結果から除外され、これらのファイルの読み取り操作は拒否されます。
Subagent 構成
Claude Code は、ユーザーレベルとプロジェクトレベルの両方で構成できるカスタム AI subagents をサポートしています。これらの subagents は YAML frontmatter を含む Markdown ファイルとして保存されます:- ユーザー subagents:
~/.claude/agents/- すべてのプロジェクト全体で利用可能 - プロジェクト subagents:
.claude/agents/- プロジェクト固有で、チームと共有できます
プラグイン構成
Claude Code は、skills、agents、hooks、および MCP サーバーで機能を拡張できるプラグインシステムをサポートしています。プラグインはマーケットプレイスを通じて配布され、ユーザーレベルとリポジトリレベルの両方で構成できます。プラグイン設定
settings.json のプラグイン関連設定:
enabledPlugins
どのプラグインが有効かを制御します。形式:"plugin-name@marketplace-name": true/false。任意のスコープにエントリがないプラグインは、その defaultEnabled 値にフォールバックします。
スコープ:
- ユーザー設定(
~/.claude/settings.json):個人的なプラグイン設定 - プロジェクト設定(
.claude/settings.json):チームと共有されるプロジェクト固有のプラグイン - ローカル設定(
.claude/settings.local.json):マシンごとのオーバーライド(Claude Code が作成する場合は gitignored) - Managed 設定(
managed-settings.json):すべてのスコープでのインストールをブロックし、マーケットプレイスからプラグインを非表示にする組織全体のポリシーオーバーライド
プロジェクト設定はユーザー設定よりも優先されるため、
~/.claude/settings.json でプラグインを false に設定しても、プロジェクトの .claude/settings.json が有効にするプラグインは無効になりません。プロジェクトで有効になっているプラグインをマシンでオプトアウトするには、代わりに .claude/settings.local.json で false に設定してください。Managed 設定で強制的に有効にされたプラグインは、Managed 設定がローカル設定をオーバーライドするため、この方法では無効にできません。外部ソース(GitHub リポジトリや npm パッケージなど)からのプラグインをプロジェクトの .claude/settings.json で有効にしても、他のユーザーにはインストールされません。Claude Code v2.1.195 以降、プラグインを読み込むすべてのパスは、実行前に各ユーザーに プラグインをインストールして信頼するよう求めます。pluginConfigs
プラグインの userConfig プロンプトが収集する機密性の低いオプション値を保存します。プラグイン ID でキー付けされます。Claude Code は、プラグインの構成ダイアログに入力すると、このキーをユーザー設定に書き込むため、手動で編集する必要はありません。機密オプションは、macOS Keychain に保存されるか、サポートされているキーチェーンがないプラットフォームでは ~/.claude/.credentials.json に保存されます。
この例は、acme-tools マーケットプレイスからインストールされたプラグインの 1 つのオプションを保存します:
pluginConfigs はユーザー設定、--settings フラグ、および managed 設定からのみ読み込まれます。プロジェクトの .claude/settings.json または .claude/settings.local.json 内のエントリは無視されます。これらの値はプラグイン hook、MCP、および LSP 構成に置き換えられるため、クローンされたリポジトリはそれらを提供できません。v2.1.207 より前は、プロジェクトおよびローカル設定も読み込まれていました。
extraKnownMarketplaces
リポジトリで利用可能にする必要がある追加のマーケットプレイスを定義します。通常、リポジトリレベルの設定で使用され、チームメンバーが必要なプラグインソースにアクセスできることを確認します。
リポジトリが extraKnownMarketplaces を含む場合:
- チームメンバーはフォルダを信頼するときにマーケットプレイスをインストールするよう求められます
- チームメンバーはそのマーケットプレイスからプラグインをインストールするよう求められます
- ユーザーは不要なマーケットプレイスまたはプラグインをスキップできます(ユーザー設定に保存)
- インストールは信頼境界を尊重し、明示的な同意が必要です
github:GitHub リポジトリ(repoを使用)git:任意の git URL(urlを使用)directory:ローカルファイルシステムパス(開発のみ、pathを使用)hostPattern:マーケットプレイスホストに一致する正規表現パターン(hostPatternを使用)settings:ホストされたリポジトリなしで settings.json に直接宣言されたインラインマーケットプレイス(nameとpluginsを使用)
git ソースタイプは、自己ホストされた GitLab や Bitbucket を含む任意の git ホスティングサービスで機能します。Claude Code は、そのマシンで git clone が使用するのと同じ認証でリポジトリをクローンします:構成された認証情報ヘルパーまたは SSH キー。GITHUB_TOKEN などのプロバイダートークンは、それを読み取る認証情報ヘルパーを通じてのみ有効になります。セットアップの詳細については、プライベートリポジトリを参照してください。
github および git ソースの場合、source オブジェクト内(repo または url と並行して)に "skipLfs": true を設定して、Claude Code がマーケットプレイスリポジトリをクローンまたは更新するときに Git LFS ダウンロードをスキップします。LFS ポインターファイルはポインターのままで、コンテンツをダウンロードしません。リポジトリにプラグインコンテンツに関連しない大規模な LFS オブジェクトが含まれている場合に使用します。Claude Code v2.1.153 以降が必要です。
各マーケットプレイスエントリは、オプションの autoUpdate ブール値も受け入れます。source と並行して "autoUpdate": true を設定して、Claude Code がそのマーケットプレイスをリフレッシュし、起動時にインストール済みプラグインを更新するようにします。省略した場合、公式 Anthropic マーケットプレイスはデフォルトで true に設定され、その他すべてのマーケットプレイスはデフォルトで false に設定されます。自動更新の構成を参照してください。
source: 'settings' を使用して、ホストされたマーケットプレイスリポジトリをセットアップせずに、小規模なプラグインセットをインラインで宣言します。ここにリストされているプラグインは、GitHub または npm などの外部ソースを参照する必要があります。各プラグインを enabledPlugins で個別に有効にする必要があります。
strictKnownMarketplaces
Managed 設定のみ:ユーザーが追加してプラグインをインストールできるプラグインマーケットプレイスを制御します。この設定は managed 設定でのみ構成でき、管理者にマーケットプレイスソースに対する厳密な制御を提供します。
Managed 設定ファイルの場所:
- macOS:
/Library/Application Support/ClaudeCode/managed-settings.json - Linux と WSL:
/etc/claude-code/managed-settings.json - Windows:
C:\Program Files\ClaudeCode\managed-settings.json
- managed 設定(
managed-settings.json)でのみ利用可能 - ユーザーまたはプロジェクト設定でオーバーライドできません(最高優先度)
- ネットワーク/ファイルシステム操作の前に強制されます(ブロックされたソースは実行されません)
hostPatternとpathPatternを除き、ソース仕様に対して完全一致を使用します。hostPatternとpathPatternは正規表現マッチングを使用します
undefined(デフォルト):制限なし - ユーザーは任意のマーケットプレイスを追加できます- 空配列
[]:完全ロックダウン - ユーザーは新しいマーケットプレイスを追加できません - ソースのリスト:ユーザーは正確に一致するマーケットプレイスのみを追加できます
hostPattern と pathPattern はそれぞれマーケットプレイスホストとファイルシステムパスに対して正規表現マッチングを使用します。
- GitHub リポジトリ:
repo(必須)、ref(オプション:ブランチまたはタグ)、path(オプション:サブディレクトリ)
- Git リポジトリ:
url(必須)、ref(オプション:ブランチまたはタグ)、path(オプション:サブディレクトリ)
- URL ベースのマーケットプレイス:
url(必須)、headers(オプション:認証アクセス用の HTTP ヘッダー)
URL ベースのマーケットプレイスは
marketplace.json ファイルのみをダウンロードします。サーバーからプラグインファイルをダウンロードしません。URL ベースのマーケットプレイス内のプラグインは、相対パスではなく外部ソース(GitHub、npm、または git URL)を使用する必要があります。相対パスを持つプラグインの場合は、代わりに Git ベースのマーケットプレイスを使用します。詳細については トラブルシューティングを参照してください。- NPM パッケージ:
package(必須、スコープ付きパッケージをサポート)
- ファイルパス:
path(必須:marketplace.json ファイルへの絶対パス)
- ディレクトリパス:
path(必須:.claude-plugin/marketplace.json を含むディレクトリへの絶対パス)
- ホストパターンマッチング:
hostPattern(必須:マーケットプレイスホストに対してマッチする正規表現パターン)
各リポジトリを列挙することなく、特定のホストからすべてのマーケットプレイスを許可する場合は、ホストパターンマッチングを使用します。これは、開発者が独自のマーケットプレイスを作成する内部 GitHub Enterprise または GitLab サーバーを持つ組織に役立ちます。
ソースタイプ別のホスト抽出:
github:常にgithub.comに対してマッチgit:URL からホスト名を抽出(HTTPS と SSH 形式の両方をサポート)url:URL からホスト名を抽出npm、file、directory:ホストパターンマッチングではサポートされていません
- パスパターンマッチング:
pathPattern(必須:file および directory ソースの path フィールドに対してマッチする正規表現パターン)
ネットワークソースの hostPattern 制限と並行して、ファイルシステムベースのマーケットプレイスを許可するには、パスパターンマッチングを使用します。すべてのローカルパスを許可するには ".*" を設定するか、特定のディレクトリに制限するにはより狭いパターンを設定します。
構成例:
例:特定のマーケットプレイスのみを許可:
github と git)の場合、これはすべてのオプションフィールドを含みます:
repoまたはurlは正確に一致する必要がありますrefフィールドは正確に一致する必要があります(または両方が未定義)pathフィールドは正確に一致する必要があります(または両方が未定義)
extraKnownMarketplaces との比較:
形式の違い:
strictKnownMarketplaces は直接ソースオブジェクトを使用します:
extraKnownMarketplaces は名前付きマーケットプレイスが必要です:
strictKnownMarketplaces はポリシーゲートです:ユーザーが追加できるものを制御しますが、マーケットプレイスを登録しません。マーケットプレイスを制限して事前登録するには、managed-settings.json で両方を設定します:
strictKnownMarketplaces のみが設定されている場合、ユーザーは /plugin marketplace add を通じて許可されたマーケットプレイスを手動で追加できますが、自動的には利用できません。
重要な注意:
- 制限はネットワークリクエストまたはファイルシステム操作の前にチェックされます
- ブロックされた場合、ユーザーはソースが managed ポリシーでブロックされていることを示す明確なエラーメッセージを表示します
- 制限はマーケットプレイスの追加およびプラグインのインストール、更新、リフレッシュ、および自動更新に対して強制されます。ポリシーが設定される前に追加されたマーケットプレイスは、そのソースがホワイトリストと一致しなくなると、プラグインのインストールまたは更新に使用できません
- Managed 設定は最高優先度を持ち、オーバーライドできません
strictPluginOnlyCustomization
Managed 設定のみ:skills、agents、hooks、および MCP サーバーをユーザーおよびプロジェクトソースからブロックするため、プラグインまたは managed 設定からのみ取得できます。strictKnownMarketplaces と組み合わせて、カスタマイズサプライチェーン全体を制御します:マーケットプレイスホワイトリストはユーザーがインストールできるプラグインを制御し、この設定はプラグインまたは managed 設定から来ていないすべてをブロックします。
値は、すべての 4 つのサーフェスをロックするための true、またはロックするサーフェスを名前付けする配列です:
Claude Code バージョンが認識しないサーフェス名は、設定ファイルが失敗するのではなく無視されるため、すべてのクライアントが更新される前に新しいサーフェス名を追加できます。
プラグインの管理
/plugin コマンドを使用してプラグインを対話的に管理します:
- マーケットプレイスから利用可能なプラグインを参照
- プラグインをインストール/アンインストール
- プラグインを有効/無効にする
- プラグインの詳細を表示(提供される skills、agents、hooks)
- マーケットプレイスを追加/削除
環境変数
環境変数を使用すると、設定ファイルを編集することなく Claude Code の動作を制御できます。任意の変数は、すべてのセッションに適用するか、チームにロールアウトするためにsettings.json の env キーで構成することもできます。
完全なリストについては、環境変数リファレンスを参照してください。
Claude が利用できるツール
Claude Code は、ファイルの読み取り、編集、検索、コマンド実行、および subagents のオーケストレーション用のツールセットにアクセスできます。ツール名は、権限ルールと hook マッチャーで使用する正確な文字列です。 完全なリストと Bash ツール動作の詳細については、ツールリファレンスを参照してください。関連項目
- 権限:権限システム、ルール構文、ツール固有パターン、および managed ポリシー
- 認証:Claude Code へのユーザーアクセスをセットアップ
- 設定をデバッグする:設定、hook、または MCP サーバーが有効にならない理由を診断
- インストールとログインのトラブルシューティング:インストール、認証、およびプラットフォームの問題