Claude Code Desktop SSH接続がWindowsで失敗する原因と対処法(ENOENT)¶
2026年2月 更新:このバグは修正されました
本記事で報告していた /usr/bin/ssh パス固定の問題(Issue #25659)は、Claude Code Desktopのアップデートにより修正済みです。Windows環境でもSSH接続が正常に動作するようになりました。
SSH接続のセットアップ手順は以下のハンズオンガイドを参照してください:
Claude Code Desktop SSH × WSL2 実践セットアップガイド【Windows編】
以下の内容は、問題発生時の調査記録として残しています。
この記事のポイント¶
- Claude Code DesktopのSSH sessionsは、Windowsで
Failed to spawn /usr/bin/ssh ENOENTにより接続できない - 原因はSSH実行パスが
/usr/bin/sshにハードコードされている既知バグ(Issue #25659) - OpenSSHがインストール済みでも関係なく、Desktopのspawn処理の問題
- 代替策:VS Code Remote + Claude Code拡張 が現実解
- 2026年2月時点でIssueはOpen、修正待ちの状態
何が起きるか:選択した瞬間に落ちる¶
Desktop UIのSSH接続先を選ぶと、即座にENOENTエラーで失敗する。
Claude Code DesktopにはSSH sessionsという機能がある。 Desktop UIからリモートマシン上のClaude Codeを操作できる、リモート開発向けの機能だ。 公式ドキュメントでもセットアップ手順が案内されている。
Windows環境でSSH接続先を追加し、環境プルダウンから選択すると、こうなる:
Failed to spawn /usr/bin/ssh: spawn /usr/bin/ssh ENOENT
接続先の名前は一覧に表示される。しかし選択した瞬間にこのエラーで落ちるため、実際の接続には至らない。
なぜ起きるか:SSHパスがUnix固定¶
DesktopのSSH spawn処理で、Windowsに存在しないUnixパスを参照している。
GitHub Issue #25659に報告されている通り、 DesktopのSSH spawn処理でSSH実行パスが /usr/bin/ssh にハードコードされている。 Windows上にこのパスは存在しないため、Node.jsのspawnがENOENTを返す。
Issue報告者は「回帰ではなく、最初から動いていない」と明記している。 WindowsのSSH sessionsは、UIに露出しているが実質的に使えない状態が続いている。
Windows上のOpenSSHは通常以下のいずれかにある:
C:\Windows\System32\OpenSSH\ssh.exe(Windows組み込み)C:\Program Files\Git\usr\bin\ssh.exe(Git for Windows同梱)
Desktopがこれらのパスを参照するか、システムPATHから解決すれば動くはずだが、 現時点ではその対応が入っていない。
ネイティブインストールに移行しても直らない¶
claude installで移行しても、SSH sessionsのENOENTは解消しない。
Claude Codeの公式ドキュメントでは NPMインストールはdeprecatedと案内されている。 既存のnpmインストールからネイティブ版への移行コマンドがclaude installだ。
claude install
✔ Claude Code successfully installed!
Version: 2.1.42
Location: C:\Users\<user>\.local\bin\claude.exe
ネイティブ移行後、SSH接続先がDesktopの環境プルダウンに表示されるようになるケースがある。 旧インストール時には出なかった接続先が見えるようになる変化だ。
ただし表示されても、選択するとENOENTで落ちる。 インストール方式の問題ではなく、Desktopの/usr/bin/ssh固定パスが原因のため、移行だけでは解決しない。
「OpenSSHが入っていない」のではないことの切り分け¶
ssh自体は動く。問題はDesktopがそのsshを見つけられないこと。
以下が通っていれば、SSHクライアントとネットワーク経路には問題がないと判断できる:
# 1. OpenSSH の存在確認
ssh -V
# → OpenSSH_for_Windows_9.x ... のように返れば OK
# 2. リモートへの 22/TCP 到達確認
Test-NetConnection <REMOTE_HOST> -Port 22
# → TcpTestSucceeded : True なら OK
# 3. ssh バイナリのパス確認
Get-Command ssh | Select-Object Source
# → C:\Windows\System32\OpenSSH\ssh.exe 等が返る
where のハマりどころ
PowerShellでwhere sshと打つとWhere-Objectの別名が呼ばれ、期待した結果にならない。 パスを調べるには where.exe ssh または Get-Command ssh を使う。
sshバイナリが存在し、リモートに到達できる状態でもDesktopのENOENTは発生する。 Desktopが/usr/bin/sshを直接spawnしているため、Windows上のPATH解決とは無関係にエラーになる。
代替策:VS Code Remote + Claude Code拡張¶
VS Code側のRemote機能で対象環境に入り、Claude Code拡張を使う。
VS CodeのRemote機能(Remote - WSL / Remote - SSH)で対象環境に接続し、 そこでClaude Code拡張を使う方法が現時点の現実解だ。 公式のVS Code統合手順でセットアップできる。
VS Code自体がWindowsのSSHバイナリを正しく解決するため、Desktopで起きるENOENTの問題は発生しない。 DesktopのSSH sessionsに頼らず、VS Code経由でリモートファイルとClaude Codeの両方にアクセスできる。
Issue修正待ち
Issue #25659は2026年2月時点でOpenのまま。Issueをwatchしておけば修正リリース時に通知を受け取れる。
まとめ¶
- Claude Code DesktopのSSH sessionsは、Windowsでは
/usr/bin/sshパス固定の既知バグで動かない - ネイティブインストールに移行しても解消しない(Desktopの実装側の問題)
- VS Code Remote + Claude Code拡張 が現時点の現実解
今後Desktopのクロスプラットフォーム対応が進めば、Windows上でもSSH sessionsが使えるようになるだろう。 macOS/Linuxでは問題なく動作している機能なので、修正の優先度は高いと推測される。 Issueの👍が23件集まっている点からも、コミュニティの関心は高い。