Claude Desktopのリモートマシン接続が「no route to host」で失敗する——原因はHomebrewのsshだった
Claude Desktopでリモートマシン（SSH）に接続すると一瞬で「no route to host」になる不具合を調査。macOS共通の原因とClaude特有の原因（Homebrewのssh×TCC disclaimed launch）を切り分け、恒久対策と応急処置を整理した。
エンジニアのゆとです。
Claude Desktopの「リモートマシン」機能（Codeタブからuser@192.168.1.xのようなLAN内のマシンをSSHで登録する機能）で「Test connection」を押すと、一瞬で次のエラーが返ってくることがある。
Connection failed: SSH host unreachable (no route to host)「一瞬で」というのがポイントで、これは実際にネットワークがタイムアウトした待ち時間ではない。ターミナルから同じホストにsshすれば一発でつながるのに、Claude Desktop経由だけが280ミリ秒前後で即座に失敗する。ネットワークの問題っぽい顔をしているが、正体は別物だ。
2026年9月11日にこの症状がGitHub Issueとして報告され、複数人が再現を追試した結果、9月16日までに根本原因が特定された。原因は「Claude Desktopが起動するsshプロセスがHomebrewのopensshを掴んでしまい、macOSのローカルネットワークプライバシー機能に接続をブロックされる」というものだった。この記事ではその調査の流れと、恒久対策・応急処置の両方を整理する。
まず結論
- 症状: Claude Desktopのリモートマシン機能で「Test connection」がほぼ即座に
SSH host unreachable (no route to host)で失敗する。同じホストへターミナルからsshすると成功する - 原因: Claude.appがPATHの先頭側から
sshを解決するため、Homebrewでインストールした/opt/homebrew/bin/sshを掴んでしまう。この非システム製バイナリはmacOSの権限管理上「TCC responsibility disclaimed（信頼の委譲なし）」で起動され、ローカルネットワークへのアクセスがデフォルトで拒否される - 対象: macOSでHomebrew版opensshを導入している環境（
brew install openssh済み、またはgit系ツール経由で依存導入されているケースを含む） - 影響範囲: Claude Desktopアプリの「リモートマシン」設定のみ。Claude Code CLIやターミナルからの
claude起動、VS Code拡張のBashツールには影響しない（同じマシンの同じネットワークで、CLI経由の接続だけは成功する報告が複数ある）
先に対処法を知りたい人は「解決策」の章まで飛んでほしい。仕組みを追いたい人はこのまま読み進めてもらえたらと思う。
ログで確認する——本当にこの原因か
まず自分の症状がこれに当てはまるか、ログで確認できる。macOSで以下のファイルを見る。
cat ~/Library/Logs/Claude/ssh.logこのパターンが出ていれば、今回の原因と一致している。
[info] [untrustedLaunch] not lending Claude's TCC responsibility: /opt/homebrew is not system-owned (directory_not_root_owned); launching it disclaimed instead
[info] [OpenSSHConnection] starting master for user@192.168.1.x (TCC responsibility disclaimed)
[info] [OpenSSHConnection] master stderr: ssh: connect to host 192.168.1.x port 22: No route to host
[warn] [OpenSSHConnection] master for user@192.168.1.x exited before ready; stderr tail: ssh: connect to host 192.168.1.x port 22: No route to hostポイントは1行目のnot lending Claude's TCC responsibilityだ。これはClaude.appが「このsshバイナリはシステム所有(root所有)のディレクトリに置かれていないから、自分の持っている権限（Local Network使用許可）を貸せない」と判断し、sshプロセスを”disclaimed”（責任放棄）状態で起動していることを意味する。
再現コマンドも用意されている。GitHub Issueの調査者が実際に叩いて確認した内容がこれだ。
# 失敗する: Homebrewのsshをdisclaimedで起動した場合
/Applications/Claude.app/Contents/Helpers/disclaimer --pgroup -- /opt/homebrew/bin/ssh -o BatchMode=yes <LANホスト> true
# 成功する: システム標準のsshを使う場合
/Applications/Claude.app/Contents/Helpers/disclaimer --pgroup -- /usr/bin/ssh -o BatchMode=yes <LANホスト> true
# 成功する: disclaimerを経由せず直接叩いた場合
/opt/homebrew/bin/ssh -o BatchMode=yes <LANホスト> true3つとも同じホスト・同じ鍵・同じネットワークに対する接続なのに、disclaimer経由で/opt/homebrew/bin/sshを叩いたときだけ失敗する。ネットワーク経路の問題ではなく、「どのバイナリを」「どういう権限で」起動したかだけが結果を分けている。
なぜHomebrewのsshだと権限が剥がされるのか
macOS（Sequoia以降）は、アプリが他のLAN内マシンへ発信する通信を「ローカルネットワークプライバシー」という仕組みで制御している。ユーザーが一度許可を出したアプリは、システム設定の「プライバシーとセキュリティ→ローカルネットワーク」に登録され、以後は許可済みとして扱われる。
問題は、この許可がアプリ本体（com.anthropic.claude のような署名済みバンドルID）に対して発行される点にある。Claude.appは自分のリモートマシン機能でsshを子プロセスとして起動するとき、そのsshが「システムが管理する、素性のはっきりしたバイナリ」（/usr/bin/sshなど、root所有ディレクトリ配下）であれば、自分に許可されている権限をそのまま貸し出せる。
ところがHomebrewの/opt/homebrewはユーザー所有のディレクトリで、システムから見ると「誰が書き換えたか保証できない場所」になる。ここに置かれたバイナリをClaude.appが直接自分の権限で起動すると、万が一差し替えられていた場合に任意コードへ権限を渡すことになりかねない。そのためmacOSは、この手の非システムバイナリを起動する際にdisclaimerヘルパーを経由させ、「これはClaude.appの権限では動かさない、独立した無署名相当のプロセスとして扱う」という扱いに切り替える。
こうして生まれた”disclaimed”プロセスは、ローカルネットワークプライバシーの観点では「まだ誰からも許可をもらっていない未知のプロセス」だ。しかもこの手のバイナリは実行のたびに再デプロイされる格好になっており、安定したコード識別子を持てないため、通常なら出るはずの「ローカルネットワークへのアクセスを許可しますか」という確認ダイアログすら安定して出せない。結果、macOSはデフォルトの挙動として拒否を返す。これが実測280ミリ秒前後という「一瞬の失敗」の正体で、実際に接続を試みてタイムアウトしたのではなく、OSの権限チェックの時点でEHOSTUNREACH（no route to host）を返している。
一般的な「no route to host」とは原因が違う
「no route to host」自体はmacOSでは決して珍しいエラーではない。macOS Sequoia以降、着信ではなく発信側のローカルネットワーク通信を制限するようになったため、pingやsshがLAN内の別マシンに届かなくなる報告は以前からある。
ただし一般的なケースの多くは、次のような原因で起きている。
- システム設定の「ローカルネットワーク」トグルで、そのアプリ（ターミナルアプリなど）自体の許可がオフになっている
- VPNクライアントやセキュリティソフトがLAN宛の経路を握っていて、ローカル通信までトンネルに巻き込んでいる
- ルーターの「端末分離（クライアント分離）」設定が有効で、Wi-Fi機器同士の通信自体がブロックされている
- 対象ホスト側のsshdが落ちている、ファイアウォールでport 22が閉じている
今回のClaude Desktopのケースがこれらと違うのは、「同じMac・同じネットワークから、ターミナルのsshは成功するのにClaude経由だけ失敗する」という非対称性がある点だ。一般的な原因なら大抵はどのアプリから叩いても同じように失敗するので、まずここで切り分けができる。
自己診断のチェックリストはこうなる。
- ターミナルから同じホストへ
ssh user@hostが通るか → 通るなら、原因はネットワークではなくClaude Desktop側の起動経路 which sshで/opt/homebrew/bin/sshなど/usr/bin以外が返ってくるか → 該当するなら今回のケースに一致する可能性が高い~/Library/Logs/Claude/ssh.logにTCC responsibility disclaimedの行があるか → あれば確定
ターミナルからもsshが通らない場合は、この記事の対象外で、上に挙げた一般的な原因（ローカルネットワーク権限・VPN・ルーターの端末分離）を疑ったほうが早い。
解決策1（推奨・恒久対応）: sshClientPathを明示指定する
Claude Desktopの管理設定で、使用するsshバイナリを明示的に固定できる。/etc/claude-desktop/managed-settings.jsonに以下を追加する。
{
"sshClientPath": "/usr/bin/ssh"
}これでClaude Desktopは常にシステム標準の/usr/bin/sshを使うようになり、PATHの解決順に依存しなくなる。Homebrewのopensshを他の用途（Gitのssh署名やCI関連など）でそのまま使い続けたい場合は、こちらの方法が安全だ。設定ファイルが存在しない場合は新規作成して問題ない。
解決策2（応急処置）: Homebrewのopensshをunlinkする
すぐに直したいだけなら、PATHの解決順を変えてしまう方法もある。
brew unlink opensshこれで/opt/homebrew/bin/sshへのシンボリックリンクが外れ、PATH上は/usr/bin/ssh（macOS標準のLibreSSL版OpenSSH）が優先されるようになる。GitHub Issueの報告でも、この直後の接続試行からTCC responsibility disclaimedがTCC responsibility keptに変わり、即座に接続できるようになったことが確認されている。
ただし副作用がある。Homebrewのopensshを他の理由（新しいOpenSSHの機能を使いたい、特定のcipherスイートが必要、など）でわざわざ入れていた場合、そちらの用途にも影響が出る。一時しのぎとして使い、余裕があるときに解決策1のsshClientPath指定に切り替えるのがおすすめだ。
戻したくなったらいつでもbrew link opensshで元に戻せる。
Claude Codeの他の接続系トラブルとの関係
似た「接続系のはずがOS側の権限で詰まる」パターンは、Windows版のClaude Coworkでも別の形で起きている。あちらはWindows Updateがマウント機構を壊すケースだったが、根っこにある「OSのセキュリティ機構とClaude側のプロセス起動方法が噛み合わずに接続が落ちる」という構図は共通している。
リモートマシン機能自体を初めて触る、あるいはスマホから作業を投げる用途で興味がある場合は、Claude Dispatchの設計もあわせて見ておくと全体像がつかみやすい。
VPS上でSSH経由のワークフローを組んでいる場合、1Password CLIとの組み合わせで別の詰まりどころもある。あわせて確認しておくと安心だ。
FAQ
Claude Code CLI（ターミナルのclaudeコマンド）にも影響する?
このIssueで報告されている症状は、Claude Desktopアプリの「リモートマシン」機能（Codeタブ内のSSH接続設定）に限定されている。ターミナルから直接claudeコマンドを起動している場合や、VS Code拡張のBashツールからsshを叩く場合は、disclaimerヘルパーを経由しないため、同じ原因では失敗しない。実際にGitHub Issueの中でも「同じマシン・同じネットワークで、iTerm2から動かしているclaude CLIは問題なく接続できる」という報告がある。
LinuxやWindowsでも起きる?
コメント欄ではLinux版のClaude Desktop（claude-desktop 1.8555.0-2.0.12）でも類似の症状を報告している人がいるが、原因の中心はmacOSのTCC（ローカルネットワークプライバシー）機構なので、少なくとも今回特定された根本原因はmacOS固有のものだ。Linuxでの類似報告は、別の権限機構（AppArmorやFirejailなどのサンドボックス）が絡んでいる可能性があり、原因を混同しないほうがいい。
システム設定の「ローカルネットワーク」トグルをオフ/オンし直しても直らないのはなぜ?
このIssueの報告者も同じことを試している。disclaimedプロセスは安定したコード識別子を持てず、システム設定の許可リストに正しく登録されないため、トグルの操作自体が効かない。これはUIのバグではなく、「そもそも許可を紐づける相手（安定したバイナリの身元）が存在しない」という構造上の問題なので、トグル操作では解決しない。
まとめ
Claude Desktopのリモートマシン機能で「no route to host」が一瞬で返ってくる場合、まず疑うべきはネットワーク経路ではなくwhich sshの結果だ。Homebrewのopensshが優先されていて、~/Library/Logs/Claude/ssh.logにTCC responsibility disclaimedが出ているなら、今回のケースにほぼ一致する。
恒久対策はmanaged-settings.jsonにsshClientPath: "/usr/bin/ssh"を指定すること、すぐ直したいだけならbrew unlink opensshが応急処置になる。逆にターミナルからのssh接続自体が失敗するなら、この記事の対象外で、ローカルネットワーク権限・VPN・ルーターの端末分離設定など、macOS一般の「no route to host」原因を疑ったほうが早い。
