Desktop app SSH connection feature fails to reach same-subnet hosts (EHOSTUNREACH), while Terminal SSH to the same host succeeds

Description

Desktop app's SSH connection feature (Settings → SSH connections → Add) cannot reach any host on the same subnet as the machine running the app, even though the OS itself (Terminal, ssh in a shell) connects to the same host without any issue at the same moment. Cross-subnet hosts connect fine through the app.

Environment

• App version: 1.46388.4 (50e62f), built 2026-09-05T01:57:47.000Z
• Platform: macOS (Apple Silicon)
• Both the Mac and the target host are on the same /24 subnet, directly connected (no VPN, no extra routing)

Steps to reproduce

1. On a Mac that is directly on subnet 10.0.1.0/24 (e.g. Mac has IP 10.0.1.102), have a reachable SSH host also on 10.0.1.0/24 (e.g. 10.0.1.97).
2. Confirm from a normal Terminal that SSH works: ssh user@10.0.1.97 succeeds instantly.
3. In the desktop app, go to Settings → SSH connections → Add, enter user@10.0.1.97, click "Test connection".

Expected

Connection succeeds, same as the Terminal.

Actual

App reports:

Connection failed: Host unreachable
connect EHOSTUNREACH 10.0.1.97:22 - Local (10.0.1.102:xxxxx)

• This happens for every host we tried on the same /24 as the Mac — not just one machine.
• Testing the Mac's own IP address in the same field (10.0.1.102) gets past the routing check and instead fails on host-key verification (Host key changed or not trusted), confirming the app can open a TCP connection to that specific address — the EHOSTUNREACH is specific to other same-subnet peers, not a total local-network block.
• macOS "Local Network" permission for the app (System Settings → Privacy & Security → Local Network) is already granted.
• Flushing the Mac's ARP cache (sudo arp -d <target-ip>) does not fix it.
• Fully quitting and relaunching the app does not fix it.
• The OS-level route is fine at all times during the failure: route -n get <target-ip> resolves correctly, and ssh from Terminal (bound to either of the Mac's NICs) connects successfully throughout.

Workaround

Forward the target's SSH port to loopback from a Terminal session, then point the app at 127.0.0.1:

ssh -f -N -L 2297:localhost:22 -i ~/.ssh/id_ed25519 user@10.0.1.97

Then in the app, use user@127.0.0.1 port 2297. This works reliably — confirming the app's own network path to same-subnet peers is the broken part, since loopback (not same-subnet) succeeds.

Limitations of the workaround: only covers one host per tunnel/port, and the tunnel drops on Mac sleep/reboot, requiring the user to notice the app can't connect and manually re-establish it.

Suspected cause

Looks like the app's SSH client is using a network path / reachability check (possibly a cached NWConnection/SCNetworkReachability-style state) that treats same-subnet peers differently from loopback or cross-subnet hosts, and this state does not get invalidated by ARP cache flush or app relaunch.