I built a zero-knowledge SSH client – looking for early feedback

I spent some time reading the repository because the stated threat model is exactly the part SSH users need to be able to audit. The encrypted-backup side looks thoughtfully done, especially the Argon2id floor and storing the KDF parameters with the backup. I did notice a few seams in the host-key flow that are worth tightening:

1. The first-use prompt may be skipped. The background service/modal use the status "new", while both main connection paths wait for "unknown" or "changed". A new host can therefore fall through to the normal connect path instead of stopping for the fingerprint decision. One shared status type across those pieces would prevent that class of mismatch.

2. A stored host appears to be returned as "match" without a fresh scan, but the terminal then starts OpenSSH with strict checking disabled, and the background ssh2 connection does not supply a host verifier. In other words, the accepted fingerprint is not really bound to the key negotiated in the actual handshake. Feeding the accepted key into a temporary known_hosts file with strict checking enabled, and verifying the ssh2 handshake key too, would close a changed-key/TOCTOU gap. Storing keys per host + key type would also help when a server offers several host keys.

3. Legacy algorithm policy is inconsistent: the native path makes it opt-in, while the ssh2 manager always enables some very old key-exchange, cipher, host-key, and MAC options. Making legacy mode an explicit per-server warning/opt-in in both paths would fit the security positioning better.

None of this negates the backup design; these are mostly integration seams between otherwise sensible components. A regression test that changes the server host key after first acceptance and expects the terminal connection to refuse would catch the first two nicely.