Hop from server to server without ever leaving your terminal.

What hop is

hop is a terminal UI over your SSH fleet. It holds one connection per host and opens everything else as extra channels on that same connection: more shells, an SFTP browser, an editor running on the remote box, and any tunnels you defined. Nothing is a new window, nothing re-authenticates, and leaving a pane never tears down what is inside it.

A status bar above the footer always tells you where you are and where your keystrokes are going — the host, the mode, the directory or file, and the machine behind the alias. That is the single most disorienting thing about a TUI that embeds other people’s programs, so it gets permanent screen space, directly above the keys that act on it.

Features

Install

One line, either platform. The script picks the archive for your OS and CPU, verifies its checksum, drops hop on your PATH and prints where it went.

# macOS / Linux -> /usr/local/bin, or ~/.local/bin when that is not writable
      curl -fsSL https://raw.githubusercontent.com/p-arndt/hop/main/scripts/install.sh | sh
      

# Windows -> %LOCALAPPDATA%\Programs\hop, added to your user PATH
      irm https://raw.githubusercontent.com/p-arndt/hop/main/scripts/install.ps1 | iex
      

Both take the same options — a specific release, a directory of your own:

sh scripts/install.sh --version 0.11.0 --dir ~/bin
      

.\scripts\install.ps1 -Version 0.11.0 -Dir C:\tools\bin -NoModifyPath
      

$HOP_INSTALL_DIR / $env:HOP_INSTALL_DIR sets the directory too. On unix the script never edits a shell profile: if the directory is not on your PATH it prints the one line to add. On Windows it appends to the user PATH in the registry unless you pass -NoModifyPath, so a new terminal has hop.

Prefer to do it by hand? Grab the archive from the latest release, unpack it and move the binary onto your PATH. Every release ships a hop_<version>_checksums.txt for sha256sum -c.

From source

Needs Go 1.26+ and optionally just ≥ 1.39.

git clone https://github.com/p-arndt/hop.git && cd hop
      just build          # -> ./hop   (or: go build -o hop .)
      just build-release  # stripped + version-stamped
      just install        # build it, then put it on your PATH
      

just install is the same installer with --from-source / -FromSource: it builds the checkout, stamps it with VERSION and the current commit, and installs it exactly where the downloading path would have.

Updating

hop self-update replaces the binary in place, wherever the installer put it — see Update.

Staying current

hop check-update   # is there a newer release?
      hop self-update    # download it, verify its checksum, swap this binary
      

self-update fetches the archive for your platform from the latest GitHub release, checks its SHA-256 against that release’s checksums.txt, and replaces the running binary atomically. On Windows the old hop.exe is renamed aside and swept up the next time hop starts. Source builds (version = dev) are refused: there is nothing to compare them against.

Quick start

hop            # launch the TUI
      

On a first run with no hosts, hop offers to import ~/.ssh/config for you: one enter and your list is full. Then, in the TUI: ↑/↓ to move, enter to connect, ctrl+o o to come back out. That is the whole model.

CLI

For when you are already in a shell.

Where things live

hop keeps its hosts in an OpenSSH config file of its own and adds a single Include hop.config line to the top of your ~/.ssh/config. Every host you save in hop is therefore a host ssh, scp and rsync can reach by the same alias, and a host you write into ~/.ssh/hop.config by hand shows up in hop. hop rewrites that file when you add, edit or remove a host, so comments inside it are not preserved — hosts you want hop to leave alone belong in ~/.ssh/config itself.

Anything OpenSSH has no keyword for — tags, groups, pin order, how often you connect — is hop’s own preference about a host, so it sits under the hosts key of config.json alongside the rest of your settings, out of ~/.ssh entirely. Losing that key costs your pins and ordering, never a host.

A missing or malformed config file starts hop on defaults rather than refusing to start.

Upgrading from a version that kept its hosts in SQLite? The first start converts <config dir>/hop/hop.db into the files above and leaves the database behind as hop.db.bak. Nothing deletes it.

The three modes

Every mode returns to the sidebar — a double esc inside 400 ms from any pane, the browser or an editor, or ctrl+o o behind the leader. The cursor lands on where you were, and esc in the sidebar goes straight back there. esc never quits hop: q or ctrl+c in the sidebar does.

One row along the bottom says where you are and what to press. On the left, the crumb names the place — the host, the tab, and the thing it is at: the directory a shell is standing in, the file an editor tab holds, the listing the browser shows. A message such as connected takes that side for the few seconds it is up. On the right is the key legend, and it is deliberately short: it names the keys the mode cannot be worked without, adds more as the window gets wider, and leaves the full table to ? (the key card), which opens on the section for the mode you are in.

Nothing here has to be memorised first. space opens the action menu on the host under the cursor and ctrl+k the palette for whatever mode you are in — both list what is possible and the key that does it, and how much hop keeps on screen without being asked is one setting (see Guidance).

Everything else works in all of them: the sidebar beside every tab, the settings popover, the tunnels, the mouse and the optional vim keys.

Two rules explain most of the keyboard:

• In a pane and in the browser, ctrl+o is hop’s leader. It does nothing on its own and it is on no clock — it opens a menu in the footer and waits. ctrl+o o goes to the sidebar.
• Inside a pane, everything else is the remote’s. hop reserves as few keys as it can, because every one it takes is one the shell or editor no longer gets.

Navigation mode

Navigation — the sidebar

esc never quits: a second one straight after the first is the same esc, and with no host in front there is nowhere to go back to, so it does nothing.

With vim keys on, j/k move, l opens a host out as → does, and h folds it up as ← does.

Navigation mode

Import — the SSH config card

i opens the import card, a modal like the rest: one field, pre-filled with ~/.ssh/config, so the usual answer is a single enter.

The first run opens this card by itself: with no hosts yet and a ~/.ssh/config on disk, hop offers the import instead of showing an empty list. esc skips it — an empty list is not an error, and a adds a host by hand.

It stays bound once the list is full, because importing is a sync, not a one-time step: each host is upserted, so a re-import refreshes what the config knows (hostname, user, port, identity file, LocalForward/RemoteForward, ProxyCommand/ProxyJump) and leaves hosts hop added itself untouched. Wildcard patterns (Host *) are skipped. hop import [path] does exactly the same thing.

Navigation mode

Host keys and authentication

An unknown host key aborts the dial and shows a fingerprint card. y trusts it and retries, appending it to your usual ~/.ssh/known_hosts; n or esc trusts nothing. A mismatch — a key that changed on a host you already know — is always a hard error, never a prompt.

When the host asks for a password or a one-time code, a card opens by itself: enter submits or moves to the next question, tab/shift+tab move between fields, ctrl+u clears, and esc cancels the connect. The dial waits inside the handshake rather than restarting, because a one-time code is only good once — and you are asked once per host, since shells, SFTP, editors and tunnels all ride that one connection. Nothing is stored.

Terminal mode

Terminal — a live shell on a remote host

Several shells on one host

S in the sidebar, or ctrl+o 0 from inside the pane, opens another shell on a host you are already connected to. It is a second channel on the connection hop already holds — no new handshake, no second authentication — and it appears as another tab under its host in the sidebar. The new shell arrives focused, at the full size of the content area, the same as the first.

Type exit to close a shell: its tab goes away, the rest keep running. When the last one exits, the connection is done and the host goes back to idle in the sidebar — unless its SFTP browser, an editor tab or a tunnel is still open on it, which keeps the connection alive. d still tears down the whole host at once.

The cursor

The pane draws the cursor itself — the emulator hands hop cells, not a cursor — and draws the one the remote asked for: a block, an underline or a bar (DECSCUSR, what vim switches between as you enter and leave insert mode), and no cursor at all while the program has it hidden (DECTCEM), the way a full-screen program hides it while it paints. A bar has no half-cell to stand in, so it is drawn as the thinnest glyph there is in place of the character; a full reset, and a program leaving the alternate screen, put the block back rather than leaving its shape behind.

Blinking is the one part that is yours: it is a clock hop has to run, so it is off until , → Cursor blink asks for it, and even then a cursor the remote asked to stand still does.

Terminal mode

The leader — ctrl+o

ctrl+o inside a pane has no effect of its own, and no timeout. It opens the leader, the footer becomes the menu, and hop waits as long as you take:

f and c follow the directory the shell reports as you cd. A shell that has not reported one (a login shell hop could not hook, or one still starting) leaves f opening the browser where it would anyway, and the status line says so.

A key that names no chord is swallowed, not passed to the remote: while the leader is open hop has the keyboard, and a program that received the tail of an abandoned chord would act on a key you were not typing at it. The leader also outranks ctrl+g, which is otherwise held in every mode.

Getting back to anything. ctrl+o space raises go to over whatever you are in. With nothing typed it is a tree: every open host with what is open on it under it — each shell tab with its directory, the browser, each editor tab by path, the terminal panel, its tunnels — numbered as ctrl+o 1 … 9 count them, then the hosts with nothing open. The cursor starts on the place you were in before this one, so ctrl+o space enter goes back there. Typing flattens it into one list, most recently used first, narrowed by host, path or name the way / narrows the sidebar. enter lands exactly on the row: that shell tab, that file, the panel. A host row lands where you last were on that host, connects one that has no session, and reconnects one that dropped; esc closes the card and changes nothing. ctrl+o tab is alt-tab for hosts: it goes back to the host you were on before this one, on the tab you left it on, and a second press comes back. ctrl+o → and ctrl+o ← step along the open hosts in the sidebar’s order. The file browser opens go to with p.

Terminal mode

Scrolling back through history

shift+↑ pauses the live shell and steps one line up into its scrollback; shift+pgup does it a page at a time. Both are deliberately chords a bare shell never sends, and both decline (falling through to the shell) when there is nothing to show: on the alt screen a full-screen program owns its own scrolling. The footer advertises shift+↑ scrollback exactly when the key is live.

Once paused, the keyboard drives the history viewport rather than the remote shell. The status bar says <host> › scrollback, and how far back you are reading is the ⇅ <offset>/<len> chip at its right-hand end.

The wheel enters and drives scrollback too, three lines a notch, and scrolling back down to the live bottom returns you to the shell. It keeps working while you are dragging out a selection: the view scrolls under the pointer and the selection grows with it. On the alt screen, where there is no history to show, a notch is sent on as ↑ / ↓ instead, so a full-screen program scrolls itself.

Terminal mode

How double-esc works, and what it costs

A lone esc is still forwarded to the shell. hop cannot know a second esc is coming without swallowing the first one and waiting out the timer, which would put a 400 ms lag on every esc you press in vim. So the rule is:

Browsing mode

Browsing — the SFTP file browser

With vim keys on the browser keeps the whole motion set (the host list only the step keys): j/k, gg, G, H/M/L, ctrl+d/ctrl+u, ctrl+f, plus l to descend and h to back out.

Anything that needs an answer — a name to rename to, a local path to upload, a yes before an overwrite — asks on the status line, and while the question is up every key is its answer: a , typed into a filename is a comma, not the settings popover. enter answers, esc cancels, ctrl+u clears the line.

Marks and the target

Every file operation is plural. space marks the entry and steps down, so a run of files is marked by holding it; a takes the whole directory. With nothing marked, an operation falls back to the entry under the cursor, which is why the single-file keys above still read the way they always did. Marks are keyed by absolute path and survive a refresh, so one inside a collapsed directory is still marked — the footer always names the total, so it cannot quietly follow you around.

Copying and moving need somewhere to go, and that somewhere is the target: t pins the directory under the cursor, the tree draws it in green, and c and v send the marked entries there. Nothing is ever typed as a path, and both ends stay on screen — that is what the tree column buys that a single listing could not.

Both ask before they destroy anything, as d and u already do: a name already taken in the target is a confirmed overwrite for c — the question names the files, since one answer covers all of them — and for v a refusal, because a move cannot clear the way without a recursive remote delete, so it says so before it starts rather than failing halfway through the batch. Anything in the selection that already lives in the target is simply skipped, and the outcome says how many, so a count short of what you marked explains itself.

A batch stops at the first failure and says where it stopped: delete b: permission denied — 1 of 4 done, 2 skipped. The marks stay up, so the same keystroke retries what is left.

Transfers run off the UI, so a large file no longer freezes the browser — the status line becomes a progress line until it lands, counting 3/7 · name.txt through a batch. Deleting asks first, and so does overwriting a file that is already in your download directory.

The browser is the files tab. Where the window has room for the sidebar, the tree lives there, in a box under the hosts, and the content area beside it previews the file under the cursor — the first 64 KiB of it, read on demand, with directories, binaries and anything larger described rather than read. On an editor tab the same tree box stays under the hosts beside the open file, and tab and ctrl+o t pass the keyboard between the two. Below 94 columns there is no docked sidebar, and the files tab draws the tree across the content area instead.

Browsing mode

Editing — editor tabs

enter on a file opens it in an editor inside hop, in the content area, with its path above it. The tree stays on screen in the sidebar, under the hosts, and every open file is a tab under its host there.

How it works

The editor runs on the remote host, not locally: hop opens a second SSH channel on the connection it already has and runs ${EDITOR:-vi} <file> on a pty, then renders that pty in a pane exactly as it renders a remote shell. There is no download and no copy — you are editing the real file, and :w writes straight back to the server.

If the remote $EDITOR is unset (it usually is over SSH, since the rc-file that sets it is never sourced for a non-interactive command), hop probes the remote PATH for nvim, vim, vi, then nano, falling back to vi — POSIX requires it to exist.

Tabs are independent editor processes, so leaving with a double esc keeps them all running: come back and every file is where you left it, cursor included.

Two files side by side

\ in the browser opens the file beside the current one instead of behind it, splitting the content area into two halves, each with its file’s path above it. tab/ctrl+o t pass the keyboard between tree and content; shift+→/shift+← cycle the tabs of whichever half has it. The same file is never shown in both halves — asking for one that is already open just focuses the half it is in. A content area too narrow to give each half a readable 22 columns declines the split rather than drawing two unreadable ones.

ctrl+\ folds the split back to one box, keeping whichever file the half you were in was showing — it is the counterpart to \, and it closes the split, not the file: every tab stays open and every editor keeps running. Closing the last tab in a half folds the split back too, but that is the long way round.

Editing locally instead

o is the escape hatch for files a terminal editor is no good for — a PDF, an image. It downloads the file to a scratch directory under the system temp dir and hands that copy to the desktop (start on Windows, open on macOS, xdg-open elsewhere), returning immediately so hop stays usable. Unlike enter, this edits a local copy: nothing is written back to the remote host. d downloads without opening anything.

Every mode

Actions — the menu and the palette

Two keys reach everything hop can do without knowing a single binding, and both of them show the key beside every line — so using them is how you stop needing them.

The menu is also a right-click on a host: the click stands the cursor on it and opens the menu in one gesture.

The menu is about the thing under the cursor. It lists only what that host can take right now — connect on an idle host, back to where you were on a live one, reconnect and reopen on one whose connection dropped, unpin it on a pinned one. ↑/↓ move, enter runs, esc closes and decides nothing.

The palette is about the mode you are in. In the host list it holds the host’s actions and then hop’s own; in the file browser it holds the browser’s; in a shell or an editor tab it holds the chords behind the leader — which is the keyboard hardest to remember, and so the one it is worth most for. Type to narrow it: the search matches the label and the key, so a half-remembered ctrl+g finds the mouse toggle just as sft finds the browser.

Guidance — how much hop keeps on screen

The first time hop starts it asks one question: how much of its keyboard to keep on screen. Three answers, and every key works in all three — the profile changes what is shown, never what a key does.

hybrid is the default, and the one an escape from that first question picks. Change it any time with , → Guidance. An install that already had a config file is never asked: it keeps working exactly as it did, on hybrid.

Every mode

Tunnels — port forwarding

Forwards are defined per host and ride the connection hop already holds, so a tunnel costs no extra handshake and no second authentication.

A definition is a direction (local or remote), a bind address and port, and the host and port to reach on the far side. LocalForward and RemoteForward lines are picked up by the SSH config import, so the forwards you already have keep working. Editing a running definition stops the old one on save, and a reconnect puts the set that was running back up.

The sidebar shows ⇄ 2 tunnels under a host that has two up, and enter on that line opens its manager.

Every mode

When a connection drops

Drops are found with keepalive probes rather than silence, so a suspended laptop or a dead VPN does not leave a pane quietly frozen.

The pane keeps the last screen the host drew, under a banner saying what happened, so the command that was running is still there to read. Nothing is forwarded to the far end, because there is no far end.

Shell tabs, the browser’s directory and the running tunnels come back on reconnect. Editor tabs do not — an editor holds a buffer, and reopening the file on a fresh pty would look like nothing was lost — and the status says how many were left behind.

Every mode

The sidebar and the content area

hop’s screen is at most two columns: the sidebar on the left and the content area beside it, with one row of footer under both. There is no header.

The sidebar is the host list. Every host is in it, pinned ones first. The host in front — the one the content area shows — is opened out (▾): under it are its tabs in the order you opened them, $ app for a shell by the directory it stands in, ▤ files for the SFTP browser, ✎ nginx.conf for each open file, then ⇄ 2 tunnels if it has any. The tab the content area shows is bold, with a bar (▌) while the keyboard is in it. Other connected hosts are folded up (▸) with a green dot and how many tabs they hold; a dropped one has a red dot; a host with nothing open is dim, with a hollow one.

What the content area shows is decided by the tab in front:

• a shell tab — that shell, the whole content area.
• an editor tab — the open file, with the terminal panel under it if you asked for one. The file tree sits in the sidebar, in a box of its own under the hosts.
• the files tab — the same tree box in the sidebar, and in the content area a preview of the file under the tree’s cursor.

A double esc from a shell, an editor, the tree or the panel puts the keyboard in the sidebar, with the cursor on the tab you were in. ↑ ↓ walk hosts and tabs alike, enter goes there — a tab exactly, a host back to where you were on it, connecting first if it is not — → opens a host out and ← folds it up. esc gives the keyboard back with nothing changed; a double esc there does the same, and esc never quits hop (q does). ctrl+o o is the same trip from inside a pane, sending nothing to the remote. Every host key works on a host row: / to filter, e to edit, S for another shell, t for its tunnels, space for its menu. Clicking a tab row goes to that tab, and clicking an open host goes to it.

With no host in front — when hop starts, or after the one in front was closed — the content area lists the recent places across every host, which ↑ from the first host reaches and enter lands on, then the details of the host under the cursor: how to reach it, what is open on it, and which of those was the last place.

The files have a terminal panel under them, the way an IDE keeps one under its editor: ` in the tree or ctrl+o j shows it and moves into it, the same key inside it puts it away. S on an entry puts the panel in that directory — a running panel is told to cd there, so its history stays. Drag its top edge to resize it. From the keyboard, + and - in the tree size it directly; from the panel or an editor, ctrl+o + or ctrl+o - starts sizing, and + - ↑ ↓ keep going until any other key. It starts at a bit under half the height. It is a shell of its own, not one of the host’s shell tabs, so neither ever resizes the other.

ctrl+o t is the tree’s key: from a file it puts the keyboard in the tree box, from the tree it hides the box, and hidden it brings it back with the keyboard in it. The hosts box takes what its rows need, up to 40% of the height, so the tree always keeps a usable one.

A narrow window — under 94 columns — has no room for the sidebar beside the content. There the sidebar is off screen until a double esc, and then floats over the content rather than pushing it aside. The files tab draws its tree across the content area, and an editor tab is the file alone.

Hiding it. ctrl+o b — or shift+b in the sidebar — gives the sidebar’s width to the content in a window that has room for both, and the same key docks it again. Hidden, it behaves as it does in a narrow window: a double esc floats it over the content, and esc puts it away. Hiding and docking resize the panes once, because you asked; nothing else ever does.

Every mode

Settings — the popover

, opens the settings card, floating over whatever is on screen. It works from the host list, from a pane and from the file browser. It is modal: while it is up, keys go to it.

Key	Action
↑ ↓ (k j)	move between settings
← → (h l)	pick a colour (accent), walk a profile, or flip a switch
enter i	edit the selected setting — or flip it, if it is a switch
enter esc ctrl+u	while editing: save / cancel / clear
r	reset the setting to its default
esc q ,	close

Every mode

The mouse

Every gesture is an existing binding reached by pointing, so nothing is mouse-only.

A selection is not limited to the screenful it started on: while the button is down the wheel scrolls the view under it and the selection grows, and a drag held against the top or bottom row of the pane scrolls by itself until you let go. A selection also rides the text it was made on, so scrolling leaves the highlight over the same words. Anything you type takes it down.

A remote program that asks for the mouse (vim with set mouse=a, htop) gets the pointer verbatim instead, so a drag in vim becomes a visual selection that copies nothing. Hold shift as you press to select with hop instead — the first plain drag says so on the status line. The cards are keyboard-only. ctrl+g hands mouse reporting back to your terminal for a moment — for a selection spanning the sidebar and a pane, or anything else that wants your terminal’s own pointer.

Every mode

The rest of the keyboard

Copy and paste

Paste has no key of its own: paste the way your terminal pastes, and hop marks it as a paste for the remote program — which is what stops vim indenting a pasted block into a staircase. It works on Windows too.

Copying out of a pane is a drag (the mouse), or your terminal’s own selection after ctrl+g. A yank on the remote host travels to your clipboard over OSC 52, unless you turn Remote clipboard off. nvim asks the terminal whether it takes OSC 52 before it uses it, and hop says yes, so "+y in a remote nvim lands on your clipboard with no config; plain vim needs its osc52 package. A remote asking to read your clipboard is never answered.

What hop takes from the remote

The full list, so there are no surprises: ctrl+o, ctrl+g, shift+←/shift+→, shift+↑, shift+pgup, and the first esc of a double. Everything else reaches the program on the other end.

One cost worth naming: shift+←/shift+→ no longer reaches the remote as a selection motion. A remote tmux does get its ctrl+b prefix.

macOS and the alt keys

hop’s own bindings are ctrl and shift chords, which every terminal sends — nothing below is needed to use hop.

The alt+… aliases are another matter. On macOS, Option+letter types a character (ø, é, ∑) instead of sending the ESC-prefixed meta key hop reads, so every alt+… binding is simply absent until the terminal is told otherwise:

• Terminal.app — Settings → Profiles → Keyboard → Use Option as Meta key
• iTerm2 — Settings → Profiles → Keys → Left Option key: Esc+
• Ghostty — macos-option-as-alt = true
• VS Code’s terminal — "terminal.integrated.macOptionIsMeta": true

This is also why shift+k/shift+j reorder pinned hosts, why the mouse toggle is ctrl+g, and why the tree is ctrl+o t from an editor rather than alt+t alone.

Every mode

Vim keys

Off until you turn them on, in the settings popover (, → Vim keys). Off, they are not bound to anything else either: a stray l in the sidebar does nothing at all. pgdn/pgup are not part of the switch — they page without being vim, so turning vim off never costs you a way to page.

Every mode

The cards

All of them are modal: while a card is up it takes every key, and esc closes it.

The keys card opens on the section for the mode you are in — the shell’s keys from a shell, the browser’s from the browser — and marks it you are here. That is what lets the footer stay short: it names the two or three keys a mode cannot be worked without and leaves the rest to this card, which is only a fair trade if the card starts where you are.

? reaches it from every mode hop owns the keyboard in. In a shell or an editor a bare ? is a question mark the remote is owed, so there it is ctrl+o ? — the same key, one level in.

The host form carries more than an address: a group, a default directory every session on that host starts in, an identity file, and ProxyCommand / ProxyJump for hosts you reach through a bastion. Renaming the alias keeps the host’s visit history, so it does not lose its place in the frecency order.

Development

just            # list recipes
      just run list   # go run . list
      just build      # dev binary
      just install    # build from source onto your PATH (scripts/install.sh|.ps1)
      just test       # go test ./...
      just test-e2e   # + the Docker 2FA end-to-end tests (needs Docker)
      just vet
      just fmt        # gofmt -w .
      just ci         # fmt-check + vet + test (what CI runs)
      just docs       # regenerate index.html, README.md and KEYBINDINGS.md from docs/
      just demo       # re-record assets/demo.gif + the stills (needs vhs)
      

just release          # patch bump: stamps VERSION, commits, tags, pushes
      just release minor    # or major, or an explicit 1.0.0
      

Where a binding lives

The host list and the file browser move on the same keys, so they do not each spell that keyboard out. internal/keymap holds it: one table, one row per key, saying what the key means (a Motion), whether the vim setting owns it, and whether the host list binds it as well as the browser. Both views resolve keys through it — passing keymap.Full or keymap.List — and act on the motion they get back.

A mode with no motions of its own — the settings popover — asks keymap.Vim(key) instead, the same table answering the narrower question: is this a key the vim setting owns? That is why turning the setting off is one fact in the config rather than a flag threaded through three switch statements.

Roadmap

Shipped: embedded shells · multi-shell tabs · SFTP browser · remote editor tabs · scrollback · tunnels · ProxyCommand/ProxyJump · 2FA · reconnect · mouse · copy and paste · host management · host-key confirmation · SSH config import · live settings · uploads and file ops · async transfers · cross-platform releases.

Next up:

The living version, with far more detail on each item, is TODO.md.