uniTerm: A Wails Desktop Client That Puts SSH, RDP, Databases and an AI Agent in One Window

The tab sprawl problem uniTerm is aimed at

Most engineers who touch remote infrastructure end up with a stack of separate clients: one for SSH, one for SFTP, a database GUI, a Kubernetes dashboard, an RDP viewer, and a serial console tool for the occasional switch or embedded board. Each has its own connection list, its own credential store and its own window. uniTerm's pitch is consolidation. The README describes it as a lightweight all-in-one terminal covering SSH, RDP, SFTP, databases, Kubernetes and more, with a connection manager that groups and searches server connections and supports batch operations. The target user is the generalist who moves between a Linux box, a Windows server, a Postgres instance and a container cluster in the same afternoon, and who would rather learn one keybinding set than five. It is not aimed at the specialist who lives inside one protocol and wants that tool to be the best available. The protocol table in the README is the honest summary of scope: terminal, file transfer, remote desktop, database and container categories, each with a list of named protocols.

What the architecture actually is: Vue in Wails, Go drivers underneath

The primary language listed for the repository is Vue, and the topics include wails, xterm and cross-platform. That combination tells you the shape of the thing: a Wails shell wrapping a web front end, with xterm.js providing the terminal emulator surface and Go code handling the protocol work. The README reinforces this in the database section, which says Oracle and SQL Server connections go through pure Go drivers. Pure Go drivers matter for a desktop app because they avoid native client libraries that would have to be shipped or installed per platform. The same logic applies across the protocol list: SSH, Telnet, Mosh, SFTP, FTP, SMB, WebDAV, S3, RDP, VNC and SPICE are all things a Go backend can speak, with the front end rendering panes. The build section points at a project structure with a build directory containing appicon.png, which is the standard Wails layout. Remote desktop support carries a platform caveat in the protocol table: RDP is marked Windows only. That is a real constraint, not a footnote. If you are on macOS or Linux and your main need is Windows Remote Desktop, uniTerm will not cover it.

The AI agent and its four execution modes

The distinguishing feature is the autonomous AI agent. The README states it can plan, execute, observe results and iterate across multiple rounds of shell commands without manual intervention. It connects to Anthropic or OpenAI compatible APIs, so Claude, GPT and other compliant models are options. The part that deserves the most attention is the execution mode list: bypass, dangerous only, dangerous plus write, or confirm all. Read that as a spectrum from no oversight to full oversight. Bypass means the agent runs commands without asking. Confirm all means every command waits for you. The middle two are pattern-based gates, and pattern-based gating of shell commands is inherently approximate: whether a command is classified as dangerous depends on the matcher, and shell syntax has many ways to express the same effect. The README does not describe how the classifier works, so treat the middle modes as a convenience rather than a security boundary. Commands execute in the active terminal tab, and the agent can be pinned to a specific tab or follow whichever tab is active. Chat history persists per session across app restarts. There is also a skills system: reusable skill workflows and prompt-template commands invoked with a slash in the AI input, and the README notes the AI can save new skills itself. That last detail is worth pausing on. An agent that writes its own reusable procedures is convenient and also means the set of things it will do next time is not fixed by you.

Getting it running: download or build with Wails

The README offers two paths. The first is the Download section, which points at the latest GitHub release; the releases list shows v1.9.2 and v1.9.1 as tagged versions alongside a main-snapshot build. If you want a stable artifact, take a tagged release rather than the snapshot. The second path is Build from Source, which is listed as its own section in the table of contents and implies the standard Wails toolchain: Wails CLI, a Go toolchain for the backend, and Node for the Vue front end. The repository layout includes build/appicon.png, which is where Wails expects application icons. Beyond that, the supplied README excerpt does not print the exact build commands, so I cannot give you a verified command line here. Check the Build from Source section in the repository itself before assuming a one-liner. Configuration is done through the UI rather than a documented config file in the material I have: connection manager entries for hosts, cloud sync settings, custom keybindings, and theme selection. Cloud sync is described as encrypting and auto-syncing settings through your own private repository on GitHub, GitLab or Gitee. That is a meaningful design choice because it keeps the sync backend under your control rather than the vendor's, but it also means you are responsible for the repository's access controls.

Where uniTerm is the wrong tool

Three limitations are visible from the material. First, the AI agent's safety model rests on execution modes whose classification logic is undocumented in the README. If your environment has change-control requirements that demand a human approval record for every production command, confirm all is the only mode that satisfies that, and it removes most of the agent's value. Second, breadth has a cost. An application that speaks 30 or more protocols is unlikely to match a dedicated client on any single one. The README lists Oracle and SQL Server through pure Go drivers, which is a reasonable engineering choice for portability, but pure Go database drivers typically trail vendor-native drivers on protocol edge cases and feature coverage. If you depend on an obscure Oracle feature, test it before you migrate your workflow. Third, the release cadence is fast: v1.9.1 and v1.9.2 are five days apart, and a main snapshot was published six days after v1.9.2. Fast cadence is not inherently bad, but it does mean the surface you validated is a moving target, and there is no long-term support branch mentioned. RDP being Windows only is a fourth, simpler constraint.

Compared with a single-protocol client

The obvious alternative is the tool you already have for each job: PuTTY or OpenSSH in a terminal for SSH, FileZilla or the sftp command for transfers, DBeaver or psql for databases, and a vendor RDP client for Windows desktops. The difference in approach is not features, it is the unit of organisation. Single-protocol clients optimise one connection type and typically have no shared connection model, so you maintain credentials and host lists in several places. uniTerm optimises the shared model: one connection manager, one keybinding set, one theme system, one sync target, and split panes that let a terminal and a file browser or database view sit side by side. The trade-off is that you accept a young, broad application instead of several narrow, mature ones, and you accept the AI agent as part of the package rather than as an optional add-on. If you never want an LLM anywhere near your shell, the agent is dead weight you are still carrying in the binary.

Licence, maintenance and what to verify

uniTerm is Apache-2.0. That is a permissive licence: you can use it commercially, modify it and redistribute it, provided you keep the licence and notices intact and state significant changes. It includes an explicit patent grant, which matters if you plan to embed the code in a product. It is not a copyleft licence, so it does not oblige you to publish your modifications. None of this is legal advice; if you are redistributing a modified build inside a company, have counsel read the NOTICE and attribution requirements. On maintenance, the evidence available is the release history: a steady stream of tagged versions through mid-2026 plus snapshot builds, and an active default branch. That tells you the project is being worked on. It does not tell you how long any version will be supported, and the README does not describe a support policy. The practical next step is narrow: install a tagged release, open the AI settings, and read what each execution mode actually gates before you connect it to anything you care about. Then check whether cloud sync is pointed at a repository you control, because that setting decides where your connection metadata lives.

Editorial conclusion

Adopt uniTerm if you want one desktop window for SSH, SFTP, RDP, database and container work, and you are willing to build from source or track a fast-moving release line. Do not adopt it if you need a mature, narrowly scoped tool with a long support horizon, or if you cannot accept an AI agent that executes shell commands under a permission mode you configure. Before committing, check the AI execution mode defaults and the cloud sync repository target, because those two settings decide how much the application can do on your behalf without asking.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. ys-ll/uniterm on GitHub