Netcatty: an Electron SSH workspace with a built-in AI agent

The problem Netcatty targets: too many hosts, too many windows

The README frames the audience narrowly: developers, sysadmins and DevOps engineers who manage multiple remote servers. The pain it addresses is not connecting to one machine. It is keeping a fleet legible. Hosts drift into ad-hoc config files, notes and shell history, and the file transfer for a fix usually happens in a different program from the shell where you found the problem.

Netcatty's answer is a workspace model. The vault holds hosts and groups with grid, list and tree views plus search. Terminals open as tabs and split panes, and the README describes session restore for always-on workflows. SFTP sits in the same window with a dual-pane browser, drag and drop, and an editor for in-place changes. The stated goal is that deploy, logs and metrics can share one screen instead of three windows.

The project is explicit about one boundary. It says Netcatty is not a shell replacement: it connects to shells over SSH, Telnet, Mosh or local and serial sessions. That framing matters because it sets expectations. You are adopting a client and an organizer, not a new login environment.

How the pieces fit: Electron shell, xterm.js terminals, a vault, and Catty Agent

The stack is visible in the README and package.json. The app is Electron with React and xterm.js, and the repository is a TypeScript monorepo: npm workspaces cover packages/* and examples/plugins/*, the main process entry is electron/main.cjs, and the renderer is built with Vite. Connection types listed are SSH, local terminal, Telnet, Mosh and Serial, with Mosh and serial qualified as available when the platform supports them.

Catty Agent is the part that distinguishes the product. The README describes it as a built-in AI assistant that understands your servers, executes commands and handles multi-host operations through natural conversation. The documented examples are server diagnostics (run commands, analyze output, summarize) and a Docker Swarm setup across two hosts where the agent performs the init, exchanges tokens and joins nodes. That is a real architectural claim: the agent is wired to the connection layer, not just to a text box.

It is also the part with the least published detail. The README does not document which model or provider backs Catty Agent, whether commands require per-command confirmation, or how credentials are scoped for agent-initiated actions. For anyone whose servers hold production data, those are the questions to answer before the first conversation, not after.

Installing Netcatty and opening a first SSH session

There is no package-manager install line in the README. Distribution is through GitHub Releases, with builds for macOS (universal x64 and arm64), Windows (x64 and arm64) and Linux (x64 and arm64). Download the artifact for your platform and run it.

If you prefer to build from source, package.json sets the engine floor at Node 22 and defines the development scripts. The dev script fetches Mosh binaries, runs lint, then starts Vite and Electron together:

npm install
npm run dev

The Vite dev server runs on port 5173, and the Electron launcher waits for http-get://localhost:5173 before starting with VITE_DEV_SERVER_URL=http://localhost:5173. If you need a clean start because of stale renderer cache, the repository provides a dedicated script:

npm run dev:clean

After launching, create a host in the vault and connect. The README does not spell out the exact dialog fields, so treat the vault entry as the place to record address, credentials and grouping, then open a terminal from that entry. To test the split-pane workflow, open a second session and split horizontally or vertically; the README's example is watching deploy output, logs and metrics side by side. For file work, open the SFTP view for the same host and drag files between panes.

Windows packaging: portable data, Explorer integration, and unsigned builds

The README's Windows notes are the most concrete operational details in the whole document, and they are easy to miss. For the portable build, you exit Netcatty and create a folder named data beside Netcatty.exe or beside the portable launcher. On the next launch the app stores its profile there. Saved passwords and private keys stay bound to the Windows user account that created them, so moving that folder to another computer or another Windows account means re-entering them.

The installed version adds an Open in Netcatty item to Explorer's folder context menu and folder-background menu, opening a local terminal in that folder. On Windows 11 you go through Show more options first. The menu can be toggled in Settings, System, Windows Explorer. ZIP and portable builds do not add it.

Code signing is unresolved. The README states the project is applying to the SignPath Foundation open-source program, and that once approved, covered Windows artifacts will use free code signing provided by SignPath.io with a certificate from SignPath Foundation. Until the application and integration complete, Windows releases may remain unsigned. That is a distribution problem, not a code problem, but it is the first thing an IT department will ask about.

Where Netcatty is the wrong tool

Three cases stand out.

First, headless and scripted environments. Netcatty is an Electron desktop app. There is a bin entry, netcatty-tool-cli, in package.json, but the README does not document it as a general automation surface, and nothing in the documentation suggests you should replace plain ssh, ssh config files or a configuration tool with it. If your workflow is CI jobs, Ansible runs or tmux over ssh from a jump host, this app is not in that path.

Second, minimal-footprint users. An Electron application ships a browser runtime and a Node main process. If you want a terminal that starts in milliseconds on a remote box or a machine with little memory, a native terminal emulator plus ssh is the smaller answer.

Third, the AI agent itself. The README markets multi-host orchestration, but it does not publish the agent's model, its permission model, or an audit trail for commands it runs. On production infrastructure, an assistant that executes commands across hosts without a documented confirmation step is a risk you cannot yet size from the documentation. The honest position is that Catty Agent is worth evaluating on staging first, where a wrong command costs a rebuild rather than an outage.

How Netcatty differs from Termius, WindTerm and a plain terminal

The README positions Netcatty against PuTTY, Termius, SecureCRT and macOS Terminal.app. The meaningful comparison is with Termius, because both aim at the same multi-host user. Termius is a cross-platform client with sync and team features; Netcatty's differentiator in the documentation is the embedded agent and the workspace-first layout, and its distribution is a GPL-3.0 repository rather than a commercial product.

WindTerm is the other useful reference point. It is a native terminal application with a strong emphasis on a single fast terminal core. Netcatty's approach is the opposite: an Electron shell around xterm.js, with the vault, SFTP browser and agent treated as first-class parts of the same window. If your work is one long shell session, WindTerm's model is a closer fit. If your work is ten hosts and a file transfer in the middle of a debugging session, Netcatty's model is the one being optimized for.

Against a plain terminal plus ssh and sftp, the difference is organizational rather than technical. You can do everything Netcatty does with separate tools; the project's bet is that you would rather not.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-08-25, the same day as release v1.1.82. Releases v1.1.81 and v1.1.80 landed on 2026-08-19 and 2026-08-14, so the project is shipping frequently. That cadence is a cost as well as a signal: an Electron app with a Vite renderer and native binary fetches for Mosh and the ET integration has a build pipeline to keep working, and the dev script runs lint before starting, which means a lint failure blocks local development.

The licence is GPL-3.0-or-later, stated in package.json and referenced by the LICENSE file. For individual use this is unremarkable. For a company that wants to fork Netcatty, embed it in a product, or ship a modified internal build, the copyleft terms are the thing to read before writing code, and the repository also carries a CODE_SIGNING_POLICY.md and PRIVACY.md that are worth reading alongside it. Nothing here is legal advice; the point is that GPL-3.0 is a real constraint on redistribution, not a formality.

Upgrade cost is mostly the Windows signing situation. Until the SignPath Foundation application completes, each new Windows release may arrive unsigned, which means the same manual approval step on every update.

Editorial conclusion

Adopt Netcatty if you already keep a fleet of hosts and want a single window for shells, file transfers and the Catty Agent, and you accept GPL-3.0 and an Electron-sized download. Skip it if you need a fully signed installer today, a scriptable CLI as the primary interface, or a terminal that runs without a browser stack. Verify first that a current release for your platform is on GitHub Releases, that your distro and architecture are covered (macOS universal, Windows x64/arm64, Linux x64/arm64), and whether the Windows build you download is still unsigned while the SignPath Foundation application is pending.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes