Claude Media
「Failed to spawn /usr/bin/ssh」の原因と対処 — Claude Desktop
Claude CodeTips

「Failed to spawn /usr/bin/ssh」の原因と対処 — Claude Desktop

Claude DesktopのSSHセッションがWindowsでFailed to spawn /usr/bin/sshエラーになる不具合の原因と、回避策が招く別の不具合をGitHub issueからまとめます。

読了目安 約9分

Windows版Claude Desktopで、CodeタブからSSHセッションを使ってリモートマシンに接続しようとすると、Failed to spawn /usr/bin/ssh: spawn /usr/bin/ssh ENOENTというエラーで接続自体が始まらないことがあります。SSHバイナリを起動するパスがUnix系の/usr/bin/sshに固定されており、Windowsにはそのパスが存在しないために起きる不具合です。GitHub issue #25659で2026年2月14日に報告され、その日のうちに複数のユーザーが同じ症状を報告しています。

このTipsでできること

このエラーが今回の不具合によるものだと判断でき、コミュニティが試したシンボリックリンクの回避策と、その回避策自体が引き起こす別の不具合まで把握できるようになります。

実際に出るエラーメッセージと発生条件

報告者の環境はWindows 11 Pro、Claude Code Desktop(最新版)、OpenSSH 10.2p1導入済みでした。ターミナルからはsshコマンドが正常に動くのに、Desktop側のSSHセッション機能だけがこのエラーで止まります。

再現手順は次の4ステップです。

  1. Windows 11でClaude Desktopを開く
  2. SSHの機能・設定画面に移動する
  3. 任意のマシンへのリモートSSH接続を設定する
  4. SSHリモート機能で接続を試みる

期待される結果は接続の確立、実際の結果はFailed to spawn /usr/bin/ssh: spawn /usr/bin/ssh ENOENTでの失敗です。issue報告者は「これまで一度も動いたことがない」としており、過去バージョンからの後退ではなく最初から存在した不具合だと述べています。

報告の直後、自動botが類似issueとの重複候補として検出し、3日以内にコメントが付かなければ自動クローズすると通知しました。実際には報告から数時間のうちに複数の利用者が「同じ症状です」とコメントを重ねたため、自動クローズは働かずそのまま議論が続いています。

原因は/usr/bin/sshのハードコード

報告によると、SSHセッション機能はSSHバイナリのパスとしてUnix系の/usr/bin/sshを固定で参照しています。WindowsでSSHクライアントが置かれる場所は通常C:\Windows\System32\OpenSSH\ssh.exe(標準搭載のOpenSSH)かC:\Program Files\Git\usr\bin\ssh.exe(Git for Windows付属)のいずれかで、/usr/bin/sshというパス自体がWindowsには存在しません。報告者が求めた期待動作は、プラットフォームを検出して適切なパスに切り替えるか、where sshのようにシステムPATHを参照する実装への変更でした。

この不具合が影響するのはClaude DesktopのSSHセッション機能に限られます。ターミナルで直接claudeコマンドを実行する運用や、Bashツールから生のsshコマンドを呼び出す場合は、システムにインストール済みのOpenSSHをそのまま使うため影響を受けません。Desktopアプリの設定画面とターミナル運用の両方を知っておきたい場合は、Claude Code SSH接続ガイドにDesktopのSSHセッション機能とターミナル単体での認証手順がまとまっています。

シンボリックリンクの回避策と、そこで見つかった別の不具合

報告から1日ほどで、ユーザーのSSS135氏がシンボリックリンクを使った回避策を共有しました。

mkdir C:\usr\bin
mklink C:\usr\bin\ssh.exe "C:\Windows\System32\OpenSSH\ssh.exe"

/usr/bin/sshが探しに来るパスへ、標準搭載のOpenSSHへのシンボリックリンクを事前に作っておく方法です。この回避策自体はENOENTエラーを解消しますが、SSS135氏は直後に「Host denied (verification failed)」という別のエラーに突き当たったと報告しています。

別のユーザーpockerhead氏が同じ回避策を試して詳しく検証したところ、ENOENTが解消されると、Desktopアプリはシステムのsshコマンドを起動する代わりに、アプリ内蔵のssh2ライブラリへ切り替わることが分かりました。ログに[SSH2Connection]という表記が現れることで判別できます。そしてこの内蔵ライブラリ側で、非標準ポートを使う接続のホスト鍵検証が壊れていました。

非標準ポートでホスト鍵検証が壊れる仕組み

pockerhead氏の検証環境はWindows 11 Pro(ビルド10.0.26100、x64)、Claude Desktop 1.1.3189、同梱のClaude Code 2.1.41で、接続先はポート40010(非標準)のクラウドGPUインスタンスでした。symlink適用後のログは次の順で失敗します。

[SSH2Connection] Resolved root@<host> -> root@<host>:40010
[SSH2Connection] Host <host>:40010 is not in known_hosts
[SSH2Connection] Connecting to root@<host>:40010 (agent: false, key: true, proxy: false, keyboard: true)
[SSH2Connection] Connection error: Host denied (verification failed)

該当するホスト鍵は~/.ssh/known_hostsに確かに存在し、ターミナルからssh -p 40010 root@<host>を直接実行すれば即座に接続できる状態でした。それでもDesktopアプリだけが鍵を見つけられません。pockerhead氏は次の対応をすべて試しましたが、いずれも効果がありませんでした。

試した対応結果
known_hostsに[<host>]:40010形式(OpenSSH標準)で登録結果認識されない
ポートなし・ブラケットなしの<host>形式で登録結果認識されない
ログ表記に合わせた<host>:40010形式で登録結果認識されない
ssh_configs.jsonのtrustedHostsに各形式を登録結果効果なし
~/.ssh/configにStrictHostKeyChecking no結果無視される
~/.ssh/configにUserKnownHostsFile /dev/null結果無視される

pockerhead氏が突き止めた根本原因は次の4点です。

  1. OpenSSHは非標準ポートのエントリを[host]:portのようにブラケット付きでknown_hostsに保存するが、内蔵のssh2ライブラリはブラケットなしのhost:portで検索するため一致しない
  2. 未知のホスト鍵を許可するUIが無く、鍵が見つからないと即座に接続を拒否する。標準的なSSHクライアントにある「信頼して続行」のようなプロンプトが無く、選べるのは同じエラーを繰り返す「Try again」だけ
  3. ssh_configs.jsonのtrustedHostsがホスト鍵検証に効かない
  4. ~/.ssh/configのHost・Port・HostNameは正しく読み込む一方、StrictHostKeyCheckingやUserKnownHostsFileといったセキュリティ関連の設定は無視する

pockerhead氏はこの検証結果をもとに、issueに4つの修正案を書き添えています。ブラケット形式に対応し、未知ホストを承認するUIを設け、trustedHostsを実際に効かせ、StrictHostKeyCheckingに従う、という内容です。Claude Desktop単体では非標準ポートを使うSSH接続の回避策は無く、Claude Code CLIはシステムのOpenSSHをそのまま使うため、この問題自体の影響を受けません。

sshIdentityFileの~がWindowsで展開されない

同じissue内で、pockerhead氏はもう一つ別の不具合も報告しています。ssh_configs.jsonのsshIdentityFileフィールドに~を使ったパスを指定しても、Windows上では展開されません。

sshIdentityFileの指定ログのkeyフィールド
~/.ssh/id_ed25519ログのkeyフィールドfalse(鍵が見つからない)
C:\\Users\\<user>\\.ssh\\id_ed25519ログのkeyフィールドtrue(鍵を認識)

~表記のままでは秘密鍵が見つからないので、Windowsではユーザーディレクトリを含むフルパスを直接書く必要があります。sshConfigsの設定例でもsshIdentityFileは登場しますが、Windows環境ではこの展開の癖を踏まえてフルパス指定にしておくと安全です。

影響範囲はDesktopのSSHセッションだけ

公式ドキュメントでは、SSHセッションの設定項目としてSSH Host・SSH Port・Identity Fileの3つが挙げられており、接続先のリモートマシンはLinuxまたはmacOSであることが前提とされています。Windows同士の接続を試している場合は、この前提自体に当てはまっていないか確認する価値があります。

WindowsとClaude Codeの組み合わせでは、今回とは別の不具合もいくつか報告されています。Git Bashで発生するnulという名前のファイルが生成される不具合や、shebang付きスクリプト実行時にstdoutが空になる不具合、ARM64版でclaude.exeが0xC0000005でクラッシュする不具合は、いずれも今回のSSH関連の不具合とは原因も影響範囲も異なります。症状を混同しないよう、エラーメッセージやログの文言で切り分けることが大切です。

Anthropicの対応とこの先の確認ポイント

コメント欄ではユーザー側からの改善案も出ています。evaneaston氏は、Windows標準のOpenSSH(C:\Windows\System32\OpenSSH\ssh.exe)をそのまま起動する実装にしたうえで、Git BashやWSLが使える環境ではそちら経由の接続も選べるようにする案を提示しました。ただしこれはユーザー個人の要望であり、Anthropicが採用を確約した設計ではない点に注意してください。

Anthropic側のamorriscode氏は2026年2月16日、issueに「Sorry about this folks, this will be fixed in the next release.」と返信しています。修正対象がENOENT・ホスト鍵検証・~展開のどこまでを指すかは返信の文面からは特定できませんが、issue自体はその後クローズされ、2026年2月24日にはbotが7日間動きが無かったとして自動ロックしています。

この返信は具体的な修正バージョン番号を示していません。一次ソースを確認した時点でも、その後に修正版の番号が公表された形跡は見当たりませんでした。このエラーに遭遇している場合、まずClaude Desktopのバージョン表示を確認したうえで、再現手順の4ステップを踏み直し、どの段階でどのエラーメッセージが出るかを本記事のログと照らし合わせてください。ホスト鍵検証と~展開の不具合は、ENOENT自体の修正とは別枠の指摘としてissueに残っているため、ENOENTが直っていても非標準ポートやチルダ展開の症状だけが残っている可能性は考えられます。

まとめ

Windows版Claude DesktopのSSHセッション機能は、SSHバイナリのパスが/usr/bin/sshに固定されているためFailed to spawn /usr/bin/ssh: spawn /usr/bin/ssh ENOENTで失敗することがあります。シンボリックリンクでこのエラー自体は回避できますが、代わりに内蔵ssh2ライブラリの非標準ポートでのホスト鍵検証エラーが表面化する場合があります。sshIdentityFileの~がWindowsで展開されない不具合も同じissue内で報告されています。いずれもClaude DesktopのSSHセッション機能に限られ、CLIでのターミナル運用やBashツール経由のsshコマンドには影響しません。

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

関連する記事

Claude Code をもっと見る →