unstablebuild/rune: a GPU-accelerated IDE and terminal multiplexer in one binary

The problem rune targets: three tools that do not know about each other

Most terminal-based workflows are assembled from parts. A multiplexer holds the panes, an editor lives inside one of them, a shell history tool remembers commands, and an agent or script runner sits somewhere else, usually with no shared state. Rune's README calls the result of collapsing this stack "a fast, GPU-accelerated, full-featured IDE and terminal multiplexer, suitable both for automatic and manual programming." The audience is narrow and specific: engineers who want their editor and their pane layout to be the same program, and who want an agent to be able to drive that program rather than a shell beside it.

The second problem is remote work. Rune's README states that all Rune instances form an e2e-encrypted network of peers, powered by a headscale network, so you can connect to your workstation from your laptop and the other way round. That is a different answer to remote development than a hosted dev container or an SSH session into a VM: the peer network is the transport, and each machine runs the full editor.

Screen multiplexing, nine workspace slots, and where the agent sits

The organising model is the interesting part. The README describes the UI as "a screen multiplexer that allows you to organize it freely," with nine workspace slots and, in its words, infinite terminals, tabs and windows. Nine slots is a fixed budget, not a preference setting, and that constraint shapes how you work: you allocate slots to projects or contexts and switch between them rather than spawning another window.

Alongside the manual path there is an agent path. The Makefile builds two binaries, rune and rune-agent, described there as "the agent extension binary (bin/rune-agent)." The go.mod file lists the Anthropic and OpenAI Go SDKs, the Model Context Protocol Go SDK, and a rune-go-sdk, so the agent integration is a first-class dependency of the build rather than a shell-out to an external CLI. The README frames the choice as "a built-in agent or IDE-grade skills for yours," which means the agent is optional: you can drive the editor yourself and ignore the agent surface entirely.

Rendering is native. The README states OpenGL on Linux and Metal on macOS, and explicitly "No Electron." That rules out a browser engine in the loop, and it also rules out any platform without one of those two graphics paths.

Installing rune and opening your first workspace

The README gives a single install line for the released build. It pipes a script from rune.build into sh, so read the script first if your environment requires that.

curl -fsSL https://rune.build/install.sh | sh

After that, `rune` should be on your PATH as a native binary. The README does not document an uninstall step or a package-manager route, so removal means deleting the installed binary and any state it wrote.

If you would rather build from source, the README gives the clone command and then a direct Go run. The go.mod declares go 1.26.6, so the toolchain version is not optional.

git clone git@github.com:unstablebuild/rune.git
cd rune
go run ./cmd/rune

The Makefile is the more useful entry point for day-to-day work. `make` builds all binaries into bin/, and the individual targets build one at a time. `make debug` is the one worth knowing early: it builds with the race detector and enables debug-only commands.

make            # build all binaries into bin/
make rune       # the editor (bin/rune)
make rune-agent # the agent extension binary (bin/rune-agent)
make debug      # race detector plus debug-only commands

On macOS, the README documents a bundle target, `make rune-dmg`. The Makefile also names test, lint, format, generate, coverage and the license targets. The README warns that the remaining targets, including dist, release, rune-dmg*, the docker and notarize targets, and the dist targets, drive Unstable Build's internal release and cloud deployment pipelines and are not expected to work outside that environment. Treat the public build path as `make` and `make debug`, not the release machinery.

Plugins come from Git repositories, which is a supply-chain decision

Rune's extension model does not go through a curated registry by default. The README gives this example for installing a community package:

pkg install github.com/unstablebuild/rune-extension-themebuilder

There is also an official package listing at rune.build/packages. The distinction matters. An official package has been through whatever review Unstable Build applies; a community package is fetched from a Git repository and executed inside your editor process. The README does not describe a sandbox, a permission model, or a signature check for community packages, so the trust boundary is the repository you name. For a personal machine that is a reasonable trade. For a shared or regulated environment it is a policy question you have to answer yourself, and the documentation as given does not answer it for you.

Limitations: platform reach, plugin API stability, and a release pipeline you cannot run

The most concrete limitation is platform coverage. The README names OpenGL on Linux and Metal on macOS. There is no Windows graphics path mentioned, and the CI badges cover Linux and macOS only. If your team is on Windows, rune is not a candidate today.

The second is API surface. The go.mod pins rune-go-sdk at v0.2.0, and the README's plugin example points at a community repository. A 0.x SDK is a signal about how much churn to expect in the extension interface, and the README does not make a compatibility promise for third-party packages.

The third is reproducibility of releases. The README states plainly that the dist, release, rune-dmg*, docker and notarize targets are internal. That means you cannot reproduce an official artifact from the public repository with the documented commands; you can build your own binary, but it is not the same build the maintainers ship. For teams with artifact-provenance requirements, that is a real gap rather than a documentation nit.

Finally, the licence. Rune is GPL-3.0 or later. That is fine for internal use and for anyone comfortable with copyleft, and it is a different proposition from a permissively licensed editor if you intend to redistribute a modified build.

How rune differs from tmux plus a terminal editor, and from a browser-based IDE

The obvious alternative is tmux with Neovim or Helix inside it. The difference is not features, it is process topology. In that stack, the multiplexer, the editor and the agent are separate processes communicating through a terminal, and the editor has no idea what a pane is. In rune, the README describes the UI itself as the screen multiplexer, so pane layout, workspaces and editing are one program with one state model. The agent can therefore be a participant in the workspace rather than a subprocess in a pane.

The other alternative is a browser-based IDE on a remote host. That approach centralises compute and gives you a consistent environment from any device with a browser. Rune goes the opposite way: the README says every Rune instance is a peer on an e2e-encrypted network, so each machine runs a full native editor and the network links them. You get native rendering and offline-capable local editing, and you give up the single-source-of-truth server model. If your team's problem is environment drift between machines, a centralised IDE solves it more directly than a peer network does.

Maintenance, upgrade cost, and what GPL-3.0 means in practice

The repository is not archived, and the last push was on 2026-09-16, the day before this was written. Releases v1.2.0 and v1.2.1 landed on 2026-09-10 and 2026-09-11. That is a project in motion, and the practical consequence is upgrade cadence: expect to rebuild from source or re-run the install script rather than sit on one version for a year.

The upgrade cost is concentrated in two places. The Go toolchain requirement in go.mod is go 1.26.6, so a stale local toolchain blocks a source build. And the plugin surface, with a 0.x SDK, is where a version bump is most likely to break third-party extensions rather than the editor itself.

On licensing, GPL-3.0 or any later version applies. Internal use inside a company is the ordinary case for a developer tool. The question to route to your legal team is redistribution: if you ship a modified rune, or bundle it into a product, the copyleft terms travel with it. Nothing in the README suggests a commercial exception, and the sponsorship section describes Unstable Build as a self-funded organisation funded through GitHub Sponsors, not through dual licensing. This is a description of the licence text, not legal advice.

Editorial conclusion

Adopt rune if you already live in a terminal and want the editor, the multiplexer and an agent runtime in one native process, and you accept GPL-3.0 obligations plus a macOS/Linux-only graphics path. Do not adopt it if you need Windows, a stable plugin API, or a release process you can reproduce from the public Makefile: the README states the dist, release, notarize and docker targets drive Unstable Build's internal pipelines and are not expected to work outside that environment. Verify three things before you commit a team: that docs.rune.build lists your language under supported languages, that your platform is covered by the Linux or macOS test workflows, and that your legal team is comfortable with GPL-3.0 for a tool that links into your workflow.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. unstablebuild/rune on GitHub