wslInheritsWindowsSettingsの仕組みと設定方法
WSL上のClaude CodeはデフォルトでWindows側の管理設定を読みません。wslInheritsWindowsSettingsで継承させる条件と、/statusでの確認手順をまとめます。
このTipsでできること
wslInheritsWindowsSettingsは、WSL上で動くClaude CodeにWindows側の管理設定(HKLMレジストリまたはC:\Program Files\ClaudeCodeのファイル)を継承させるためのキーです。何も設定しなければ、WSL上のClaude CodeはWindowsに配った管理ポリシーを一切参照しません。これは組織のWindows端末を統制していても、WSL上のセッションだけ許可外のモデルやツールが素通りするという盲点を生みます。
対象になるのは、WSLターミナルから直接起動したClaude CodeのCLIセッションと、Claude Code DesktopがWSL 2ディストリビューション内で開くCodeセッションの両方です。どちらの起動経路でも、Claude Codeプロセス自体はディストリビューションの中で動くため、管理設定の解決はこの記事で扱うWSL側の発見パスを通ります。
デフォルトの挙動 — WSLはLinux側のパスしか見ない
Claude Codeは管理設定を4つの配信経路から優先度順に探し、中身のある設定を見つけた最初の1つだけを採用します(マージはしません)。
| 経路 | 配信元 | 優先度 | 対応OS |
|---|---|---|---|
| サーバー管理 | 配信元claude.ai管理コンソール、または自前のgateway | 優先度最高 | 対応OS全OS |
| plist / レジストリポリシー | 配信元macOS plist / Windows HKLM\SOFTWARE\Policies\ClaudeCode | 優先度高 | 対応OSmacOS・Windows |
| ファイルベース | 配信元managed-settings.json(OSごとの固定パス) | 優先度中 | 対応OS全OS |
| Windowsユーザーレジストリ | 配信元HKCU\SOFTWARE\Policies\ClaudeCode | 優先度最低 | 対応OSWindowsのみ |
WSL上のファイルベース経路は/etc/claude-code/managed-settings.json固定です。同じマシンのWindows側にHKLMレジストリポリシーやC:\Program Files\ClaudeCode\managed-settings.jsonを配っていても、WSLディストリビューション内のClaude CodeはデフォルトではWindows側の設定源に一切アクセスしません。WSLとWindowsは別々のファイルシステム・別々のレジストリ空間として扱われるため、これは不具合ではなく設計上の初期状態です。
組織のWindows端末をmanaged settingsで統制していても、開発者がWSL上でClaude Codeを動かした瞬間にその統制が丸ごと外れる、という盲点はここから生まれます。権限ルールやサンドボックス強制のようにネイティブWindows側では効いている制御が、WSLでは初期状態では一切適用されません。フリートにWSLを使う開発者が混ざる組織ほど、この既定挙動を早い段階で把握しておく価値があります。
wslInheritsWindowsSettingsで継承させる
WindowsのHKLMレジストリキーか、C:\Program Files\ClaudeCode\managed-settings.jsonのどちらかにwslInheritsWindowsSettings: trueを明示的に配ると、同じマシン上のWSLディストリビューションが起動時にそのWindows側の管理設定も読みに行くようになります。両方のソースに値がある場合はWindows側が優先されます。
{
"wslInheritsWindowsSettings": true
}このキーには3つの制約があります。
- 有効なソースが限定される: HKLMレジストリキーか、
C:\Program Files\ClaudeCode\managed-settings.jsonのいずれかに書いた場合のみ有効です。どちらもWindows管理者権限がないと書き込めません - HKCUには別途設定が必要:
HKCU\SOFTWARE\Policies\ClaudeCode(ユーザーレジストリ、管理者権限なしで書き込み可能)の内容もWSLに及ぼしたい場合、フラグをHKCU側にも重ねて設定する必要があります - ネイティブWindowsには無効: このフラグ自体はWSL経由の読み込みを制御するためのものなので、Windows上で直接動くClaude Codeの挙動には影響しません
/statusで継承が効いているか確認する
設定を配ったら、WSLセッション内で/statusを実行して確認します。Setting sourcesの行にEnterprise managed settingsと、継承元が(HKLM)か(file)のどちらかで表示されていれば、Windows側のポリシーが正しく届いています。
/statusこの行が出ない、または期待した継承元と違う表示なら、フラグを配ったレジストリキーやファイルパスを取り違えている可能性が高いです。特にHKCUとHKLMを混同しているケースが多く、HKCUだけにwslInheritsWindowsSettings: trueを書いてもHKLM側やファイルベース側の管理設定はWSLに継承されません。設定変更のたびにWSLセッションを開き直して/statusを確認する運用にしておくと、配布ミスをその場で検知できます。
サーバー管理設定だけでは配れない
wslInheritsWindowsSettingsは、claude.ai管理コンソールから配るサーバー管理設定(表の最優先経路)では配布できません。policyHelperと並んで、OSレベルのポリシーソースに限定されたキーだからです。管理コンソールだけで組織のClaude Codeを統制している場合でも、このキーに関してはHKLMレジストリかファイルベースのmanaged-settings.jsonをWindows端末に個別配布する作業が別途必要になります。MDMを使っている組織は、そのMDM経由でHKLMレジストリキーかファイルパスへ配るのが現実的な選択です。
この制約に気づかず「管理コンソールで全部設定したのにWSLだけ許可外のモデルが使える」という問い合わせに発展するケースがあります。管理コンソール側の設定を確認する前に、まずこのキーがファイルベースかレジストリ経由で配られているかを確認すると切り分けが早くなります。
Desktop内のWSLセッションでも別途有効化が要る
Claude Code DesktopのCodeタブからWSL 2ディストリビューション内でセッションを開く機能もあります。この場合もセッションのプロセスはディストリビューション内で動くため、上記と同じWSL側の発見パスで管理設定を解決します。Windows専用のソースはwslInheritsWindowsSettings: trueが配られていない限り届きません。
さらに、管理設定が存在するデバイスでは、Desktop WSLセッションはデフォルトで無効化されています。セッション開始時に「デバイスが管理下にある」旨のメッセージで失敗する場合、これは不具合ではなく管理者側の設定によるものです。組織として有効化したい場合はAnthropicアカウントチームへの連絡が必要で、有効化後は次の2点を実施します。
- HKLMレジストリか
C:\Program Files\ClaudeCodeのファイルを通じてwslInheritsWindowsSettings: trueを配布し、WSLセッションがホストセッションと同じポリシーを継承するようにする - WSLセッション内で
/statusを実行し、Setting sourcesが(HKLM)または(file)付きのEnterprise managed settingsを示すことを確認する
エンドポイント監視での見落としどころ
WSL 2のユーティリティVM内で動くプロセスは、Windows側のエンドポイント検知センサーからは見えません。CrowdStrike Falconを使っている場合は、WSL用のFalconセンサーをLinux向けに有効化し、WSL仮想マシンのプロセスとVMディスクイメージという2つの除外設定をCrowdStrikeのWSL関連ドキュメントの指示どおりに追加しないと、ディストリビューション内のプロセス・ファイル活動が観測対象から漏れます。一方、Claude CodeのOpenTelemetryによるツール実行テレメトリは、WSLでもネイティブセッションでも同一の形式で出力されるため、テレメトリ収集基盤側の対応は不要です。
よくあるつまずき
wslInheritsWindowsSettingsを設定したのにWSL側でモデル制限やサンドボックス強制が反映されない場合、まず配布先を疑います。ユーザーレジストリのHKCUに書いても、HKLMやファイルベース側にフラグ自体がなければWSLは継承しません。逆にHKLM側にフラグを立てても、HKCU固有のポリシーだけをWSLへ及ぼしたいならHKCU側にもフラグの重ね書きが要ります。
もう1つの典型的な誤解は、このフラグをネイティブWindows上のClaude Codeにも効くと思い込むことです。ネイティブWindowsは元々Windows側の管理設定を直接読むため、このフラグの対象外であり、設定しても何も変わりません。
よくある質問
wslInheritsWindowsSettingsはどこに書けば効きますか
HKLMレジストリキー(HKLM\SOFTWARE\Policies\ClaudeCode)か、C:\Program Files\ClaudeCode\managed-settings.jsonのどちらかです。どちらもWindows管理者権限が必要な配布経路です。WSL側の/etc/claude-code/managed-settings.jsonやユーザーの~/.claude/settings.jsonに書いても効果はありません。
WSLディストリビューションが複数ある場合、それぞれ個別に設定が必要ですか
いいえ。wslInheritsWindowsSettingsはWindows側のレジストリまたはファイルに1回設定すれば、同じマシン上の全WSL 2ディストリビューションに対して有効になります。ディストリビューションごとの個別設定は不要です。
policyHelperという別の管理者向けキーとは関係がありますか
policyHelperは実行ファイルを起動して管理設定そのものを動的に計算する仕組みで、wslInheritsWindowsSettingsとは役割が異なります。共通点は、どちらもサーバー管理設定(管理コンソール配信)では配れず、OSレベルの経路に限定される点だけです。ただし配布先は同じではありません。policyHelperはMDMかファイルベースのmanaged-settings.jsonからのみ有効で、wslInheritsWindowsSettingsはそれに加えてHKLMレジストリからも配れます。両方を併用する組織は、この配布先の違いを混同しないよう注意します。
通常のWSLセットアップ手順とはどう違いますか
Claude Code WSL2セットアップは、個人の開発環境としてWSL2上でClaude Codeを動かすための初回セットアップ(バージョン確認・パス・sandbox有効化)を扱っています。本記事が扱うのは、組織が管理するWindows端末上でWSLセッションにもポリシーを及ぼすための管理者向けの設定です。Windows上でネイティブとWSLのどちらを選ぶかという判断自体はClaude Code Windowsインストールが扱っています。
まとめ
WSL上のClaude Codeは、wslInheritsWindowsSettings: trueをHKLMレジストリかC:\Program Files\ClaudeCodeのファイルに明示的に配らない限り、同じマシンのWindows側管理設定を一切読みません。HKCU固有のポリシーも継承させたい場合はHKCU側にも同じフラグが必要で、Desktop内のWSLセッションを有効化する場合は別途Anthropicアカウントチームへの連絡と同じフラグの配布が要ります。配布後は/statusのSetting sources行で継承元が(HKLM)か(file)付きのEnterprise managed settingsになっているかを確認するのが、設定漏れに気づく最短の方法です。管理設定の全体像はClaude Code組織管理ガイドを参照してください。