SShvTerm
An SSH client that carries its own agent
Hosts, identities, keys, groups, tags, snippets and port-forwarding rules in one desktop client, over a real terminal — xterm.js with GPU-accelerated rendering, tabs and splits of up to four panes, password or key, and automatic reconnection when the network drops.
What it adds to that is an AI agent that operates the terminal: you ask in plain language, it proposes the command, and — once you approve — it types it into the visible session while you watch.
The server holds your hosts and cannot read them
Hosts, identities, keys and snippets sync end to end. The sensitive fields are encrypted on your own machine — AES-256-CBC + HMAC-SHA256 — and the key never leaves it: the sidecar holds it in memory and nothing else does. Install SShvTerm on another machine, sign in, and everything reappears; the server that carried it never saw any of it.
And that server can be yours. The sync backend is a separate, self-hostable piece, so "the cloud" here is a deployment choice rather than a condition of using the product.
It runs commands under a policy you wrote
Every command is allow, ask or deny by your rule. A destructive action asks for confirmation, and nothing runs at all with execution switched off. The agent types into the visible terminal of the tab — you watch every keystroke — and both the conversation and the commands land in the audit log.
Stop interrupts during the call to the provider, not only between steps. Each turn reports its time, its tokens and its cost — the real figure when the provider reports one, marked with ~ when it is an estimate.
Bring your own key: Claude (Anthropic), ShvIA (Blue3), xAI/Grok, local Ollama, LM Studio, vLLM and any OpenAI-compatible endpoint. Where the provider supports tools the model returns a structured call; where it does not, a text bridge extracts the command from a ```run block and runs it down the same guarded path.
What else is in it
SFTP on the open connection
Browse, upload and download reusing the SSH session you already have. A transfer queue with progress, several at once, cancellable while running.
WireGuard VPN per host
Reach servers on private networks through a tunnel scoped to that connection — no root, and no touching the system VPN. If the tunnel does not come up, nothing leaks: it fails closed.
Keys under control
Generate, import and organise Ed25519, ECDSA and RSA keys, and reuse an identity across hosts instead of copying it around.
Visual port forwarding
Local (-L) and remote (-R) tunnels tied to the session, without memorising the flags.
Bring your existing configuration
Import hosts from OpenSSH (~/.ssh/config), PuTTY, MobaXterm and Termius, with a preview before anything is applied.
Snippets and autocomplete
Save the commands you repeat and fire them in any session, with per-host startup snippets. Suggestions as you type, switchable off from the bar when they get in the shell's way.
Windows, macOS and Linux. The installers and the release notes are served from sshvterm.com — this page is the description, not the download.
What changed
The most recent releases, taken from the project's own changelog.
-
v2.0.78 current
- Nothing visible changed, and that is the entry: the five largest files in the app now carry a size ceiling that fails the build when they grow. They had been growing for thirty versions, and the cost was the kind of bug you do see — a fix applied to one path and not to its twin.
-
v2.0.77
- The VPN screens stop stating things they cannot know. A refused WireGuard change now says why instead of the switch snapping back on its own, and a vault it could not read says exactly that rather than printing "no host with VPN configured" — a claim expensive enough to make someone re-import a .conf holding a private key.
- The markdown that renders the agent's replies no longer rewrites the commands it is showing you.
-
v2.0.76
- Secret detection runs on its own; rewriting what it found waits for your click. Finding and changing are two decisions, and only one of them is the app's to make.
-
v2.0.75
- The redaction can be re-run over what is already stored. The earlier fix stopped new leaks and removed none of the old ones, which left the sessions recorded before it exactly as they were.
-
v2.0.74
- The leak at the boundary between two chunks of terminal output was closed in one of the three places that write the session log. The other two write the same log, and now they close it too.
-
v2.0.73
- Six failures that reached you as "unrecognised error" now say what went wrong.