MeatShell: a Rust and Slint SSH client aimed at FinalShell users who want lower memory

The problem MeatShell targets: FinalShell behaviour without the JVM

The README is explicit about the goal. MeatShell is described as a lightweight, low-memory SSH and terminal client inspired by FinalShell, implemented entirely in Rust and Slint. The stated aim is to keep FinalShell's core experience, meaning the resource monitoring sidebar, session management and multi-tab terminal, while cutting memory use from what the README calls 400 MB+ under a JVM down to native tens of megabytes. That framing tells you who this is for: people who already use FinalShell daily, like the layout, and dislike the runtime cost. It is not pitched at users who want a minimal terminal emulator with no sidebar. The project ships a FinalShell-style UI with dark, light and system-following themes, so the visual continuity is deliberate rather than incidental. If you have never used FinalShell, the appeal here is thinner; the feature list assumes you want remote CPU, memory, swap, network and disk panels next to your shell.

How the SSH stack, terminal emulation and monitoring fit together

The architecture is visible in the dependency table and the Cargo.toml comments. The UI layer is Slint 1.16.1, pinned exactly, compiled from Rust with no garbage collector, and the Cargo.toml comment explains the pin: keeping all desktop platforms on a patched native text layout. Async work runs on tokio. The SSH protocol comes from russh, which the README notes has no libssh dependency, so there is no C library to link against for the transport. System metrics come from sysinfo, shared between local and remote monitoring panels. Serialisation is serde with serde_json, which is what persists sessions to a JSON file.

Two details in Cargo.toml are worth noticing because they show where the friction was. First, icu_provider is pulled in with the logging feature enabled; the comment says ICU4X, which Slint's text layout brings in, otherwise writes raw errors such as a missing segmentation model for Japanese straight to stderr. Enabling logging routes those through the tracing subscriber instead. Second, raw-window-handle 0.6 is a direct dependency for Win11 rounded-corner and shadow DWM tweaks on the frameless window, used only under cfg(windows). That is a narrow, platform-specific use of unsafe-adjacent window handles, and it is confined to Windows by configuration. Terminal emulation is described as full VT/ANSI, with btop, htop and vim rendering correctly in full screen, and colour emoji including skin tones, flags and ZWJ sequences. The emoji glyphs come from Twemoji under CC BY 4.0, with attribution in THIRD_PARTY_NOTICES.md.

Installing MeatShell on Linux, Windows and macOS

The README says every v* tag triggers GitHub Actions to build Windows, Linux and macOS binaries and publish them to the Releases page. On Windows you download the windows-x86_64 zip and run meatshell.exe. On Linux the archive extracts to a directory containing an optional installer script. The README states that the installer places the binary at /usr/local/bin/meatshell, the launcher at /usr/local/share/applications/meatshell.desktop and the icon at /usr/local/share/icons/hicolor/512x512/apps/meatshell.png, and that it cleans up an older user-level launcher with the same name.

tar -xzf meatshell-*-linux-x86_64.tar.gz
cd meatshell-*-linux-x86_64
./meatshell
chmod +x install-linux.sh && ./install-linux.sh

The README states a glibc floor of 2.35, which it maps to Ubuntu 22.04+ and Debian 12+, and notes that on Wayland the icon may require a logout and login after installation. On macOS the zip contains an app bundle rather than a bare binary, and the README is candid that the build is unsigned, so Gatekeeper will report the app as damaged until the quarantine attribute is removed.

unzip meatshell-*-macos-*.zip
mv meatshell.app /Applications/
xattr -dr com.apple.quarantine /Applications/meatshell.app
open /Applications/meatshell.app

macOS 11 Big Sur or later is required, on Apple Silicon and Intel. Building from source needs Rust 1.75 or newer per Cargo.toml, plus the Slint, winit and rfd system development packages; the README lists a single apt command for Linux Mint, Ubuntu and Debian covering build-essential, pkg-config, cmake, fontconfig, freetype, the xcb and xkbcommon libraries, Wayland, Mesa GL and EGL, GTK 3 and libudev. Then `cargo run --release`. The README states that first launch creates an empty session store at the platform-specific path, for example ~/.config/meatshell/sessions.json on Linux, and that you add your first server through the "＋ 新建会话" button.

Scripting sessions with the CLI and MCP server

The CLI and the MCP server share the sessions and the SSH and SFTP implementation that the GUI uses, so there is no second configuration file to maintain. The README requires that you create and connect once in the GUI first, so host key confirmation completes. Session IDs come from the sessions command, and remote commands must follow a double dash.

meatshell cli sessions --json
meatshell cli exec <session-id> -- free -h
meatshell cli exec <session-id> --timeout 60 --json -- journalctl -n 100 --no-pager
meatshell cli files <session-id> /var/log
meatshell cli download <session-id> /tmp/result.txt ./downloads

The README states that downloads require the local target directory to already exist and that existing files are not overwritten. That is a conservative choice: a script that downloads to a directory which has not been created will fail rather than create it, and a repeated download to the same path will not clobber the earlier file. For MCP, you enable it under 设置 → 界面 → MCP, decide whether saved credentials, arbitrary SSH commands and file transfer are permitted, then register a stdio server named meatshell.

{
  "mcpServers": {
    "meatshell": {
      "command": "/absolute/path/to/meatshell",
      "args": ["mcp", "serve"]
    }
  }
}

The README notes that on Windows the command can be C:\\path\\to\\meatshell.exe, and that on macOS the binary lives inside the bundle at /Applications/MeatShell.app/Contents/MacOS/meatshell. It also warns that credentials do not appear in CLI or MCP results and that plaintext passwords should not be placed in prompts or MCP configuration. The permission model is the part to think about: allowing arbitrary SSH commands and file transfer turns an AI client into a remote execution path, and the README puts that decision in the user's hands rather than the protocol's.

Where MeatShell is the wrong tool

The unsigned macOS build is a real adoption barrier, not a cosmetic one. Removing the quarantine attribute is a manual step that the README documents, and there is no mention of notarisation or code signing. In an environment with endpoint protection that flags unsigned bundles, that alone may block deployment. The planned feature list contains exactly one item: moving session passwords to the OS keychain. Today the README states passwords are encrypted with ChaCha20-Poly1305 in the session store, which is better than plaintext but is not the same as delegating to Keychain, Credential Manager or Secret Service, and the encryption key management is not described in the README at all. If your threat model requires OS-managed secrets, MeatShell is not there yet.

The licence situation is also worth stating plainly. Cargo.toml declares MIT OR Apache-2.0, but the repository metadata gives no licence, and the README does not discuss licensing. The dependency versions are pinned tightly in places, with Slint at exactly 1.16.1, which reduces surprise but means upgrades wait on the project. Finally, the README documents no crash recovery, no session restore after an unclean exit, and no rollback procedure for a bad release; it is silent on those points, and you should treat that silence as unverified rather than as a guarantee.

MeatShell against a bare terminal and tmux

The obvious alternative for many readers is not another GUI client but the combination they already have: a terminal emulator plus ssh and tmux. That approach wins on longevity and on scriptability, since everything is a process you can wrap, and it costs nothing in memory beyond the emulator. It loses on exactly the things MeatShell is built around. There is no session manager with grouping and JSON persistence, no import of ~/.ssh/config as a first-class feature, no SFTP panel with drag-and-drop upload, no ZMODEM sz and rz handling inside the terminal, and no remote resource sidebar showing CPU, memory, swap, network and disk next to the shell. Port forwarding exists in plain ssh, but MeatShell exposes local -L, remote -R and dynamic -D SOCKS5 as session settings rather than flags. The trade is therefore not about capability but about where configuration lives: files and flags you compose yourself, or a GUI that stores sessions in one JSON document and can export and import them, including FinalShell connection files. If you already have a working dotfile setup and never wanted a sidebar, MeatShell adds a second place to keep state.

Maintenance cadence, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-16. Releases are frequent and small: v0.7.1 on 2026-08-28, v0.7.2 on 2026-09-04 and v0.7.3 on 2026-09-06, with the Cargo.toml version matching 0.7.3. That cadence suggests a project still filling in features rather than one in maintenance mode, and the single planned item (keychain storage) is a signal about what the author considers unfinished. Upgrading is a binary replacement on Windows and macOS, and on Linux either a fresh tarball or a rerun of install-linux.sh, which the README says also removes a stale user-level launcher. Because sessions live in a JSON file outside the install directory, replacing the binary does not touch them, but the README documents no schema migration path for that file, so back it up before jumping versions. On licence: Cargo.toml states MIT OR Apache-2.0, which is a permissive dual licence typical of Rust projects, but the repository page lists no licence and the README does not mention one. Vendored and third-party assets carry their own terms, and the Twemoji artwork is CC BY 4.0 with attribution required, so redistributing a build means carrying THIRD_PARTY_NOTICES.md with it. That is a description of what the files say, not legal advice.

Editorial conclusion

MeatShell suits engineers who already like the FinalShell layout but want a native Rust binary instead of a JVM, especially those who need scripted SSH through the CLI or MCP tooling for AI clients. It is a poor fit if you need a documented stability policy, a signed macOS build, or OS keychain storage today, since the README lists keychain support as planned and macOS users must strip the quarantine attribute manually. Before adopting it on a work machine, verify two things yourself: that your target OS meets the stated floor (glibc 2.35 or macOS 11), and that the licence terms in Cargo.toml (MIT OR Apache-2.0) match what your organisation expects, because the GitHub repository page does not state a licence.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. yituorou/meatshell on GitHub