Claude Desktop で「このデバイスでは WSL セッションを利用できません」と出たときの原因と対処

はじめに

こんにちは。くどうです。

Claude DesktopのCodeタブでは、Windowsの端末でWSL 2のディストリビューションを選び、その中でClaude Codeのセッションを動かすことができます。

Claude Desktopのポリシー（レジストリ値）を端末に配った状態でWSLセッションを開始したところ、「このデバイスではWSLセッションを利用できません」と表示されて開始できませんでした。

詳細には次のメッセージが出ていました。

WSL sessions are not available because this device is managed by your organization.

本ブログでは、EC2上のWindows Serverに検証環境を作り、どの設定でこのメッセージが出るのか、どうすればちゃんと動くようになるのかを確かめました。

結論

• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Claudeに値が1つでもあると、Claude Desktopはその端末を「組織で管理されている端末」と判定し、WSLセッションが使えなくなります。ローカルのMCPサーバーを無効にするisLocalDevMcpEnabledを設定すると、この判定になりました
• 同じ場所にdisableWslSessions（REG_DWORD）を0で追加すると、ほかのレジストリ値の設定を活かしたままWSLセッションが使えるようになります。

仕組み

公式ドキュメントの「Set up Claude Code for your organization」によると、Claude Desktopは「組織で管理されている端末」で、WSLセッションを既定で無効にします。有効にするには、HKEY_LOCAL_MACHINE\SOFTWARE\Policies\ClaudeにdisableWslSessionsを0で設定します。

HKLM\SOFTWARE\Policies\Claude の下に disableWslSessions という名前の値を作成し、REG_SZ 文字列 false または REG_DWORD 0 に設定します。この値は Claude Desktop ポリシーキーの下にあり、管理設定を含む ClaudeCode キーとは別です。HKLM の下に値をデプロイします。これには管理者権限が必要です。HKCU の下の値は WSL セッションを有効にしません。

どの端末を「組織で管理されている端末」と判定するかは、ドキュメントには例が1つ（C:\Program Files\ClaudeCode\managed-settings.jsonがある場合）載っているだけです。今回は、Claude Desktopのポリシー（レジストリ値）でもこの判定になるかを確かめました。

→検証の結果、Claude Desktopのポリシー（レジストリ値）でも『組織で管理されている端末』と判定されました。
Claude Desktopのポリシーをレジストリ値で配った端末でWSLセッションを使うには、disableWslSessions（REG_DWORD）を0で追加する必要があります。
手元で試したい方は、以降の検証の手順を参照してください。

検証環境

EC2でWSL 2を動かすには、ネストされた仮想化（Nested virtualization）に対応したインスタンスタイプが必要です。執筆時点で対応しているインスタンスファミリーは次のとおりです。

最新の対応状況は「Use nested virtualization to run hypervisors in Amazon EC2 instances」で確認してください。

やってみた

EC2でWSL 2を動かす

最初に用意したEC2インスタンス（t8i.medium）でwsl --install -d Ubuntuを実行すると、次のエラーでWSL 2を開始できませんでした。

エラー コード: Wsl/InstallDistro/Service/RegisterDistro/CreateVm/HCS/HCS_E_HYPERV_NOT_INSTALLED

wsl.exe --install --no-distributionで「仮想マシン プラットフォーム」を有効にして再起動しても、結果は同じでした。WSL 2はHyper-Vの仮想化を使うため、EC2のインスタンスの中で動かすには、インスタンスでネストされた仮想化（Nested virtualization）を有効にする必要があります。

※下の画像は、インスタンスの起動画面のものです。インスタンスを新しく作る場合は、『高度な詳細』でこの設定を有効にしてから起動すれば、あとで停止して変更する必要がありません。

「検証環境」の表のとおり、ネストされた仮想化に対応したインスタンスファミリーにT系は含まれていません。そこで、次の手順でインスタンスタイプを変え、ネストされた仮想化を有効にしました。

1. EC2コンソールでインスタンスを停止する
2. 「アクション」＞「インスタンスの設定」＞「インスタンスタイプを変更」で、m8i-flex.largeに変更する
3. 「アクション」＞「インスタンスの設定」＞「CPUオプションを変更」を開き、「ネストされた仮想化」を「有効」にして保存する
4. インスタンスを起動する

ネストされた仮想化を変更できるのは、インスタンスが停止しているときだけです。ネストされた仮想化自体に追加料金はかかりませんが、インスタンスタイプを変えた分の料金は変わります。

EC2のネストされた仮想化と、EC2でWSL 2を使う手順については、次の記事を参照してください。

https://dev.classmethod.jp/articles/koty-mousa-ec2-support-nested-virtualization/

インスタンスを起動し直すと、wsl --install -d Ubuntuが成功しました。続けてUbuntuにgitを入れます。（最初からはいってるかも。入ってなかったらいれる。）

sudo apt update && sudo apt install -y git

ディストリビューションが入る前のClaude Desktopでは、環境の一覧に「WSL」の項目が出ていませんでした。

ディストリビューションを入れたあとは、環境の一覧に「Ubuntu」が出ました。

サンドボックスの準備

Ubuntuを選んでメッセージを送ると、次のエラーが出ました。

Error: sandbox required but unavailable: sandbox is enabled but dependencies are missing: socat not installed · install missing tools (e.g. apt install bubblewrap socat) or see https://code.claude.com/docs/en/sandboxing
  sandbox.failIfUnavailable is set — refusing to start without a working sandbox.

管理設定でサンドボックスを強制しているため、サンドボックスに必要なsocatがないとClaude Codeは動きません。Ubuntuにbubblewrapとsocatを入れます。

sudo apt update && sudo apt install -y bubblewrap socat

入れたあとに「もう一度試す」を押すと、WSLセッションでClaude Codeが応答しました。

この時点ではHKEY_LOCAL_MACHINE\SOFTWARE\Policies\Claudeに何も設定していません。管理されている端末と判定されていなければ、WSLセッションはそのまま開始できます。

レジストリ値でClaude Desktopのポリシーを設定する

初期状態だとHKEY_LOCAL_MACHINE\SOFTWARE\Policiesには、Claudeのキーがありません。

ここにローカルのMCPサーバーを無効にするisLocalDevMcpEnabledのレジストリ値を設定します。PowerShellを管理者として実行し、下記のコマンドで設定しました。

New-Item -Path 'HKLM:\SOFTWARE\Policies\Claude' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Claude' -Name 'isLocalDevMcpEnabled' -Value 0 -PropertyType DWord -Force | Out-Null

Claude Desktopを起動し直し、新しいセッションでUbuntuを選んでメッセージを送ると、エラーが出ました。

ログで理由を確かめる

Claude Desktopのメニューの「ヘルプ」＞「トラブルシューティング」＞「エクスプローラーでログを表示」を選ぶと、ダウンロードフォルダにClaude-logs-（日時）.zipが保存されます。

その中のmain.logに、次の行がありました。

[info] [managedConfig] configuration at launch { type: 'managed', remote: false, managedKeys: [ 'isLocalDevMcpEnabled' ] }
[info] Managed MDM config detected { keys_set: [ 'isLocalDevMcpEnabled' ] }
[warn] [wslPolicyGate] denying WSL session (managed-presence): desktop managed tier owns the config, set at least one key, or claimed the app-behavior overlay

レジストリの値を設定する前の起動では、configuration at launch { type: 'none', remote: false, managedKeys: [] }でした。isLocalDevMcpEnabledを設定したことで、Desktopが端末を管理されている端末（type: 'managed'）と判定しています。

disableWslSessionsを入れてエラーを回避する

次に、同じ場所にdisableWslSessionsを追加しました。

New-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Claude' -Name 'disableWslSessions' -Value 0 -PropertyType DWord -Force | Out-Null
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Claude'

Claude Desktopを再起動せずに、新しいセッションでUbuntuを選んでメッセージを送ると、WSLセッションで応答が返りました。

このときのmain.logには、次の行があります。

[warn] [wslPolicyGate] allowing WSL sessions on a managed device (machine-scoped-false): host endpoint policy does not apply in-distro unless policy is server-managed or wslInheritsWindowsSettings is deployed

端末は管理されている端末と判定されたまま、disableWslSessionsによってWSLセッションが許可されています。

設定画面の「このコンピュータ」の下は「システム」と「拡張機能」だけで、ローカルのMCPサーバーを設定する「開発者」タブは表示されていません。isLocalDevMcpEnabledの効果はそのまま残っています。

結果のまとめ

注意点

• Desktopは、値が設定されているかどうかで管理されている端末かを判定しているようです。isLocalDevMcpEnabled以外のClaude Desktopのポリシー（自動更新の無効化など）を配った場合も、同じようにWSLセッションが止まると考えられます。今回はisLocalDevMcpEnabledでだけ確かめました
• disableWslSessionsはHKEY_LOCAL_MACHINEに設定してください。ドキュメントでは、HKEY_CURRENT_USERではWSLセッションは有効にならないとされています
• サンドボックスを強制している場合は、WSLのディストリビューションにbubblewrapとsocatが必要です

おわりに

Claude Desktopのポリシー（レジストリ値）を1つ配るだけで、CodeタブのWSLセッションが止まることを確かめました。Windowsの端末でClaude CodeをWSLの中で使う運用にする場合は、Claude Desktopのポリシーを配るときにdisableWslSessionsも一緒に配りましょう。

参考

• Set up Claude Code for your organization（WSL sessions in Claude Code Desktop）
• Claude Code Desktop in WSL
• Enterprise configuration for Claude Desktop
• Use nested virtualization to run hypervisors in Amazon EC2 instances
• [新機能]EC2で ネストされた仮想化がサポートされました！── EC2 で WSL2 を使ってみよう！