背景

この連載では、Claude Codeの公式ドキュメントを1ページずつ読み解いていきます。公式ドキュメントは情報が網羅されている分、「結局どの機能を、どんな場面で使えばいいのか」は自分で考える必要があり、読むのに意外と時間がかかります。そこで、私が実務で使うために読み込んだ内容を「使う場面→実例コード」の順に整理して残していくことにしました。専門家の解説というより、一次情報を読んだ記録です。推測や動作を確認していない部分には、その都度そう書きます。

公式ドキュメント：https://code.claude.com/docs/ja/settings-reference

1. 一言でいうと

Claude Code の settings.json に書けるキーを、1つ残らず並べた辞書です。キーごとに「どのファイルに書けるか（スコープ）」「型」「既定値」「1回だけ上書きする方法」「貼り付けて使える例」がそろっています。冒頭の索引には 245 個のキーが載っていて、17 のトピックに分かれています。

ただし、このページは「どのファイルを選ぶか」「複数のファイルがぶつかったらどれが勝つか」は扱いません。原文は、それは「設定ファイルと優先順位」のページから始めるように、と最初に書いています。このページは、書く場所が決まったあとに「何を書けるか」を引く辞書です。

この連載でも、これまで apiKeyHelper・policyHelper・modelPricing・extraKnownMarketplaces など、詳しくは設定のリファレンスへ、と後回しにしてきたキーがたくさんありました。今回はそれらの置き場所を地図にしながら、誰がそのキーを書けるのかという視点で読んでいきます。

---

2. どういう場面で役立つか

シーン1：やりたいことは決まっているが、キーの名前がわからない

「自動コンパクト化を止めたい」「API キーを毎回ボールトから取ってきたい」「セッションの記録を何日残すか決めたい」。やりたいことから引くと、autoCompactEnabled・apiKeyHelper・cleanupPeriodDays にたどり着きます。原文の索引には絞り込みの欄があり、キー名でも用途でも探せるようになっています。

シーン2：チームのリポジトリに設定を置く前に、効くかどうか確かめたい

.claude/settings.json に書いて共有したつもりでも、キーによってはリポジトリのファイルからは読まれません。どのキーがそうなのかは、各キーの「スコープ」の行でわかります。書いてから「効かない」と悩む前に引くページです。

シーン3：組織として、開発者のマシンに守らせたい決まりを作る

権限のバイパスを禁止する、サンドボックスが動かないなら起動させない、使ってよい API の提供元を絞る。こうした「組織の管理設定でだけ書けるキー」が 44 個あり、このページで1つずつ仕様を確かめられます。

不要・向かないケース

• 設定ファイルの選び方や優先順位を知りたい：原文はこれを別ページ（設定ファイルと優先順位）に回しています。
• 環境変数の一覧が欲しい：env キーで任意の環境変数を設定できますが、変数そのものの一覧は「環境変数」のページの担当です。
• 初めて設定ファイルを書く：245 個のキーを頭から読む必要はありません。原文の関連項目にある「設定ファイルの例」のページで、個人用・チーム用・組織用のファイルの例を見るほうが早いはずです（筆者の指摘）。

---

3. コードと仕組みの解説

原文は 7,000 行を超え、fenced コードブロックは 255 本あります。ほとんどが各キーの「貼り付け可能な例」で、数行の JSON です。この連載の大きなリファレンスの扱いに従い、12 本を引用し、残りは表と文章に圧縮します。引用したのは、(1) リポジトリと個人と組織の「誰が書けるか」の違いが表に出るキー、(2) 安全に直結し、原文が「これだけでは防げない」と注意を書いているキー、(3) これまでの回で後回しにしてきたキーです。

3-0. バージョン要件（この記事で触れるもの）

原文には 2.1 系のバージョンが 100 か所近く出てきます。この記事で触れるキーに関わるものだけを表にします。

バージョン	内容
v2.1.193 以降	disableSideloadFlags（起動時のプラグイン・MCP などを読み込むフラグを拒否）
v2.1.223 より前	バイパスを無効にしても、エージェント定義のフロントマターの権限モードが適用されていた
v2.1.246 以降	apiKeyHelper の出力が期限切れの JWT なら、送信前に再実行する
v2.1.251 以降	modelSettings（モデルごとの努力レベルの保存）
v2.1.257 以降	permissions.blockReadsOutsideWorkingDirectories。また、これより前は bypassPermissions がどのファイルからでも有効になっていた
v2.1.271 以降	modelPricing の multiplier で 1 を超える値（上乗せ）が効く
v2.1.282 以降	プロジェクト・ローカル設定の env に書いたテレメトリ関連の変数を無視する
v2.1.285 以降	allowedProviders

3-1. ページの地図

スコープ：誰がそのキーを書けるか

原文の索引には「Scope」の列があり、キーを書けるファイルが示されています。ファイルの対応は次のとおりです。

名前	ファイル
User	~/.claude/settings.json
Project	.claude/settings.json
Local	.claude/settings.local.json
Managed	組織がデプロイするもの
Global config	~/.claude.json（設定ファイルではなく、こちらに書くキー）

索引の 245 キーをスコープ別に数えると、次のようになります（筆者が索引の表から数えたもの）。

スコープ	キー数	意味
Any file	157	どの設定ファイルにも書ける
Managed	44	組織の管理設定だけ
User or managed	27	個人の設定か管理設定だけ（リポジトリからは書けない）
Global config	12	~/.claude.json にだけ書く
User, local, or managed	4	個人・ローカル・管理設定（プロジェクトの共有ファイルからは書けない）
User	1	worktree.location だけ

ただし、「Any file」と書かれていても、注記で「プロジェクト設定とローカル設定には制限あり」と添えられているキーがあります。後で見る permissions.defaultMode や sandbox.enabled がその例です。索引の列だけで判断せず、各キーの「スコープ」の行の注記まで読むのが確実です（筆者の指摘）。

「User or managed」の 27 キーには、skipAutoPermissionPrompt、sandbox.credentials.allowPlaintextInject、sandbox.network.strictAllowlist、processWrapper、autoContinueAtUsageLimit などが入っています。リポジトリを開いただけで、通知を消したり、サンドボックスの穴を広げたりできないようにする区分だと読めます（筆者の解釈）。

トピック：17 の節

節	キー数	主な中身
インターフェースとターミナル	39	表示、テーマ、ステータスライン、音声、vim など
サンドボックス設定	38	sandbox の下のファイルシステム・ネットワーク・認証情報
モデルと応答	23	model、availableModels、effortLevel、modelPricing、modelSettings など
プラグインとスキル	22	enabledPlugins、extraKnownMarketplaces、strictKnownMarketplaces など
権限設定	15	permissions の allow／ask／deny、既定のモード、auto モード
メモリとコンテキスト	14	autoCompactEnabled、env、claudeMd など
リモート、デスクトップ、通知	13	Remote Control、プッシュ通知、Artifact など
エージェント、セッション、worktree	12	agent、worktree、crossSessionInbound など
グローバル設定	12	~/.claude.json に書くキー
MCP	10	許可・拒否する MCP サーバー、組織が配る MCP サーバー
認証とプロバイダー	10	apiKeyHelper、allowedProviders、ログイン方法の強制
フックと自動化	9	hooks、disableAllHooks、ワークフロー
エンタープライズと管理設定	9	policyHelper、管理ソースの組み合わせ方
Git と帰属表示	7	コミット・PR の帰属表示
プライバシーとテレメトリ	5	cleanupPeriodDays など
更新とバージョン管理	4	更新チャネル、必須の最小・最大バージョン
ツール	3	ブラウザの外部ページ操作の制限など

キー数は索引の「Topic」列から数えたものです。

各キーの項目は、ほぼ同じ形をしています。説明の文、スコープ、タイプ（ブール値なら true と false それぞれの意味まで書かれる）、デフォルト、あればセッションごとの上書き（コマンドラインのフラグや環境変数）、そして JSON の例です。例のコードブロックには settings.json・managed-settings.json・~/.claude.json のように、置くファイルの名前が付いています。

3-2. 権限：リポジトリに勝手にバイパスさせない

権限設定の節は、ルールを並べる3つの配列（allow／ask／deny）と、セッションの開始モードなどからなります。まず既定のモードです。

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

permissions.defaultMode の値は "default"・"acceptEdits"・"plan"・"auto"・"dontAsk"・"bypassPermissions"・"manual"（"default" の別名）です。スコープは「Any file」ですが、原文は注記で auto と bypassPermissions はプロジェクトやローカル設定からは有効にならないと書いています。これらは ~/.claude/settings.json に書きます。3-0 の表のとおり、v2.1.257 より前は bypassPermissions がどのファイルからでも有効でした。クローンしてきたリポジトリが、確認なしで何でも実行するモードを仕込めた、ということです（筆者の解釈）。

逆に、誰にもバイパスさせない設定もあります。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

これを設定すると、--dangerously-skip-permissions フラグは拒否され、サブエージェントの定義にある permissionMode: bypassPermissions も無視されて、サブエージェントは親セッションのモードで動きます。原文は「通常、組織のポリシーを強制するために管理設定で設定します」と書いています。

deny ルールが止めるもの、止めないもの

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Bash(curl *)"
    ]
  }
}

この例は、.env や secrets ディレクトリ、認証情報ファイルの読み取りを拒否し、curl を止めるものです。ただ、原文はすぐ後に、この形で止まらないものを書いています。

• Bash(curl *) は Claude が書いたコマンドの文字列に一致するルールなので、/usr/bin/curl や、sh -c で包んだ curl は止まりません。
• Read の deny ルールは、Claude 自身のファイルツールと、Claude Code が Bash の中で認識できるファイルコマンド（cat・head・tail・sed・tee など）やリダイレクトの対象には効きます。しかし、grep -r pattern . のようにファイル名を書かずに読むコマンドや、任意のサブプロセスには効きません。OS のレベルで強制したいなら、サンドボックスを有効にするよう原文は勧めています。

ルールの評価順は deny → ask → allow で、ルールの具体性に関係なく、最初に一致したものが結果を決める、とも書かれています。第80回で Agent SDK 側の6段階の評価順序を見ましたが、そのうち deny → ask → allow の部分が設定ファイルのルールに当たります（筆者の対応づけ）。

作業ディレクトリの外を読ませない

permissions.blockReadsOutsideWorkingDirectories を true にすると、bypassPermissions を含むすべてのモードで、Claude のファイルツール（Read・Grep・Glob・LSP）が作業ディレクトリの外を読めなくなります。このキーはスコープの扱いが独特で、どれか1つのファイルに true があればブロックがかかります。リポジトリは自分にブロックをかけられますが、ユーザーがかけたブロックを外すことはできません。外すには、設定しているすべてのファイルからキーを消して、新しいセッションを始める必要があります。

3-3. サンドボックス：動かないときに黙って素通りしない

サンドボックスは 38 キーあり、このページで2番目に大きい節です。全体像は、原文が最初に置いている例でつかめます。

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "excludedCommands": ["docker *"],
    "filesystem": {
      "allowWrite": ["/tmp/build", "~/.kube"],
      "denyRead": ["~/.aws/credentials"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

サンドボックスをオンにし、サンドボックス内のコマンドは確認を省き、docker だけはサンドボックスの外で実行し、書き込み先を2つ追加し、AWS の認証情報ファイルを見えなくし、GitHub と npm への通信を許可する、という例です。サンドボックスは macOS、Linux、WSL2 で動きます。

組み合わせのルールも書かれています。管理設定が enabled のようなブール値のキーを設定すると、その値は開発者の設定をすべて上書きします。一方、配列のキーはスコープをまたいでマージされるので、開発者はエントリを追加できます。

注意したいのは、サンドボックスが起動できなかったときの既定の振る舞いです。Linux と WSL2 では bubblewrap と socat が必要で、起動できない場合、Claude Code はコマンドをサンドボックスなしで実行します。これを止めるのが次の設定です。

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true
  }
}

failIfUnavailable を true にすると、サンドボックスが起動できないときは起動時にエラーで終了します。原文は、サンドボックスをセキュリティの関門として必須にする管理対象のデプロイ向けだと書いています。第105回では、Python の Agent SDK でもサンドボックスが起動できないと既定ではサンドボックスなしで動く、という話がありました。本体側も既定は同じ「素通り」の方向だということになります（筆者の対応づけ）。

認証情報は、書いたものしか守られない

{
  "sandbox": {
    "credentials": {
      "files": [{ "path": "~/.aws/credentials", "mode": "deny" }],
      "envVars": [{ "name": "GITHUB_TOKEN", "mode": "deny" }]
    }
  }
}

sandbox.credentials は、サンドボックス内のコマンドから認証情報を守る設定です。mode が deny なら隠し、mask ならプレースホルダーを見せて、送信するリクエストの中でサンドボックスのプロキシが本物の値に差し替えます。原文ははっきりと、Claude Code はリストしたエントリのみを保護します。組み込みの認証情報拒否リストはありません、と書いています。既定は「未設定。認証情報は保護されません」です。

スコープにも注意が要ります。mask のエントリ、allowPlaintextInject、awsPairs、sigv4 は、ユーザー設定、管理設定、--settings フラグからしか尊重されません。また、deny のファイル保護はファイルシステムの分離の一部なので、ファイルシステムの分離を無効にすると効かなくなります（環境変数の保護は残ります）。

3-4. env：リポジトリが書いても無視される変数

{
  "env": {
    "DISABLE_AUTO_COMPACT": "1",
    "ANTHROPIC_BASE_URL": "https://proxy.example.com"
  }
}

env は、すべてのセッションと、そこから起動するサブプロセスの環境変数を設定するキーです。この例は自動コンパクト化を止め、API リクエストをプロキシ経由にしています。振る舞いの要点は次のとおりです。

• ここの値は、シェルでエクスポートした同じ変数を上書きします。
• シェルでエクスポートした値を打ち消したいときは、"" を設定します。
• Claude Desktop アプリや自己ホスト環境のランナーがセッションを始める場合は、それらが作る起動環境がすでに設定している変数については、起動環境のほうが優先されます。
• NO_COLOR と FORCE_COLOR は、ここで設定してもサブプロセスにしか届きません。

そして、プロジェクトとローカルの設定からは設定できない変数があります。原文の分類を要約すると次のとおりです。

分類	例（原文から）
Claude Code が自分のファイルを保存する場所を決める変数	CLAUDE_CONFIG_DIR、CLAUDE_CODE_TMPDIR、HOME、TMPDIR など
Windows のプログラムやマシン全体の設定を決める変数	SystemRoot、ComSpec、PATHEXT など
セッションの内容を外へ出す変数	OTEL_LOG_RAW_API_BODIES など
テレメトリをオンにする・送り先を決める・何を記録するかを決める変数	CLAUDE_CODE_ENABLE_TELEMETRY、OTEL_LOG_USER_PROMPTS、OTEL_EXPORTER_OTLP_ENDPOINT など
起動や同期の方法を変える変数	CLAUDE_CODE_PROCESS_WRAPPER、CLAUDE_CODE_SYNC_SKILLS など
応答のないダイアログのタイマー、添付やメンションの無効化	CLAUDE_CODE_USER_DIALOG_TIMEOUT_MS、CLAUDE_CODE_DISABLE_ATTACHMENTS など

テレメトリの変数は、オフにする値だけはプロジェクトやローカルの設定からも効きます。つまり、リポジトリは「プロンプトを外部のコレクターに送る」設定は入れられないが、「送らない」設定なら入れられる、という非対称な作りです（筆者の解釈）。無視されたものは /status や claude doctor で名前を確認できます（値は表示されません）。ただし -p の非対話実行や Agent SDK のセッションでは通知が出ないので、原文はアップグレード後にコレクターがデータを受け取り続けているか確かめるよう書いています。

3-5. 認証：キーを生成するコマンドと、使ってよい提供元

{
  "apiKeyHelper": "/bin/generate_temp_api_key.sh"
}

apiKeyHelper は、モデルへのリクエストで送る認証情報を自分のコマンドで作るキーです。macOS と Linux では /bin/sh、Windows では cmd を通して実行され、出力は X-Api-Key ヘッダーと Authorization: Bearer ヘッダーの両方として送られます。コマンドを再実行するのは、キャッシュの期限が切れたとき（既定は5分）、リクエストが 401 か 403 で失敗したとき、キャッシュした出力が期限切れの JWT だったとき、です。安全面では、対話セッションの場合、プロジェクトやローカルの設定から来たコマンドは、ワークスペースの信頼のプロンプトを受け入れるまで実行されない、という点が書かれています。リポジトリに書かれたシェルコマンドが、開いただけで走ることはないということです。

{
  "allowedProviders": ["anthropic", "bedrock"]
}

allowedProviders は管理設定専用のキーで、そのマシンが Claude に到達するのに使ってよいサービスを列挙します。値は "anthropic"・"bedrock"・"vertex"・"foundry"・"anthropicAws"・"mantle"・"customEndpoint"・"gateway" の8種類です。リストにない提供元は、起動時、ログイン時、次に API に接続するときに拒否されます。原文はこの拒否メッセージについてエラーリファレンス（第107回）の項目へリンクしています。

落とし穴として、認識できない名前のエントリは取り除かれて報告され、残りで強制されますが、空のリストや、全部が認識できない名前のリストだと、すべての提供元が拒否され、Claude Code はそのマシンで起動しません。また "customEndpoint" は、管理設定の env ブロックで固定（ピン）した値と完全に一致するエンドポイントしか許されません。

3-6. 組織の管理設定：ヘルパーと、複数ソースの組み合わせ方

エンタープライズの節には、管理設定そのものの「作り方」と「組み合わせ方」を決めるキーが集まっています。

{
  "policyHelper": {
    "path": "/usr/local/bin/claude-policy",
    "timeoutMs": 5000,
    "refreshIntervalMs": 300000
  }
}

policyHelper は、起動時に管理設定を計算するための実行ファイルを指定します。デバイスの状態や ID、リモートのサービスから、静的なファイルの代わりにポリシーを導き出せます。この例は、タイムアウト5秒で実行し、5分ごとに再実行するものです。ヘルパーは引数なしで実行され、環境変数 CLAUDE_CODE_VERSION を受け取り、標準出力に JSON を書きます（上限 1 MiB）。

ここに大きな落とし穴があります。設定は managedSettings キーの下に入れなければならず、managedSettings キーのない裸の設定オブジェクトを出力すると、何も適用されず、エラーも報告されません。逆に、ヘルパーの実行が失敗した場合（0 以外で終了、タイムアウト、出力が 1 MiB 以上、JSON として不正など）は、Claude Code は理由を表示して起動を拒否します。拒否は対話セッション、claude -p、Agent SDK のセッション、バックグラウンドセッションなどに及びます。

複数の管理ソース（サーバー管理設定、MDM ポリシー、管理設定ファイルなど）をどう組み合わせるかは managedSourcesBehavior が決めます。既定の "first-wins" では、ポリシーキーを含む最も優先度の高いソースだけを使い、残りを無視します。"merge" にすると、キーの種類ごとに次のルールで組み合わせます（原文の表を要約）。

キーの種類	組み合わせ方	例
リスト	全ソースのエントリを合わせる	permissions.allow
ロック	ソースが設定するいちばん厳しい値を使う	permissions.disableBypassPermissionsMode
制限の許可リスト	最優先のソースの値をまるごと使い、下位から足さない	availableModels、allowedProviders、strictKnownMarketplaces
最優先のソースからのみ	最優先のソースが設定していなければ、下位の値も無視	apiKeyHelper
env	どちらのモードでも変数ごとにマージ	env
その他	設定している最優先のソースの値	cleanupPeriodDays、model

許可リストを「足し算」にしないのは、下位のソースが許可を広げられないようにするため、と読めます（筆者の解釈）。原文は、"merge" は最優先のソースより下のすべてのソースが管理者の管理下にある場合にだけ設定するように、と書いています。

Agent SDK や IDE 拡張機能のような埋め込み元のホストが渡す管理設定をどう扱うかは、別の parentSettingsBehavior が決めます。既定の "first-wins" では、管理者が配った管理層があればホストの設定は捨てられ、"merge" では制限だけを通すフィルターをかけて管理層の下に適用されます。どちらの場合も、実際に組み合わさったソースは /status の Setting sources 行で確認できます。

3-7. プラグイン：プロジェクトの「有効」は個人の「無効」に勝つ

{
  "enabledPlugins": {
    "code-formatter@team-tools": true,
    "deployment-tools@team-tools": true,
    "experimental-features@personal": false
  }
}

enabledPlugins は、plugin-name@marketplace-name をキーにしてプラグインをオン・オフします。/plugin や claude plugin enable を使うと、Claude Code がこのキーを書き込みます。原文が注意しているのは優先順位で、プロジェクト設定はユーザー設定より優先されるため、~/.claude/settings.json で false にしても、プロジェクトの .claude/settings.json が有効にしたプラグインは無効になりません。自分のマシンだけで外したいときは .claude/settings.local.json に false を書きます。管理設定で false にしたプラグインは、すべてのスコープでインストールがブロックされ、マーケットプレイスからも見えなくなります。

組織がマーケットプレイスの出どころそのものを絞るのが次のキーです。

{
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "acme-corp/approved-plugins" },
    { "source": "github", "repo": "acme-corp/security-tools", "ref": "v2.0" },
    { "source": "url", "url": "https://plugins.example.com/marketplace.json" }
  ]
}

strictKnownMarketplaces は管理設定専用で、ユーザーがプラグインを追加・インストールできるマーケットプレイスの出どころを許可リストで制限します。この例は GitHub のリポジトリ2つ（片方は v2.0 の ref に固定）と、ホストされた marketplace.json の URL を許可しています。未設定ならどのマーケットプレイスでも追加できますが、空の配列は公式の Anthropic マーケットプレイスも含めてすべてを止める完全なロックダウンになります。また、このキーは「何を追加してよいか」を決めるだけで、何も登録しません。登録は extraKnownMarketplaces の担当です。extraKnownMarketplaces をリポジトリの設定に書いた場合、そのフォルダーのワークスペース信頼ダイアログを受け入れるまでは受け付けられず、-p の実行を含む信頼していないフォルダーでは、メッセージなしで無視されます。

3-8. 引用しなかったキーの拾い読み

残りのキーから、これまでの回で後回しにしてきたものと、知っておくと事故を防げるものを表にします。

キー	スコープ	要点
autoCompactEnabled	Any file	既定は true。DISABLE_AUTO_COMPACT と、どちらか一方でもオフにすれば他方ではオンに戻せない。手動の /compact は使える
modelPricing	Managed	契約レートで費用を報告する。/usage、ステータスライン、Agent SDK の total_cost_usd、--max-budget-usd の上限などに適用される
modelSettings	Any file	モデルごとの努力レベルの保存先。/effort やモデルピッカーで保存すると書き込まれるので、手で編集することはめったにない
cleanupPeriodDays	Any file	既定 30 日、最小 1。削除はメッセージなしで行われる。0 は検証エラーになるので、長く残すなら 3650 のような大きな値にする
allowManagedPermissionRulesOnly	Managed	管理設定を権限ルールの唯一の出どころにする。ユーザー・プロジェクト・ローカルのルールや --allowedTools を無視する
disableSideloadFlags	Managed	--plugin-dir・--plugin-url・--agents・--mcp-config を起動時に拒否する。strictKnownMarketplaces を1回の実行で回避されるのを防ぐ
skipDangerousModePermissionPrompt	User, local, or managed	バイパスモードに入る前の確認ダイアログを省く。一度受け入れると Claude Code がユーザー設定に true を書く。信頼していないリポジトリからは省かせられない

最後に、グローバル設定の 12 キーは ~/.claude.json に書きます。原文は「設定ファイルには保存しないでください。Claude Code はそれ以外の場所ではこれらを無視します」と書いています。autoConnectIde などがここに入ります。/config から切り替えるとほとんど自動で書き込まれますが、手で settings.json に書いても効かない、という点だけは覚えておくと迷いません。

廃止予定のキーも索引に残っています。includeCoAuthoredBy（attribution に置き換え）、disableArtifact（enableArtifact に置き換え）、keybindingFlavor（効果なし）などです。古い設定ファイルを見直すときの手がかりになります。

---

4. まとめ

• このページは settings.json に書ける 245 キーの辞書。17 のトピックに分かれ、各キーにスコープ・型・既定値・上書き方法・例がそろう。どのファイルを選ぶか、どれが勝つかは別ページの担当。
• いちばん大事なのは スコープ。Any file が 157、管理設定だけが 44、個人か管理設定だけが 27。「Any file」でも注記で制限がつくキーがあるので、各キーのスコープの行まで読む。
• リポジトリからは、auto／bypassPermissions の開始モード、テレメトリをオンにする env、mask の認証情報設定などを有効にできない。apiKeyHelper や extraKnownMarketplaces もワークスペースの信頼が先。
• deny ルールは書いたコマンドの文字列に一致するもので、/usr/bin/curl やファイル名を書かずに読むコマンドは止まらない。サンドボックスは起動できないと既定で素通り、認証情報は書いたものしか守られない。
• 組織向けには、allowedProviders（空リストだと起動しない）、policyHelper（managedSettings がないと黙って何も適用されない）、managedSourcesBehavior（許可リストは足し算にならない）といった、書き方を間違えると気づきにくいキーが並ぶ。

次回予告

次回は 「設定ファイルと優先順位」（settings） を取り上げる予定です。

今回の辞書は「何を書けるか」のページでした。そのため、ユーザー・プロジェクト・ローカル・管理設定のどのファイルを選ぶのか、同じキーが複数のファイルにあったらどれが勝つのかは、原文自身が「設定ファイルと優先順位」のページに回していました。プロジェクトの「有効」が個人の「無効」に勝つプラグインの例のように、優先順位を知らないと、正しく書いたはずの設定が効かない理由がわかりません。次回は、設定ファイルの置き場所と、それらがどう重なって最終的な設定になるのかを見ていきます。

---