[BUG] SSH connection fails with EHOSTUNREACH for hosts on the local subnet (macOS desktop app)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The desktop app's SSH connector cannot reach any host on the Mac's own
directly-attached subnet. It fails instantly with EHOSTUNREACH before
authentication is attempted.

Hosts on a different subnet, reached through the router, connect fine with the
same key in the same dialog. Plain ssh from Terminal on the same Mac reaches
both. So the failure follows link-local delivery, not a specific host, not the
key, and not the network.

Ruled out by testing: the SSH key (the error is at connect stage, and the same
key works from Terminal), routing and ARP (both resolve correctly on en1), the
switch and cabling (Terminal uses the same path), and stale permission state
(the app is listed and enabled under Privacy & Security -> Local Network;
toggling it, a full quit and relaunch, and a full reboot all changed nothing).
A ProxyJump entry in ~/.ssh/config has no effect either -- the connector does
not appear to read that file, despite the dialog hint saying it does.

Practical impact: anyone using this feature to administer machines on their own
LAN cannot connect to them at all.

What Should Happen?

The SSH connection should succeed for hosts on the Mac's own subnet, the same
way it succeeds for hosts reached through the router, and the same way plain
ssh succeeds from Terminal on the same machine with the same key.

If the failure is caused by the macOS Local Network permission, the app should
either request that permission for the process that opens the socket, or report
a clear message saying local network access is required, instead of a bare
EHOSTUNREACH.

Error Messages/Logs

App error (host on the Mac's own subnet, 10.0.1.0/24):

    connect EHOSTUNREACH 10.0.1.97:22 - Local (10.0.1.187:51168)

Same key from Terminal on the same Mac, same moment -- succeeds:

    $ ssh -i ~/.ssh/id_ed25519 user1@10.0.1.97 hostname
    maqllmserver

Host on a different subnet, added in the app with the same key -- succeeds:

    user2@10.0.6.100   OK

Local routing state at the time of the failure:

    $ route -n get 10.0.1.97
    destination: 10.0.1.97
      interface: en1
          flags: <UP,HOST,DONE,LLINFO,WASCLONED,IFSCOPE,IFREF>

    $ arp -n 10.0.1.97
    ? (10.0.1.97) at <redacted> on en1 ifscope [ethernet]

That is the only error string the app surfaces. No further log detail is
exposed in the UI.

Steps to Reproduce

Preconditions: a Mac with a normal LAN address (here 10.0.1.187/24 on Wi-Fi),
an SSH server on another machine in that SAME subnet (10.0.1.97), and an SSH
server on a machine in a DIFFERENT subnet reached via the router (10.0.6.100).
The same private key is authorized on both.

1. Confirm both hosts are reachable from Terminal on that Mac:

ssh -i ~/.ssh/id_ed25519 user1@10.0.1.97 hostname -> returns hostname
ssh -i ~/.ssh/id_ed25519 user2@10.0.6.100 hostname -> returns hostname

1. In the Claude desktop app, open the SSH connection dialog and add:

Name: any
SSH Host: user1@10.0.1.97
SSH Port: empty
Identity File: /Users/<you>/.ssh/id_ed25519
Save, then connect.
-> FAILS immediately: connect EHOSTUNREACH 10.0.1.97:22

1. Add a second connection in the same dialog, same key:

SSH Host: user2@10.0.6.100
Save, then connect.
-> SUCCEEDS.

1. Repeat step 2 against any other host in the Mac's own subnet

(tested: 10.0.1.188).
-> FAILS the same way.

The split is by subnet, not by host: every same-subnet target fails, the
routed target works, and Terminal reaches all of them.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.197 (Claude Code) -- desktop app on macOS (Darwin 27.0.0, Apple Silicon)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_