v0.91.0 — one connection, many clean commands
moshcode ssh keeps one authenticated SSH connection to a box alive and gives every command its own clean channel over it (#485, PRD 0013).
moshcode ssh add dev deploy@example.com --cwd /srv/app # or an alias from ~/.ssh/config
moshcode ssh open dev # authenticate once
moshcode ssh exec dev -- git status --short # …then every command reuses it
moshcode ssh dev # a real shell, same connection
Why
A coding run against a remote workspace is a few hundred small operations: read a file, git status, apply a patch, run the tests. Each one as a fresh ssh user@host cmd pays for a TCP handshake, a key exchange, a host-key check and authentication, every time. OpenSSH has carried the fix for twenty years — ControlMaster keeps one connection and later clients open channels on it through a socket — and ssh is a thin, careful wrapper over exactly that. On a loopback sshd the median command goes from ~96ms to ~12ms; on a real network the handshake is the part that grows.
For an agent
exec runs each command with no PTY, so stdout, stderr and the exit status come back separately and stdin stays raw. Under --json the answer separates two verdicts: ok is the command's, transportOk is ssh's. A grep that finds nothing is { ok: false, transportOk: true, code: 1 } — a fact about the files, not about the network.
git diff | moshcode ssh exec dev --json --stdin --cwd /srv/app -- git apply -
moshcode ssh exec dev --json --timeout 10m -- pnpm test
There is no shell state between calls, on purpose: exec dev -- cd /tmp followed by exec dev -- pwd still answers with the target's directory. A run that performs a hundred operations authenticates once. The same objects come back from moshscript's sshOpen(), sshExec() and sshClose().
When shell state matters
moshcode ssh shell dev --name app puts a shell in tmux on the remote box, where it outlives this terminal, this connection and the laptop lid; shell send, shell read and shell kill drive it without attaching. If tmux is not on the remote box, shell says so and exec keeps working — nothing is installed remotely on your behalf.
What is not stored
~/.moshcode/ssh/targets.json holds a host, a port and a directory. Your ~/.ssh/config, agent, known_hosts, ProxyJump and hardware keys keep working exactly as they do at the prompt; host keys are never auto-accepted, and BatchMode is on only when nobody is at a terminal to answer a prompt. The connection lives behind a socket only you can read, is checked with ssh -O check, closed with ssh -O exit, and a socket the master has gone away from is cleaned up and reopened on the next command.
Also in this release
putandgetcopy single files over the same connection;putlands as a temp file and is renamed into place.moshcode ssh bench <name>measures fresh connections against the shared one on your own host, so the number you quote is the one you measured.- One thing learned the hard way, recorded in the PRD:
-Mtogether with-o ControlMaster=yesputs OpenSSH in ask mode, and every multiplexed request is then refused. The master here is-o ControlMaster=yes -N -f.
Upgrading
moshcode update