# OxideTerm: a Rust SSH and remote operations workspace with BYOK AI

> OxideTerm bundles SSH, Mosh, Telnet, serial, RDP/VNC, SFTP and port forwarding into one GPUI-rendered native app, with OxideSens AI running against your own provider. Here is what the repository documents, and where it stops.

**AnalyseDeCircuit/oxideterm** — AI-native workspace for local shells and remote machines.Zero Webview, zero OpenSSL, zero telemetry, and no app subscription.

- Repository: https://github.com/AnalyseDeCircuit/oxideterm
- Website: https://oxideterm.app
- Stars: 1,603 · Forks: 124
- Language: Rust
- License: GPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/analysedecircuit-oxideterm

## The problem OxideTerm targets: one host, too many disconnected tools

Remote work usually happens across a terminal emulator, a separate SFTP client, a port-forwarding utility, an RDP viewer and a browser tab for logs. Each one holds its own connection state. When a link drops, each reconnects on its own schedule, and the shell running a long build dies while the file browser quietly reconnects.

OxideTerm's answer, as the README frames it, is to keep terminal rendering, connection state, reconnect orchestration, files, forwarding, automation and AI context inside one Rust application. The stated goal is that tools share the same server identity and session lifecycle rather than behaving like disconnected utilities. That is a real architectural claim, not a marketing one: the workspace in Cargo.toml is split into crates such as crates/oxideterm-connections, crates/oxideterm-forwarding, crates/oxideterm-gpui-terminal and crates/oxideterm-gpui-remote-desktop, so the session and forwarding state live in shared libraries rather than in per-feature silos.

The audience is narrower than "everyone who uses SSH". The README lists Mosh, Telnet, serial consoles, RDP/VNC and tmux control mode in the same feature table, which points at people who operate fleets of heterogeneous machines: network gear on serial, Linux servers over SSH, Windows hosts over RDP. If you only ever open one SSH session to one box, the surface area here is larger than the problem.

## How the pieces fit: GPUI rendering, an in-process connection pipeline, and manifest-scoped plugins

The README contrasts OxideTerm with a bundled-browser design in a table. Terminal data flow is described as Rust input, then a TerminalState mutation, then a GPUI render. There is no WebSocket hop into a JavaScript event loop and no xterm.js. The interface is drawn with GPUI, the GPU-accelerated UI library from the Zed project, which is why the README can claim zero WebView and no bundled browser runtime.

Connection lifecycle is described as one in-process connection and reconnect pipeline, rather than split across frontend and backend layers. The reconnect behaviour has a name: Grace Period. The README states that Grace Period probes the old connection for 30s before replacing it, so TUI applications can survive short network drops. That is a specific, testable number, and it is the kind of detail most SSH clients do not publish.

The SSH stack itself uses russh plus ring, without OpenSSL or libssh2. Stored credentials go to the OS keychain, and .oxide bundles are described as using ChaCha20-Poly1305 with Argon2id. The plugin story is deliberately constrained: the README describes manifest-only plugins, capability-scoped WASM, and trusted process runtimes, which is a much smaller attack surface than a browser scripting environment, at the cost of expressiveness. The plugin-related crates in Cargo.toml (oxideterm-plugin-manifest, oxideterm-plugin-protocol, oxideterm-plugin-registry, oxideterm-plugin-wasm-runtime, oxideterm-plugin-host-api) match that description.

OxideSens, the AI layer, is BYOK: it uses your OpenAI, Anthropic, Gemini, Ollama or OpenAI-compatible endpoint. The README mentions MCP, local RAG, Agent Skills, provider-aware reasoning controls and approved workspace actions. The crates directory carries oxideterm-ai, oxideterm-ai-tasks, oxideterm-skills, oxideterm-public-mcp and oxideterm-acp-adapter, so the AI path is a first-class part of the workspace rather than a bolted-on chat panel.

## Installing OxideTerm and opening a first SSH session

The repository README does not include a package-manager install line, and the homepage at oxideterm.app is the place the project points to for downloads. What the repository does document is a Rust workspace, so building from source is the path the tree supports. The README carries a Rust 2024 edition badge, and Cargo.toml lists the member crates.

A source build starts from the workspace root. The Justfile at the repository root is the project's task runner; the README does not document its recipes, so read that file before assuming a target name.

```bash
cargo build
```

Expect a long compile. The member list in Cargo.toml runs past fifty crates, including the GPUI UI, editor, IDE, remote desktop and AI layers, so a cold build pulls a large dependency graph.

If a prebuilt binary is what you want, take it from oxideterm.app rather than from the source tree. The README does not document a Homebrew tap, an apt repository, a winget package or a Docker image, so do not assume one exists.

Once the app is running, the README describes the product as needing no account and no signup. Connections, SFTP, Telnet, forwarding, RDP/VNC, local shells, serial terminals and configuration are all listed as working without registration. OxideSens is the only part that needs an external service, and only because it calls your own provider endpoint.

The standalone CLI is a separate binary. The README says it is a standalone binary with direct crate linkage, and that unlike the bundled-browser approach it does not require the desktop app to be running. The corresponding member in Cargo.toml is crates/oxideterm-cli. The README does not publish the CLI's subcommands or flags, so treat the crate source as the reference until that changes.

## Where OxideTerm is the wrong tool

The plugin model is the clearest limitation. The README describes plugins as manifest-only with capability-scoped WASM and trusted process runtimes. That is a deliberate trade-off: you get a smaller runtime boundary, but you do not get to drop arbitrary scripts into the workspace the way you would with a browser-scripted terminal. If your workflow depends on a scripting plugin ecosystem, this design will feel closed.

The CLI is the second gap. The README asserts that a standalone CLI exists and links it to the oxideterm-cli crate, but it does not document commands, flags, exit codes or output formats. Automation built on an undocumented interface is automation that breaks quietly. Until the project publishes CLI documentation, scripting against it is guesswork.

Grace Period is a 30s probe window, per the README. That is long enough for a Wi-Fi handover and short enough that a genuinely dead link is not held open forever, but it is a fixed number rather than something the README presents as tunable. If your environment has reconnect requirements outside that window, the README does not describe a way to change it.

Finally, RDP and VNC support sit behind a helper crate, crates/oxideterm-rdp-helper, and there is a separate crates/oxideterm-pcm-audio for audio. Remote desktop over a helper process is a different reliability profile from a native terminal stream. The README does not describe failure behaviour for the RDP helper, and that silence is worth noting before you standardise on it.

## How OxideTerm differs from Termius

Termius is the comparison most people will reach for, and the search data around this project includes it. The difference is architectural rather than cosmetic.

Termius is a cross-platform client with a hosted account layer at its centre: sync, team features and shared vaults run through the vendor's service. OxideTerm's README states the opposite posture. It requires no account, keeps connections and operational data local, and describes the desktop experience as free with no app subscription. There is a cloud sync crate, crates/oxideterm-gpui-cloud-sync and crates/oxideterm-cloud-sync, and the README mentions encrypted cloud sync and portable .oxide bundles, but that is opt-in rather than the default path to a working session.

The second difference is the runtime. Termius ships an Electron-style application; OxideTerm draws with GPUI and states zero WebView. For an engineer who cares about process count, memory footprint or the presence of a bundled browser engine on a locked-down workstation, that is the deciding factor, not the feature list.

The third is AI. Termius is not positioned as an AI workspace in the README's comparison table. OxideTerm's OxideSens is BYOK, so the model bill goes to your provider account and the README lists OpenAI, Anthropic, Gemini, Ollama and OpenAI-compatible endpoints. If you already run Ollama locally, that combination is the one OxideTerm is built around.

WindTerm and TermCanvas appear in the same search list, but the README gives no basis for a feature-by-feature comparison with either, so this article does not attempt one.

## Licence, upgrade cost and what the repository actually commits to

OxideTerm is GPL-3.0. The repository carries LICENSE, NOTICE, LEGAL.md and THIRD_PARTY_NOTICES.md at the top level, plus a licenses/ directory and a deny.toml for dependency licence checking. If you plan to redistribute a modified build, read those files rather than this article; GPL-3.0 has obligations that a permissive licence does not, and the project has taken the trouble to enumerate third-party terms. Nothing here is legal advice.

The dependency surface is the main upgrade cost. The workspace members in Cargo.toml span terminal emulation, an editor, an IDE layer, RDP, audio, cloud sync, a plugin host and several AI crates. A Rust 2024 edition workspace with that many members means a version bump can move many crates at once. The update path is itself a crate, crates/oxideterm-update, so the project has an in-app update mechanism, but the README does not document its channels, signature policy or rollback behaviour.

Release cadence is visible from the tags. v2.0.26 landed on 2026-09-01, v2.0.27 on 2026-09-06 and v2.0.28 on 2026-09-10. That is three releases in ten days, which tells you the 2.0 line is moving quickly and that pinning a version is more sensible than tracking main. The last push to the repository was on 2026-09-10, and the repository is not archived.

What the project commits to, in the README's own framing, is a desktop experience free of Electron and bundled browser runtimes, with no account required. What it does not commit to in that document is a plugin authoring guide, a documented CLI surface, or a rollback story for updates. Those are the gaps to weigh against the feature list.

## Conclusion

OxideTerm fits engineers who want SSH, SFTP, forwarding and RDP in a single local-first native app and who already pay for an OpenAI, Anthropic, Gemini or Ollama endpoint. It is a poor fit for anyone who needs a documented plugin authoring guide or a stable CLI contract, since the README does not cover either. Before adopting, check the LICENSE and NOTICE files alongside THIRD_PARTY_NOTICES.md, confirm the crate list in Cargo.toml still includes crates/oxideterm-cli, and read the release notes for v2.0.28 to see what changed since the version you plan to pin.

## FAQ

### Does OxideTerm require an account or a subscription?

The README states that OxideTerm requires no account and that the desktop experience is free, with no app subscription. Connections, SFTP, forwarding, RDP/VNC, local shells, serial terminals and configuration work without signup. OxideSens is the exception only in the sense that it calls your own AI provider endpoint.

### Which AI providers can OxideSens use?

The README lists OpenAI, Anthropic, Gemini, Ollama and OpenAI-compatible endpoints, and describes the model as BYOK rather than platform credits. It also mentions MCP, local RAG, Agent Skills and approved workspace actions. The crate list includes crates/oxideterm-ai and crates/oxideterm-public-mcp.

### How do I install OxideTerm on Linux, macOS or Windows?

The README does not give a package-manager command for any of the three platforms and points to oxideterm.app for the app. The repository is a Rust 2024 edition Cargo workspace, so building from source with cargo build from the workspace root is the path the tree supports. The README does not document Homebrew, apt, winget or a Docker image.

### What is Grace Period reconnect in OxideTerm?

The README states that Grace Period probes the old connection for 30s before replacing it, so TUI applications can survive short network drops. It is described as part of the single in-process connection and reconnect pipeline. The README does not present the 30s window as configurable.

## Sources

- [AnalyseDeCircuit/oxideterm on GitHub](https://github.com/AnalyseDeCircuit/oxideterm)
- [License: GPL-3.0](https://github.com/AnalyseDeCircuit/oxideterm/blob/main/LICENSE)
- [Project website](https://oxideterm.app)
- [README](https://github.com/AnalyseDeCircuit/oxideterm/blob/main/README.md)
- [Releases](https://github.com/AnalyseDeCircuit/oxideterm/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/analysedecircuit-oxideterm