Claude Media
disableWslSessionsでClaude Code DesktopのWSLを組織展開する
Claude Codeチュートリアル

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

Claude Code Desktopは管理端末でWSLセッションを既定オフにします。disableWslSessionsレジストリキーでの有効化と、症状から止まっている関門を探す手順をまとめます。

読了目安 約8分

disableWslSessionsで何ができるか

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

配布にはClaude Desktop v1.19367.0以降が必須です。それより古いDesktopにキーを配っても効果がないので、アプリの更新が前提になります。

WSLセッションは、リポジトリがディストリビューション内のファイルシステムにあるときに使う選択肢です。Windows側からそのファイルを触るとネットワークファイルシステム経由になり、遅く、ファイル監視も壊れます。セッションごとディストリビューション内で動かせば、どちらも避けられます。

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

Claude Desktopは、たとえばC:\Program Files\ClaudeCode\managed-settings.jsonのような管理設定ファイルがある端末を、組織管理下と検知します。管理下と検知した端末では、WSLセッションを既定で無効にします。

不具合ではなく、管理端末での初期値です。WSLセッションの中で動くClaude Codeは、既定ではLinux側の/etc/claude-code/managed-settings.jsonしか読まず、Windows側の管理設定が届きません。

disableWslSessionsを配布する手順

有効化はWindowsレジストリへの1エントリで終わります。管理者権限のある端末か、MDM経由でHKLM配下に値を書き込みます。

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

1行目が書き込み、2行目が配布後の読み戻しです。REG_DWORDで配るなら、/t REG_DWORD /d 0に差し替えます。文字列のfalseでも数値の0でも有効です。

キーの置き場所には2つの落とし穴があります。

  • ClaudeとClaudeCodeは別のキーです。Claude Codeの管理設定が使うのはClaudeCodeキーで、disableWslSessionsはDesktop自身のポリシーキーであるClaudeの配下に置きます。Claude Code側のポリシーだけを配って、DesktopのWSLゲートには何も届かない事故がここで起きます
  • HKCUでは効きません。HKCU配下に同じ値を書いてもWSLセッションは有効にならず、管理者権限でのHKLM書き込みが必須です

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

止まっている関門を症状から切り分ける

WSLセッションが開けない原因は、Desktopの3つの関門のどれかにあります。ユーザーの画面に出る症状と、管理者が見る場所を上から順に突き合わせます。

切り分け

どの関門で止まっているかを上から探す

  1. 1

    Desktopで Claude Code 自体が使えない

    管理コンソール(admin settings)のCode in the desktopが関係します。このトグルは、組織のユーザーがDesktopアプリでClaude Codeにアクセスできるかどうかを決めます。ここで止まっているなら、以降のキーを調べる前に管理コンソールを見ます。

  2. 2

    Localもグレーアウトしている

    disableDesktopLocalSessionsがtrueです。環境ドロップダウンのLocalが選べず、ツールチップには組織が無効にした旨が出ます。WindowsではWSLの項目も同じようにグレーアウトします。既存のローカルセッションを続けようとすると、この端末ではローカルセッションを使えない旨のメッセージに変わります。新しいセッションの既定は、最初に設定されたSSH接続になります。

  3. 3

    Localは選べるが、WSLを選ぶと失敗する

    disableWslSessionsの領分です。ディストリビューションを選ぶとデバイスが管理されている旨のメッセージが出て、セッションの開始が失敗します。レジストリの値はこの関門だけを開けます。

ログで拒否の理由コードを読む

レジストリを配ったのに特定の端末で拒否が続くときは、その端末のDesktopログに理由が残っています。

手順

main.logで拒否の理由を読む

  1. 1

    ログを取り出す

    端末のDesktopでHelp > Troubleshooting > Show Logs in Explorerを開きます。ログフォルダーのコピーがDownloadsに保存されます。

  2. 2

    main.logを検索する

    コピーの中のmain.logを、[wslPolicyGate] denying WSL sessionで検索します。

  3. 3

    カッコ内の理由を読む

    メッセージの末尾に、拒否理由がカッコ付きで続きます。たとえば(cli-file-present)が付いていれば、管理設定ファイルの存在が引っかかっています。

.exeインストーラーでDesktopを入れた端末なら、コピーを待たずに%APPDATA%\Claude\logs\main.logを直接開いても同じ内容が読めます。

disableDesktopLocalSessionsとの違い

disableDesktopLocalSessionsは、WSLに限らず端末上で動くCodeセッションを止めるキーです。SSH接続先とクラウドセッションは残り、デスクトップアプリがこのキーを読みます。ターミナルのCLIは無視します。

くらべる

止める範囲で選ぶ

disableWslSessions

WSLだけ絞る

Windowsでローカルセッションは許可しつつ、WSLだけを使わせない運用向けです。disableDesktopLocalSessionsには触れず、レジストリのdisableWslSessionsだけを扱います。

disableDesktopLocalSessions

ローカル全体を止める

開発はSSH先の開発機やクラウドで行い、手元の端末では動かさない運用向けです。sshConfigsで接続先を配り、sshHostAllowlistで行き先を絞る使い方とセットになります。

2つのキーは性質がかなり違います。

観点disableDesktopLocalSessionsdisableWslSessions
配布経路disableDesktopLocalSessionsmanaged settings(JSON)disableWslSessionsWindowsレジストリ(HKLM)
必要バージョンdisableDesktopLocalSessionsClaude Desktop v1.37937.0以降disableWslSessionsClaude Desktop v1.19367.0以降
有効な値disableDesktopLocalSessionsJSONのブール値trueだけdisableWslSessionsREG_SZのfalseまたはREG_DWORDの0
値を誤ったときdisableDesktopLocalSessions文字列"true"や1は無効(警告がログに出る)disableWslSessionsHKCUに書いた値は無視される

disableDesktopLocalSessionsは、managed settingsに次の1行を置けば有効になります。

{
  "disableDesktopLocalSessions": true
}

このキーがtrueの端末では、同じ端末へ戻るSSH接続も開始できません。

wslInheritsWindowsSettingsとの役割の違い

名前の似たキーがもう1つあります。役割は別です。

観点disableWslSessionswslInheritsWindowsSettings
制御する対象disableWslSessionsWSLセッションを開始できるかどうかwslInheritsWindowsSettingsWindows側の管理設定をWSLへ継承させるかどうか
置き場所disableWslSessionsHKLM\SOFTWARE\Policies\ClaudewslInheritsWindowsSettingsHKLM\SOFTWARE\Policies\ClaudeCodeかC:\Program Files\ClaudeCodeのファイル
未設定のときdisableWslSessions管理端末でWSLセッションが開始できないwslInheritsWindowsSettingsセッションは開くが、Windows側のポリシーがWSL側に届かない

disableWslSessionsが「開けるかどうか」の門だとすれば、wslInheritsWindowsSettingsは開いたセッションに効かせるポリシーの経路を決めます。WSLは既定で/etc/claude-codeのファイルしか読まないので、Windows側のレジストリとC:\Program Files\ClaudeCodeのポリシーを及ぼすには、wslInheritsWindowsSettings: trueをそのどちらか(管理者専用の経路)に置く必要があります。設定手順と確認方法はwslInheritsWindowsSettingsの仕組みと設定方法にあります。

継承が効いているかは、WSLセッションの中で/statusを実行し、Setting sourcesの行で見ます。Enterprise managed settingsの横のカッコに、選ばれた管理ソースが出ます。レジストリなら(HKLM)、ファイルなら(file)です。この行が無ければ、Claude Codeは管理ソースを見つけていません。

WSLセッションを開いたあとの制約

配布前に、ユーザーへ伝えておく前提があります。

  • Windows 10または11のWSL 2が必要で、WSL 1は対象外です。ディストリビューションが1つ以上あり、その中にgitが入っている必要があります
  • フォルダーのトラストは、ディストリビューションとフォルダーの組ごとに付与されます。あるディストリビューションで信頼したフォルダーは、別のディストリビューションや、Windows上の同じパスでは信頼されません
  • 並列セッション、サイドチャット、差分レビュー、ブランチとPRのステータス、worktreeは動きます
  • 統合ターミナル、コネクターとプラグイン、セッションのフォーク、ファイルブラウザーペイン、@によるファイル補完はまだ使えません

CLI中心のチームなら影響は小さい一方で、統合ターミナルやコネクターに依存する運用では、展開前に周知しておく項目です。

配布後に残りやすいつまずき

disableDesktopLocalSessionsとdisableWslSessionsを両方配ったつもりで、片方だけ効いているケースがあります。配布経路もバージョン条件も違うので、効かない端末ではDesktopのバージョンを先に見ます。

WSLの項目が出ないときは、レジストリより先にWSL自体の状態を疑います。WSLセクションに並ぶのはWSL 2のディストリビューションで、WSL 1は対象外です。

セキュリティ監視を入れている環境では、もう1点あります。WSL 2のユーティリティVMの中のプロセスは、Windows側のエンドポイント検知センサーから見えません。EDR製品のベンダーがLinux向けセンサーを案内していれば、ディストリビューション内で動かし、必要な除外設定も入れます。Claude CodeのOpenTelemetryによるツール実行テレメトリは、WSLでもネイティブでも同じ形で出ます。

まとめ

disableWslSessionsはHKLM\SOFTWARE\Policies\Claudeに置くDesktop自身のポリシーで、WSLセッションを開けるかどうかだけを決めます。開いたセッションに管理設定を効かせるのは別のキーwslInheritsWindowsSettingsなので、WSLを展開するなら両方を配ります。

組織のWindows端末の管理全体はClaude Code組織管理ガイドにあります。Desktop WSLセッション自体の始め方はClaude Code Desktop WSLセッションの始め方とCLI版との違いが扱っています。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →