Rune combines an IDE, terminal multiplexer, and remote workspace
Rune puts editors, terminal panes, tasks, debugging, language intelligence, and a coding agent inside one native application. The organizing unit is a workspace with 9 slots, each able to hold windows, tabs, and terminals. Standard, Vim, and Emacs-style bindings apply beyond the editor to input boxes, terminals, and the file explorer. That consistency is the pitch: fewer seams between writing code and operating the tools around it.
The sharper distinction is remote work. Two signed-in Rune instances can join a private encrypted network, then open a workspace through a rune://machine/path address. Files, shells, tasks, language servers, and the agent execute beside the code on the remote machine. The free account covers 2 machines; more require a paid plan. Rune depends on its coordination service for discovery and NAT traversal, even though the workspace traffic is described as end-to-end encrypted.
Four languages get the deepest support, and 300-plus get syntax tools
Go and Python have supported Tier 1 workflows. Rust and Zig are marked beta, while TypeScript is on the roadmap. Rune's Tier 1 includes language-server support and ecosystem commands; more than 300 downloadable language packages sit at Tier 3 with parsing, highlighting, folding, indentation, and structural search. That is broad file recognition, but it is not the same as a finished IDE workflow for every listed grammar.
This split should decide the trial. A Go developer can evaluate Rune as an IDE. A TypeScript team should evaluate the current editor, terminal, and agent experience without assuming the roadmap item already exists. Language packages prompt before installation by default after onboarding. The project also has an extension system, with official packages and Git repository installs, so the practical question is whether the particular language and tools you use have enough finished integration today.
What happened when we ran it
Our sandbox installed commit 53a9d36 in 157 seconds and reported 785 packages installed. The build completed successfully in 224 seconds. We used an unprivileged golang:1.24-bookworm container with 3 CPUs, 8 GB of RAM, and no secrets. The checkout itself was substantial: 2,614 files, about 749,819 lines of source, and 107.1 MB on disk before that setup.
Tests failed after 494 seconds. Go reported 207 passed and 16 failed out of 223. The supplied log tail shows TestSchemeReportsDisconnect failing in internal/workspace/workspacerune. It also shows TestIntegrationManagerIsWorkspaceFile failing for 2 SSH-style paths in internal/workspace/workspacessh. The tail does not state why those assertions failed, so we cannot label them as container quirks, missing services, or product defects.
The repository had 7 CI workflow files, which is useful evidence that several paths receive automated attention. Our scan found no Dockerfile and no top-level tests directory. Those signals do not cancel the successful build or the 207 passing tests. They do mean the source checkout did not reproduce a completely green result under the clean Debian conditions we used.
Desktop setup has a real graphics and platform boundary
Rune supports macOS 13.3 or newer on Apple Silicon and Intel. Linux requires x86_64 or arm64, glibc 2.28 or newer, and an OpenGL-capable graphical setup with X11 libraries. Wayland desktops use XWayland. Alpine and other musl-based systems are explicitly unsupported, and Windows is absent from the prerequisites. The TUI and headless modes avoid the graphical libraries, which gives server users a narrower path.
The README's one-line installer pipes a downloaded script into a shell. Contributors instead clone the repository and can run go run ./cmd/rune; the contribution guide asks for generation, lint, and tests before a pull request. Headless deployment has a published container command and service recipes for systemd, launchd, OpenRC, and runit. Yet the measured checkout had no Dockerfile, so teams that must audit and rebuild every production image need to investigate the published image separately.
The remote convenience comes with an account and an always-on process
A remote machine is reachable only while Rune runs there. The headless guide recommends a service manager, a stable hostname, and an explicit PATH containing every toolchain the workspace should find. It also says to run the node as the user who owns the projects, since files, terminals, and language servers inherit that account's access. That is sensible operational advice, and it deserves the same care as an SSH service.
Security policy text specifically treats agent permission and sandbox escapes as vulnerabilities. The built-in agent can make model-driven file edits and shell calls under configured permission modes. Rune is GPL-3.0-or-later, accepts DCO-signed contributions, and asks contributors to discuss large behavior changes first. GitHub showed 85 open issues and 17 open pull requests on October 3, 2026, while the repository had been pushed on October 2.
v1.2.1 is active, but the failed suite keeps it in trial territory
Rune reached release v1.2.1 on September 11, one day after the repository's recorded creation date. By October 3 it had 1,224 stars, and recent issue activity included fixes for Vim behavior, terminal selection, Windows path handling, and agent conversation compaction. That pace shows active work. It also describes a young project changing across editor, terminal, network, and agent layers at once.
Try Rune if its single keyboard model and rune:// workspaces solve a problem you feel every day. Keep the pilot narrow: one supported language, 2 machines, and representative local and remote projects. Our build passed, but the 16 failed tests are enough to block a blanket recommendation. Teams happy with separate editor, tmux, SSH, and agent tools give up integration, but they also keep each replacement boundary under their own control.