disableWslSessionsでClaude Code DesktopのWSLを組織展開する

disableWslSessionsで何ができるか

disableWslSessionsは、Claude Code DesktopのWSLセッションを組織全体で許可するかどうかを切り替えるWindowsレジストリポリシーです。管理端末ではWSLセッションが既定で無効になっており、このキーをHKLMに配らない限りセッション開始が失敗します。値をfalseまたは0にすると、管理下の端末でもWSLセッションが開けるようになります。

配布にはClaude Desktop v1.19367.0以降が必須です。古いバージョンの端末ではこのキーを配布しても効果がなく、Desktopアプリ自体の更新が前提条件になります。Windows端末でのバージョン確認は、DesktopアプリのHelp > Aboutから行います。表示された番号をクリックするとクリップボードにコピーされるので、社内の配布記録やチケットにそのまま貼り付けられます。

なぜDesktop WSLセッションは既定オフになるのか

Claude Desktopは、C:\Program Files\ClaudeCode\managed-settings.jsonのような管理設定ファイルの存在を手がかりに、その端末を組織管理下と判定します。組織管理下と判定した端末では、WSLセッションを既定で無効にします。

これは不具合ではありません。安全側の初期値です。管理者がWSL側への統制を確認する前に、Windows側の管理設定が届かない実行環境が勝手に開いてしまうのを防ぐ設計です。セッション開始時に「デバイスが管理されている」旨のメッセージが出て失敗するなら、この既定挙動が働いている証拠です。

disableWslSessionsを配布する手順

有効化はWindowsレジストリへの1エントリで完結します。管理者権限を持つ端末、またはMDM経由でHKLM配下に値を書き込みます。

reg add "HKLM\SOFTWARE\Policies\Claude" /v disableWslSessions /t REG_SZ /d false /f

このキーはClaudeポリシーキーの配下に置きます。Claude Codeの管理設定が使うClaudeCodeキーとは別物です。両者を混同すると、Claude Code側のポリシーだけ配ってDesktopのWSLゲートには何も届かない事故が起きます。REG_SZのfalse文字列でも、REG_DWORDの0でも有効です。HKCU配下に同じ値を書いてもDesktopは反応しません。有効化には管理者権限でのHKLM書き込みが必須です。

C:\Program Files\ClaudeCode\managed-settings.jsonを残したままでも構いません。HKLM側のdisableWslSessionsがfalseであれば、そのファイルが存在していてもDesktopはWSLセッションを許可します。Desktopはセッション開始のたびにこのポリシーを読み直すため、値を配ったあとに端末を再起動する必要はありません。

wslInheritsWindowsSettingsとの役割の違い

似た名前の管理者向けキーが2つあり、混同されがちです。役割はまったく別です。

disableWslSessionsはセッションを「開けるか開けないか」の門です。wslInheritsWindowsSettingsは、開いたセッションに「どのポリシーを効かせるか」を決めます。組織展開ではこの2つを両方配って初めて、WSLセッションが使えて、かつ統制も効く状態になります。wslInheritsWindowsSettingsの設定手順と/statusでの確認方法はwslInheritsWindowsSettingsの仕組みと設定方法にまとめています。

disableDesktopLocalSessionsとの関係

WSLの可否を左右するキーはもう一つあります。disableDesktopLocalSessionsです。trueに設定すると、その端末で動くローカルセッションそのものを止め、SSH接続先やクラウドセッションだけを残します。ローカルセッションを止めた端末では、環境ドロップダウンのLocalがグレーアウトされて選べなくなり、WindowsではWSLの項目も同じようにグレーアウトします。

disableDesktopLocalSessionsとdisableWslSessionsは別物です。次の4点が違います。

disableDesktopLocalSessionsがtrueの端末では、disableWslSessionsをfalseにしてもWSLは使えません。ローカルセッションそのものが止まっているため、WSLだけを個別に復活させることはできない設計です。逆に、ローカルセッションは許可しつつWSLだけ絞りたいなら、disableDesktopLocalSessionsには触れずdisableWslSessionsだけを配ります。

Desktopアプリへのアクセス自体を組織で止めたい場合は、この2つのキーよりさらに上位で、管理コンソールの「Code in the desktop」トグルを使います。「Code in the desktop」をオフにするとDesktopのClaude Code自体にアクセスできなくなるため、下位の2キーをどう配っても結果は変わりません。

拒否されたユーザーの画面に何が表示されるか

disableWslSessionsやdisableDesktopLocalSessionsで止めた端末でも、ユーザー側には一貫したメッセージが出ます。展開前にサポート窓口へ共有しておくと、問い合わせの切り分けが早くなります。

• ローカルセッション自体が止まっている場合: 環境ドロップダウンのLocalがグレーアウトし、組織が無効化した旨のツールチップが付きます。既存のローカルセッションを開こうとすると、この端末ではローカルセッションが使えないというメッセージに切り替わります
• WSLだけが止まっている場合: Localは選べたままで、WSLディストリビューションを選ぶとデバイスが管理されている旨のメッセージが出てセッション開始が失敗します
• どちらの場合も、新規セッションはSSH接続先が設定されていればそれを既定にし、無ければクラウドまたはIT部門への確認を案内します

この2パターンを知っていれば、問い合わせが来たときに「Localごと止めているのか、WSLだけ絞っているのか」をユーザーが見ているメッセージの違いだけで判断できます。

配布後にログで有効化を確認する方法

端末でまだWSLセッションが拒否される場合、Claude Desktopのログで原因を特定します。DesktopアプリでHelp > Troubleshooting > Show Logs in Explorerを開くと、ログフォルダーのコピーがDownloadsに保存されます。そのコピー内のmain.logを[wslPolicyGate] denying WSL sessionという文字列で検索します。

拒否理由はメッセージ末尾のカッコ内に出ます。(cli-file-present)のような理由が付くので、どの管理設定ソースが引っかかっているかがそのまま読み取れます。.exeインストーラーでDesktopを入れた端末では、コピーを待たず%APPDATA%\Claude\logs\main.logを直接開いても同じ内容を確認できます。

組織展開のチェックリスト

配布可否を判断する前に、WSLセッションには開いた状態でも使えない機能があることを押さえておきます。並列セッション・サイドチャット・差分レビュー・ブランチ/PRステータス・worktreeは動きますが、統合ターミナル、コネクター・プラグイン、セッションのフォーク、ファイルブラウザーペイン、@によるファイル補完はまだ使えません。CLIメインで使うチームなら影響は小さいものの、統合ターミナルやコネクターに依存する運用では組織展開の前提条件として周知しておく必要があります。

WSLセッションを組織全体で使えるようにするには、次の順で確認します。

• Desktopのバージョンがv1.19367.0以降か
• disableDesktopLocalSessionsがtrueになっていないか(なっていればWSLはどう配っても使えない)
• HKLM\SOFTWARE\Policies\ClaudeにdisableWslSessionsをfalse(またはDWORDの0)で配布したか
• WSL側にも統制を及ぼす必要があるなら、wslInheritsWindowsSettings: trueをHKLM\SOFTWARE\Policies\ClaudeCodeかファイルベースの管理設定に追加したか
• 拒否が続く端末ではmain.logの[wslPolicyGate]行で理由コードを確認したか
• WSL 2のユーティリティVM内はWindows側のエンドポイント検知センサーから見えないため、EDR製品のWSL向けセンサーを別途有効化したか

最後の項目の具体的な設定手順はwslInheritsWindowsSettingsの仕組みと設定方法のエンドポイント監視の節にまとめています。この5点を上から順に潰していけば、配布ミスの切り分けに迷いません。

よくあるつまずき

disableWslSessionsをHKCUに書いてしまい、効果が出ないというつまずきが目立ちます。このキーは管理者権限でのHKLM書き込みだけを見るため、HKCUに同じ値を置いても無視されます。

ClaudeCodeキーとClaudeキーの取り違えも頻発します。Claude Codeの管理設定に慣れている担当者ほど、WSLセッションの許可も同じClaudeCodeキー配下だと思い込みがちです。disableWslSessionsは独立したClaudeポリシーキーの配下にあります。

値を配布したのにWSLセクションが表示されない場合は、レジストリではなくWSL自体の状態を疑います。WSL 1のディストリビューションは対象外です。WSL 2へのアップグレードが前提になります。

disableDesktopLocalSessionsとdisableWslSessionsを両方配ったつもりで片方だけ効いているケースもあります。前者はJSON形式のmanaged settings、後者はWindowsレジストリと配布経路がまったく違うため、片方の配布フローだけを整備して終えてしまいがちです。必要バージョンもv1.37937.0とv1.19367.0で異なるので、端末のDesktopバージョンをまず確認します。

まとめ

disableWslSessionsは、管理端末上でClaude Code DesktopのWSLセッションを許可するかどうかを決める、Claudeポリシーキー配下のレジストリ値です。Claude Desktop v1.19367.0以降で、HKLMにfalseかDWORDの0を配ればセッションが開けるようになります。ClaudeCodeキー配下のwslInheritsWindowsSettingsとは別物で、両方を配って初めてセッションが開けて統制も効く状態になります。

配布の全体像は3層です。管理コンソールの「Code in the desktop」トグルがDesktopアプリへのアクセスそのものを、disableDesktopLocalSessionsがローカルセッション全体を、disableWslSessionsがWSLだけを、それぞれ独立に制御します。「Code in the desktop」をオフにすればDesktopのClaude Code自体に届かなくなるため、下位2キーの設定内容にかかわらず結果は変わりません。配布計画はこの順に確認します。拒否が続く端末では、main.logの[wslPolicyGate]行で理由コードを確認するのが最短の切り分け方法です。組織のWindows端末管理全体はClaude Code組織管理ガイドにまとめています。Desktop WSLセッション自体の始め方はClaude Code Desktop WSLセッションの始め方とCLI版との違いを参照してください。