Claude Media
Claude Code Desktop WSLセッションの始め方とCLI版との違い
Claude Codeチュートリアル

Claude Code Desktop WSLセッションの始め方とCLI版との違い

Claude Code DesktopのCodeタブから、WSL2ディストリビューション内でセッションを直接起動する方法です。始め方の3ステップと、CLIをWSLターミナルから起動する既存の手順との使い分けをまとめます。

読了目安 約9分

リポジトリがWSL2ディストリビューションの中にあるなら、Claude Code DesktopのCodeタブからそのディストリビューションの中でセッションを動かせます。Claude Codeのプロセス、ツール群、gitまで、すべてがディストリビューションの内部で実行され、Linuxのネイティブなパスをそのまま使います。

なぜWSLセッションを選ぶのか

Windows側からディストリビューション内のファイルを触ると、ネットワークファイルシステム経由になります。動作が遅く、ファイル監視も壊れます。セッションをディストリビューション側で起動すれば、この2つを両方避けられます。

これはDesktopアプリのCodeタブが持つ機能で、WSLターミナルからCLIを直接起動する方法とは別物です。環境ドロップダウンにはLocal・Cloud・SSHと並んで、Windowsでは4つ目としてWSLが出ます。Localの一部ではなく、独立した実行先です。

前提条件は次の3つです。

  • Windows 10または11、かつWSL 2(WSL 1は非対応)
  • ディストリビューションが最低1つインストール済み(Ubuntuなど)
  • ディストリビューション内にgitがインストール済み

WindowsでClaude Code自体をネイティブ版とWSL版のどちらで動かすかは、Desktopアプリの導入前に迷う点です。判断材料はClaude Code Windowsインストールで整理しています。

セッションの始め方

手順

WSLセッションを始める3ステップ

  1. 1

    ディストリビューションを選ぶ

    Codeタブで新規セッションを開始し、環境ドロップダウンを開きます。インストール済みのWSL 2ディストリビューションが「WSL」セクションに並ぶので、使うものを選びます。

  2. 2

    フォルダーを選ぶ

    セッションはディストリビューションのホームディレクトリから始まります。フォルダーピッカーでは/home/you/projectのようなLinuxパスで辿れます。

  3. 3

    フォルダーを信頼する

    フォルダーで最初のセッションを開くと、ワークスペース信頼ダイアログが出ます。信頼はディストリビューションとフォルダーの組み合わせごとです。

ディストリビューション内で最初に開くセッションは、Claude側のセットアップが走るぶん起動がやや遅くなります。通常のフォルダーピッカーから\\wsl.localhost\...形式のフォルダーを開いても、対応するディストリビューション内で開き直されます。最近使ったフォルダーはディストリビューションごとにピッカーへ表示されるので、同じプロジェクトへの再接続はワンクリックです。

信頼ダイアログが何度も出るとき

あるディストリビューションで信頼したフォルダーは、別のディストリビューションでも、Windows側の同じパスでも信頼されません。同じプロジェクトでも開き方を変えると別物として扱われ、再度信頼が必要になります。

権限モードとモデルの選び方

新規セッションを送信する前には、環境のほかにプロジェクトフォルダー、モデル、権限モードを選びます。権限モードはClaudeにどこまで自律的に進めさせるかを決めるセレクターです。モデルと権限モードは、セッション中にも変更できます。

新規ローカルセッションの既定モードは、設定ファイルのpermissions.defaultModeで設定できます。ただしセレクターで選んだモードはフォルダー単位で記憶され、そのフォルダーではdefaultModeより優先されます。Planモードだけはそのセッション限りの適用です。

Bypass permissionsをセレクターに出すには、有効化の操作が別途必要です。ProまたはMaxプランではSettingsのClaude Code設定で「Allow bypass permissions mode」をオンにします。TeamまたはEnterpriseプランにはこのトグルが存在せず、組織のポリシーが制御します。サンドボックス化されていない環境での常用は避け、隔離されたコンテナやVM内にとどめます。

WSLセッションで使える機能・使えない機能

並列セッション、サイドチャット、ビジュアルな差分レビュー、ブランチとプルリクエストの状態、worktreeは、ディストリビューション内のgitとツールチェーンに支えられて動きます。「エディタで開く」を選ぶと、Remote - WSL経由でVS Codeがそのディストリビューションに接続した状態で開きます。VS Code拡張機能そのものはClaude Code VS Code拡張機能の使い方にまとめています。

Desktopのセッション間で連携する仕組みで、Claudeが見られるのはDesktopが動かすLocal・SSH・WSLのセッションです。クラウドセッションや、ターミナルCLI・VS Code拡張から始めたセッションは見えません。

一方、次の機能はWSLセッションでまだ使えません。

  • 統合ターミナル
  • コネクタとプラグイン(プロンプト欄の「+」ボタンも出ない)
  • セッションのフォーク
  • ファイルブラウザーペイン
  • @によるファイル候補

CLIセッションを引き継ぐ/resumeは、仕様上Localセッション専用で、WSLでは使えません。

WSLセッションでこれらが必要になったら、WSLターミナルからCLIを直接起動する方法に切り替えます。

サイドチャットはWSLセッションでも使えますが、Desktopがディスクに保存しないため、アプリを閉じると戻れません。

Claudeが他のセッションを参照する仕組みでは、既定で直近に動いた20セッションが対象で、アーカイブ済みは頼まない限り含まれません。

Desktop WSLセッションとCLI直接起動の使い分け

同じWSL上の作業でも、起動元で得られるものが変わります。

くらべる

どちらでWSLの作業を始めるか

画面で見たい・並行したい

Desktop WSLセッション

環境ドロップダウンから起動します。複数プロジェクトの並行管理、差分やPR状態のビジュアル確認に向きます。統合ターミナル・コネクタ・プラグインは使えません。

プラグイン・ターミナル中心

WSLターミナルからCLI

bashやzshからclaudeを起動します。ターミナル上で作業するので、claude.aiのコネクタやプラグインも使えます。差分の確認はターミナル上になります。

CLI側の手順はClaude Code WSL2セットアップにあります。DesktopアプリとCLI・Web版全体の使い分けはClaude Code Desktopとはにまとめています。

Desktopで使っているMCPサーバーをWSL側のCLIに引き継ぐ

スタンドアロンのCLIは、Claude Desktopのclaude_desktop_config.jsonを読みません。macOSとWSLでは、Desktopで設定済みのMCPサーバーを~/.claude.jsonへコピーするコマンドが用意されています。v2.1.285で--helpを実行すると、次のように表示されました。

claude mcp add-from-claude-desktop --help
Usage: claude mcp add-from-claude-desktop [options]
 
Import MCP servers from Claude Desktop (Mac and WSL only)
 
Options:
  -h, --help           Display help for command
  -s, --scope <scope>  Configuration scope (local, user, or project) (default:
                       "local")

スコープの既定はlocalです。全プロジェクトで使いたいなら--scope userを付けます。

実行すると、取り込むサーバーを選ぶ対話ダイアログが開きます。名前に英数字・ハイフン・アンダースコア以外を含むサーバーは取り込めず、スキップされます。同名のサーバーが既にあると、server_1のような接尾辞が付きます。

この取り込みはWSLターミナルから起動するCLIの話で、Desktop WSLセッションではコネクタを使えない点は変わりません。

組織管理デバイスでWSLが選べないとき

組織が管理するデバイスでは、Claude DesktopがWSLセッションを既定で無効にします。管理対象と判定される例として、C:\Program Files\ClaudeCode\managed-settings.jsonが存在する場合が挙げられています。セッション開始時に「デバイスが管理されている」という趣旨のメッセージが出て失敗するなら、この制限が原因です。

Local環境がdisableDesktopLocalSessionsで無効化されると、Localの項目に加えてWSLの項目もグレーアウトします。ただしWSLの可否は別の設定で決まります。Localが使えるのにWSLだけ無効なこともあります。

管理者側の切り分けは次のとおりです。

状況見る場所
WSLだけ選べない見る場所レジストリのdisableWslSessions
Localも選べない見る場所disableDesktopLocalSessions
WSL内でポリシーが効かない見る場所wslInheritsWindowsSettings

WSLを有効にするには、HKLM\SOFTWARE\Policies\ClaudeにdisableWslSessionsを作り、REG_SZのfalseかREG_DWORDの0を設定します。必要なClaude Desktopはv1.19367.0以降です。HKCU配下の値では有効になりません。managed-settings.jsonを置いたままでも、この値で許可できます。

Desktopはポリシーを、WSLセッションを始めるたびに読み直します。アプリの再起動は不要です。拒否されたときは、HelpメニューのTroubleshootingからShow Logs in Explorerを開き、main.logで[wslPolicyGate] denying WSL sessionを探します。理由が(cli-file-present)のように続きます。Show Logs in Explorerは、ログフォルダーのコピーをDownloadsに保存します。.exeインストーラーで導入したClaude Desktopなら、%APPDATA%\Claude\logs\main.logを直接読むこともできます。

WSL内のClaude Codeプロセスが既定で読むのは、Linux側の/etc/claude-codeだけです。Windowsだけにある管理設定は拾いません。Windows側と同じポリシーを効かせるには、wslInheritsWindowsSettings: trueを配布します。効いているかはWSLセッションで/statusを実行し、Setting sourcesの行で確認できます。

利用者側の対処は、管理者への確認か、SSHやクラウド環境への切り替えです。

起動できないときの切り分け

WSLセクションに何も出ない、または選んだディストリビューションで起動できないときは、WSL 1のディストリビューションではないかを見ます。WSL 2へのアップグレードが必要です。ディストリビューション内にgitが入っているかも確認します。

まとめ

組織管理のPCでWSLが選べないときは、ユーザー側では直せない設定が原因で、管理者が制御しています。管理者には、レジストリのdisableWslSessionsとwslInheritsWindowsSettingsの確認を頼みます。

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

関連する記事

Claude Code をもっと見る →