ConchshellHow Conchshell stores credentials and verifies host keys
What the vault does, what it refuses to do, and where the boundary sits. The format is documented down to the byte.
The vault
Data is sealed with XChaCha20-Poly1305. The key that seals it is derived with Argon2id from your master passphrase, and every unlock method — passphrase, OS keychain, recovery code — gets its own key slot wrapping the same data key. Adding or revoking a method rewrites one slot; the vault itself is never re-encrypted.
The interface can create a credential and delete a credential. It cannot read one back. Not because reading is blocked, but because no command exists that would answer that question.
Route binding
A stored credential is bound to the full route it was saved for: host, port, user, proxy chain and jump host. Change any of them and the credential is not offered — the connection asks you instead. A window that has been tampered with cannot walk a saved password to a different server, because the vault will not hand it over for a route it was not saved for.
Host keys
First connections and changed keys are confirmed in a dialog drawn by the operating system, outside the application's own surface. The application cannot repaint that dialog, cannot click it, and cannot make a key replacement look like a first connection. This is the one prompt worth reading carefully, so it is the one prompt the application does not draw.