[BUG] Remote SSH sessions ignore ~/.ssh/config host aliases — Node getaddrinfo runs before invoking ssh

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?

Title: Remote SSH sessions ignore ~/.ssh/config host aliases — Node getaddrinfo runs before invoking ssh

Environment:

Claude Desktop (macOS), Remote SSH session feature
macOS, Apple Silicon
Target: a Linux ARM64 host on the local network
Expected behavior:
The SSH device dialog states the Host field accepts "an entry from ~/.ssh/config". So if I have:

Host remote.example.com 10.0.0.5
HostName myhost.local
User myuser
IdentityFile ~/.ssh/id_remote
then a session configured with myuser@10.0.0.5 should connect to myhost.local (resolved via mDNS) just like ssh myuser@10.0.0.5 does from Terminal.

Actual behavior:
The session fails with:

getaddrinfo ENOTFOUND remote.example.com
This is a Node.js DNS error, indicating the app calls dns.lookup() (which consults only the OS resolver) on the raw host string before invoking ssh. ~/.ssh/config aliases are never consulted, so the redirect doesn't take effect.

Verification:

From Terminal on the same Mac, with the alias in place:
$ ssh myuser@10.0.0.5 'echo OK; hostname'
OK
myhost
✅ ssh respects the alias.
Same host configured in Claude Desktop's SSH device → getaddrinfo ENOTFOUND.
Why this matters:

The dialog hint claims ~/.ssh/config entries are supported, which is misleading.
There is no way to change the host on an existing remote conversation — each conversation is pinned to its original host string. When the network/IP of a remote machine changes, users must either recreate the conversation (losing history) or rely on external workarounds (e.g., keeping a VPN active just to make a hostname resolve).
Suggested fix:
Either:

Skip the in-process getaddrinfo and let ssh handle name resolution (it already respects ~/.ssh/config), or
Use dns.lookup() only as an optional pre-check, falling through to ssh regardless of resolution result, or
Add a UI affordance to edit the host on an existing conversation (this would also solve several reconnection issues).

What Should Happen?

The SSH device dialog states that the Host field accepts "an entry from ~/.ssh/config". Therefore, when the host string matches a Host entry in ~/.ssh/config (by name or IP), the app should connect using the SSH config's resolved HostName, User, IdentityFile, etc., exactly as the system ssh command does.

Concretely: if ~/.ssh/config contains

Host remote.example.com 10.0.0.5
HostName myhost.local
User myuser
IdentityFile ~/.ssh/id_remote
and the user configures a session with host myuser@10.0.0.5 (or remote.example.com), the app should reach myhost.local over SSH — the same behavior as ssh myuser@10.0.0.5 from Terminal, which succeeds.

The app should not perform an in-process DNS lookup (dns.lookup / getaddrinfo) on the raw host string before invoking ssh. Name resolution must be delegated to ssh, which already honors ~/.ssh/config.

Error Messages/Logs

Steps to Reproduce

On a Mac with Claude Desktop installed, add an alias to ~/.ssh/config:
Host remote.example.com 10.0.0.5
HostName myhost.local
User myuser
IdentityFile ~/.ssh/id_remote
(Replace with any host that is reachable via HostName but not via the literal Host string. e.g., myhost.local is reachable over mDNS on the LAN, while 10.0.0.5 is not assigned to any device on the current network.)
Verify the alias works from Terminal:
ssh myuser@10.0.0.5 'echo OK; hostname'
→ expected output:
OK
myhost
In Claude Desktop, open Settings → Remote SSH → Add a new SSH connection and fill in:
Host SSH: myuser@10.0.0.5
Identity file: ~/.ssh/id_remote
Leave port as default.
Save the connection and start a new remote session using it.
Observed: The session fails immediately with:
getaddrinfo ENOTFOUND remote.example.com
(Or ENOTFOUND 10.0.0.5 is treated as an unreachable literal, with no application of the SSH config alias.)
Expected: The session connects successfully, matching the behavior of ssh myuser@10.0.0.5 from Terminal in step 2.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.173 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_