dsh で WSL を使う：2つのルート — 実録手順とプラグイン直結

録画どおりの手順です。ビルドツールを準備し（sudo apt update、次いで sudo apt install -y build-essential python3）、nvm で Node 24 を入れながら NVM_NODEJS_ORG_MIRROR を速いミラーに向け、npm config set registry https://registry.npmmirror.com を設定し、npx -y @deepseek-ai/dsh web で起動。または npm install -g @deepseek-ai/dsh でグローバルに入れて dsh web を実行します。名前の罠も忘れずに。Kali で apt install dsh とすると、DeepSeek Harness ではなく dancer's shell が入ります。

必要ありません。Windows では dsh はネイティブに動きます。Node.js、npm、ポート3080の Web UI がすべて PowerShell の中。Windows 向けインストールガイドがこの道を扱っています。WSL が価値を持つのは、bash・apt・Linux パスといった本物の Linux ツールチェーンをセッションの背後に置きたいときだけです。しかもその目的なら、プラグインのルート B で達成でき、WSL 内に2つ目の dsh は要りません。

録画は Kali（kali-rolling）を使用し、最後の画面まで到達しています。その根拠となったガイド文は Ubuntu を例にしており、どちらでも動きます。要点は apt ベースのディストリビューションであること、ルート A なら Node.js 24 を追加することです。ルート B では問題さらに小さく、dsh-wsl-workspace のダイアログがインストール済みディストリビューションを一覧するので選ぶだけです。公式の推奨は存在しません。「録画で Kali が使われた」という事実の提示であり、推奨ではありません。

既存の Windows 版 dsh に WSL ワークスペースを追加します。セッションの bash はディストリビューション内で実行され、Linux パスを読み書きしますが、WSL 内には dsh を一切入れません（リポジトリ説明、2026-10-06 検証。★69、MIT）。インストールして dsh web を再起動すると、Settings の隣の W ボタンから Add WSL workspace ダイアログが開きます。ディストリビューションを選び、Linux パスを検証し、任意で Linux ユーザー名を設定して Create & open。同じセッション内で Windows のファイルには /mnt/<ドライブ> でアクセスできます。

WSL の内側からは、Windows のドライブが /mnt/<ドライブ> にマウントされます。/mnt/c/Users/... はどちらのルートでも使え、プラグインの README もセッションについて同じことを記しています。Windows の内側からは、ディストリビューションのファイルに \wsl.localhost\<ディストリビューション> のネットワーク共有でアクセスできます。両方の情報源に共通する習慣の話も。ビルドは対象のファイルシステムの中で行うこと。境界を何度もまたぐのが一番遅い道です。

Kali のリポジトリでは、その名前は dancer's shell のものだからです。録画のガイド表にあった -m/-a オプションと machines.list を持つ分散シェルユーティリティです。録画はまさにこの問題に途中で当たり、apt remove -y dsh で修正してから npm パッケージの @deepseek-ai/dsh に切り替えました。dancer's shell パッケージを抱えるディストリビューションなら同じ衝突が起きます。見慣れた名前でも、そのパッケージが何を入れるのか先に確かめる価値があります。