RSSH: an SSH client that treats a session as a stack of command blocks

Every command becomes a block you can fold and search

The central idea of RSSH is that a shell session should not be an endless scrollback buffer. Traditional clients hand you a shell and stop there, and the README's complaint is specific: endless scrollback, static IPs to memorise, and copy pasting logs into a chat bot.

Against that, RSSH renders every command and its output as a block with a colour coded left edge, so the last command's output can be spotted at a glance. The blocks are foldable, and the terminal itself does xterm emulation with 10,000 lines of scrollback, regex highlighting and search. The README is explicit that the rendering happens fully locally, with zero remote dependency, which is the point: the structure is drawn on the client, not on the machine you are connected to.

This is a rendering decision with a real consequence. If the blocks are drawn locally, a remote host that is slow or half broken still gets a usable client, because the client is not asking the server to render anything. The same local rendering also means the structure survives the terminal's own scrolling model, which is the usual reason scrollback becomes unreadable in a long debugging session.

The feature list adds a multi session workbench on desktop, with live terminal previews and selection aware broadcast across connected sessions, and session recording in asciicast v2 format with variable speed playback. That combination, blocks plus recording, is what makes a session reviewable rather than merely re-runnable.

Discovery replaces the IP address you had to memorise

The second half of the complaint about traditional clients is static IPs. RSSH answers that with dynamic discovery: it discovers Docker containers and running Kubernetes pods through local CLI contexts, then opens ephemeral exec terminals on them.

The mechanism is worth understanding because it determines the requirements. Discovery goes through local CLI contexts, which means the tool uses the Docker and Kubernetes command line tools and the contexts you have already configured, rather than talking to a cluster API with its own credentials. The consequence is that discovery only shows you what your local CLI can already see. A container on a remote host that your Docker context does not point at will not appear.

The payoff is that a dev or test environment with churn, containers and pods that come and go by the minute, becomes navigable without a spreadsheet of addresses. Each discovered target opens an exec terminal rather than a fixed login, so the session follows the container's current state.

The same feature list also covers serial console access on desktop, with saved UART profiles, text and hex modes, flow control, login scripts and DTR/RTS/break handling. That is a different job from SSH, aimed at embedded and device work, and it is one of the places where RSSH reaches beyond the SSH client category into a broader remote access tool.

The AI panel reads the terminal and asks before it acts

The AI feature is described in the README as triage, and the framing matters: not another chat box. Nothing has to be installed on your servers, and it works like a human operator, reading the terminal's input and output directly.

That design has two consequences. First, the model reads the same text a person would read, so it does not need an agent installed on the remote host, and it cannot act on the host except by proposing a command. Second, the command still travels through the normal session, so the same block rendering, the same history and the same recording apply to it.

The approval step is explicit. The project's own image caption describes the flow as ask a question, the AI proposes commands, you approve before they run. That is the right shape for a tool that can turn a question into a command on a production host, and it is the difference between this and the workflow the README criticises, where you copy logs into a chat bot and paste the answer back into a terminal.

The related feature here is snippets, reusable command shortcuts bound to Cmd+E. Combined with the AI panel, the client gives you two ways to avoid typing: a saved command for the things you already know, and a proposal for the things you do not.

What the README does not say is anything about model configuration, which provider is used, what is sent off the device, or whether a self hosted model can be pointed at. For a tool whose selling point is reading your terminal contents, those are the questions to ask before installing it on a machine with access to production.

A Tauri shell, a Svelte front end and a Rust core

The repository layout shows how the application is put together. src-tauri/ holds the Rust side, src/ the front end, idea-plugin/ the JetBrains integration, and there are per platform build scripts at the root named build-mac.sh, build-linux.sh, build-android.sh and build-ios.sh.

The front end is Svelte on Vite, with TypeScript, and the package manifest is small enough to read at a glance:

  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview",
    "tauri": "tauri",
    "test": "vitest run",
    "test:watch": "vitest"
  },

The terminal itself is xterm.js with the addons for fit, image support, search, Unicode 11, web links and WebGL, which together cover resizing, inline images, searching inside scrollback and text rendering. CodeMirror 6 with the One Dark theme and legacy modes handles the syntax highlighting for the code oriented parts of the interface, and dompurify and marked are present for handling rendered markdown, which is how a model's answer or a log snippet gets displayed safely.

Tauri 2 provides the desktop shell, with the api and the dialog and filesystem plugins as dependencies. The Rust crate underneath is what the repository's primary language tag refers to, and it is the part that talks SSH, SFTP and the serial port.

Testing is set up with Vitest, with vitest.config.ts at the root and a run script alongside a watch script. There is also an AGENTS.md file at the root, which usually holds instructions for coding agents working in the repository.

Keys in the OS keychain, profiles in your own GitHub repo

Connection management is where SSH clients usually make uncomfortable compromises, and RSSH makes its position explicit. Keys stay in your local OS keyserver, and connection configs are encrypted into your own private GitHub repo, so nothing sits on a third party server. Secrets are encrypted locally with ChaCha20-Poly1305, the master key lives in the platform keychain when one is available, and there is selective remote sync plus encrypted backup to your own GitHub repo or a WebDAV server.

Connections and credentials are stored in SQLite, and the client can import from ~/.ssh/config, which is the detail that matters for anyone moving an existing fleet of hosts across: the hosts you already have configured can be brought in rather than retyped.

Authentication covers the usual set: password, private key, SSH agent or Pageant, keyboard-interactive, and jump host through ProxyJump. Telnet is supported too, with saved profiles, echo negotiation, line controls and expect/send login scripts, which is a legacy reach that most modern clients have dropped and that some infrastructure still needs.

For file transfer there is a remote file browser with upload and download, and for networking there is port forwarding covering local, remote and dynamic SOCKS5, with named configs and real time statistics.

The shared data store is the piece that ties the platforms together. The desktop app, the mobile app, the CLI and the JetBrains plugin all read the same hosts, keys and settings from a shared ~/.rssh directory. That is also the design decision with the largest blast radius: the same directory holds the SQLite database and the credentials, so every surface you install the client on becomes a reader of that store.

Where to get it, and what each artifact is

There is no package manager route in the README. Installation is by download from the releases page, and the artifacts are built per platform. For macOS there are two disk images, one for Apple Silicon and one for Intel. Linux comes in three formats: a deb for Debian and Ubuntu, an rpm for Fedora and RHEL, and an AppImage for any distro. Windows has an msi for silent install with msiexec /i, a setup.exe GUI installer, and a portable zip that carries both the GUI and the CLI. Android has an arm64 apk for 64 bit phones and a universal apk for all ABIs including emulators. iOS is distributed through the App Store by a third party contributor rather than by the project.

The JetBrains integration is a separate set of artifacts. Each zip bundles a headless rssh-server, so the plugin is self contained, and there is a per OS zip for macOS Apple Silicon, macOS Intel, Linux and Windows. The install path runs through Settings, then Plugins, then the gear menu, then Install Plugin from Disk, after which you pick the zip for your OS and restart the IDE. The RSSH tool window opens at the bottom, and the close button in its title bar stops the embedded server.

The mobile app is not a thin shell either. It carries a virtual keybar with Ctrl, Alt, arrows, Tab and Esc, safe area handling and stack navigation, because a phone keyboard cannot type a control sequence.

Version 0.x, and the difference from a traditional client

The scope is wide, the version is not. The recent releases are v0.3.1 from 2026-09-07, v0.2.19 from 2026-08-29 and v0.2.18 from 2026-08-27, and the last push was on 2026-10-19. A 0.x version with release tags a few weeks apart is a project in active development, not a settled tool, and the pace of changes in the tag names suggests the interface is still moving.

The alternative is not a competitor product but a different way of working. OpenSSH plus your own terminal emulator gives you a session and nothing else, and the README names that as the thing being replaced. The second alternative the README calls out is a chat workflow, where you paste terminal output into an AI chat and paste the suggested command back. RSSH folds that loop into the client, which removes the paste steps and keeps the command in the session history as a block you can see and record.

The third alternative is the JetBrains plugin versus the plain terminal inside the IDE, and here the plugin is the differentiator rather than the replacement. It gives you the same hosts, keys and settings as the desktop app from a tool window, so the choice is whether the SSH session needs to be visible outside the IDE at all.

The licence is MIT, and the repository carries the standard MIT LICENSE file. There is a Chinese README, a roadmap.md file at the root, a CONTRIBUTING.md for changes, and an article in the documentation repository explaining the reasoning behind the project, which is where the depth sits if the README feels like a feature list.

Editorial conclusion

RSSH suits an operator who works across many hosts and container targets and wants one shared profile store on desktop, phone and inside a JetBrains IDE, and who is willing to review every command an AI panel proposes. It does not suit someone who needs a stable, scripted, unattended connection, since the project is at version v0.3.1 with a release history of a handful of tags, and it does not suit a team that requires audited, reproducible client builds or refuses to store connection profiles in a personal GitHub repository. Verify first by installing the package for your platform from the releases page and confirming that your SSH authentication method, whether key, agent or Pageant, works through the interface you actually use.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. rssh-org/rssh on GitHub