[BUG] Desktop SSH remote: client never sends publickey signature after "Postponed publickey" (regression in 1.21459.3; system OpenSSH with identical key/host works)

Summary

After updating Claude Code Desktop to 1.21459.3 (e0f338), all SSH remote sessions to a Linux VPS stopped working. Nothing on my side changed — same host, same user, same key file, same settings that worked immediately before the update.

Symptom in the app: it reports "connected" and then nothing happens. Re-saving the connection settings produces ECONNRESET.

Server-side sshd DEBUG3 logging pinpoints the failure: the client offers the public key, the server confirms the key is authorized and requests the signature (Postponed publickey), and the client never sends that signature. Authentication never completes — no session, no channel is ever opened.

Environment

• Claude Code Desktop 1.21459.3 (e0f338), Windows (MSIX package)
• Remote: Debian 13, OpenSSH_10.0p2 Debian-7+deb13u4
• Auth: ed25519 private key, unencrypted, correctly present in ~/.ssh/authorized_keys
• Connection settings (unchanged, worked before the update): user@host, port 22, identity file = that ed25519 key

Evidence — server-side sshd (LogLevel DEBUG3)

Every connection attempt from the app ends the same way:

debug1: /home/<user>/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
Accepted key ED25519 SHA256:<redacted> found at /home/<user>/.ssh/authorized_keys:1
Postponed publickey for <user> from <client-ip> port XXXXX ssh2 [preauth]
Connection reset by authenticating user <user> <client-ip> port XXXXX [preauth]

The server acknowledges the key as authorized and asks for the signature. The client never sends it. There is no Accepted publickey, no session opened, no channel/exec request — the app never gets far enough to do anything on the remote.

Control test (rules out key, user, host, DNS, and server)

From the same Windows machine, using the same key file, same user, same host, the system OpenSSH client authenticates and works normally:

debug1: Connecting to <host> [<ip>] port 22.
debug1: Remote protocol version 2.0, remote software version OpenSSH_10.0p2 Debian-7+deb13u4
debug1: kex: algorithm: mlkem768x25519-sha256
debug1: Authenticated to <host> ([<ip>]:22) using "publickey".

So key file, file permissions, username, hostname resolution and the SSH server are all verified good. Only the app's bundled ssh2 path fails.

Additional finding 1 — the app ignores the configured identity file

The app offers multiple keys instead of only the configured one:

Accepted key ED25519 SHA256:<keyA> found at /home/<user>/.ssh/authorized_keys:1
Accepted key ED25519 SHA256:<keyB> found at /home/<user>/.ssh/authorized_keys:2

With the server default MaxAuthTries 3 this burns authentication attempts. On servers running fail2ban this results in the client IP being banned, which then surfaces as timeouts instead of resets — a confusing secondary symptom that sends users down the wrong debugging path.

Additional finding 2 — ssh2 cannot negotiate the OpenSSH 10 default (post-quantum) KEX

Before the above was even reachable, the app's connections were reset during key exchange. OpenSSH 10 leads with mlkem768x25519-sha256. Only after forcing the server to classic algorithms:

KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256

did the app get past the handshake — to the Postponed publickey stage described above, where it then fails anyway. The system OpenSSH client negotiates mlkem768x25519-sha256 against the same server without any issue.

Implication: against a default OpenSSH 10 server the app cannot connect at all, and users are forced to downgrade their server's key exchange — giving up post-quantum protection for every client on that host — just to reach the authentication stage.

Impact

A previously working remote-development feature became unusable after an app update, with zero configuration change on the user side. The only workaround is to abandon the app's SSH remote feature and use a plain terminal SSH session instead.

Expected behaviour

The app authenticates with the configured ed25519 identity (as it did before 1.21459.3) and opens the remote session. It should also honour the configured identity file rather than probing every available key, and support the OpenSSH 10 default key exchange.