Remote machine SSH connection fails with "No route to host" due to TCC-disclaimed subprocess lacking Local Network permission

Environment

• macOS 26.6.2 (Build 25G83)
• Claude desktop app 1.52386.0
• Target host: local LAN device (private IP, e.g. 192.168.1.18), reachable via ssh from Terminal on the same Mac

Steps to reproduce

1. Add a remote machine in Claude Code settings (user@192.168.1.x, SSH key path set)
2. Click Test connection

Expected: Connection succeeds — the host is reachable and authenticates fine via plain ssh from Terminal on the same machine, using the same key.

Actual: Fails immediately (~280ms) with Connection failed: SSH host unreachable (no route to host).

Root cause (from ~/Library/Logs/Claude/ssh.log)

[info] [OpenSSHConnection] starting master for mediaserver@192.168.1.18 (TCC responsibility disclaimed)
[info] [OpenSSHConnection] master stderr: ssh: connect to host 192.168.1.18 port 22: No route to host
[warn] [OpenSSHConnection] master for mediaserver@192.168.1.18 exited before ready; stderr tail: ssh: connect to host 192.168.1.18 port 22: No route to host
[error] [RemoteServerController] Connection failed (283ms, trigger: warm_up, attempt 1): SSH host unreachable (no route to host)

The spawned ssh subprocess is launched with TCC responsibility disclaimed, so macOS evaluates its Local Network permission independently of the parent "Claude" app's grant. The instant failure (~280ms, not a real network timeout) plus the exact error text match macOS's Local Network Privacy denial (EHOSTUNREACH) for private-range destinations, not an actual routing problem — a plain ssh to the same host/port from Terminal on the same Mac, same network, succeeds immediately.

What I've already tried (none resolved it):

• Confirmed macOS Privacy & Security → Local Network has both a "Claude" entry and a separate lowercase "claude" entry, both toggled on
• Toggled both off and on again
• A fresh "Unknown" Local Network permission prompt appeared once (from a differently-signed/re-deployed subprocess per the app's own [BinaryDeployment] log lines) — clicked Allow, no third entry persists in the Privacy list afterward and the failure is unchanged
• Full macOS restart (confirmed via sysctl kern.boottime) — failure persists identically post-reboot

This suggests the SSH helper binary may be unsigned or ad-hoc-signed and rebuilt/re-deployed per connection attempt (see repeated [BinaryDeployment] Setting up remote server on ... log lines immediately preceding each attempt), so it never gets a stable code identity that TCC can grant Local Network access to persistently.

Also observed: the app continuously auto-retries stale/removed remote-machine profiles in the background (e.g. an old IP for the same host from before a DHCP change) even after they're no longer the active configuration — separate but possibly related cleanup issue.