limux: a GPU terminal workspace manager built on Ghostty's engine

What limux is, and where the rendering comes from

limux is a GPU-accelerated terminal workspace manager for Linux, powered by Ghostty's rendering engine, and the README gives a special thanks to the cmux contributors who inspired the build. It also says that if you are on a Mac you should visit the cmux repository to download the original, which places limux in a family of projects rather than presenting it as something from scratch.

The feature list is where the scope becomes clear.

The terminals are GPU-rendered via embedded Ghostty using OpenGL, so the terminal itself is not a text grid drawn by a terminal emulator but the Ghostty engine running inside the application.

Workspaces have folder-based naming, persist across restarts, and are managed from a sidebar. Workspace autostart commands can be configured directly from the workspace menu. Split panes work horizontally and vertically with keyboard navigation, and there are tabbed terminals within each pane.

There is a built-in browser on WebKitGTK, which is the feature that separates this from a plain multiplexer. A right-click context menu offers copy, paste, split and clear. Workspaces can be reordered by drag and drop, with favourites and pinning. And the sidebar collapses and expands with animation.

The licensing is MIT, the last push was on 2026-10-20, and the releases are v0.1.33 on 2026-10-19, v0.1.32 on 2026-10-13 and v0.1.31 on 2026-10-03, which is a rate of roughly one release a week at a version below 1.0.

The project is written in Rust, and it also carries a skills/ directory and a hooks/ directory alongside the code, which suggests it is set up for agent-driven development as well as human development.

Four install routes, and the AppImage detail that bites on older systems

The install section offers four ways in, and each suits a different situation.

The recommended one for Debian and Ubuntu is the deb package:

sudo dpkg -i ./limux_*_amd64.deb

The AppImage is the portable route, needing no install:

chmod +x Limux-*-x86_64.AppImage
./Limux-*-x86_64.AppImage

There is a tarball for a manual install:

tar xzf limux-*-linux-x86_64.tar.gz
cd limux-*-linux-x86_64
sudo ./install.sh

And for Arch there are two AUR packages, a prebuilt one and a source one:

# Prebuilt release package
yay -S limux-bin

# Build Limux and Ghostty from source
yay -S limux

Both AUR packages are published from this repository, and the original Arch packaging is credited to Anton Barchukov in a pull request. Uninstallation is handled by apt remove for the deb and an uninstall flag on the install script for the tarball.

The AppImage paragraph is where the real information is, and it is unusually candid. Release AppImages are built and checked on the Ubuntu 24.04 GLIBC_2.39 floor, and they bundle Limux, Ghostty resources, WebKitGTK helper processes and AppImage-only loader modules such as the gdk-pixbuf SVG loader. But they still use the host GTK4 and libadwaita runtime, so older distributions may need the deb, the tarball or a source build with matching system packages instead.

That is a real limitation of the AppImage approach as documented, and the project states it rather than letting you discover it.

The FUSE handling is a nice piece of engineering. The embedded AppImage type-2 runtime statically includes FUSE 3, so the AppImage does not need a host libfuse.so.2 or libfuse.so.3, and it works with versioned FUSE 3 helpers such as fusermount3 while keeping support for the traditional fusermount. The launcher also discovers host GBM and DRI driver directories, which lets the Ubuntu-built bundle use Mesa correctly on Fedora and Arch family systems.

And there is a subtlety about library scoping that matters more than it looks. AppImage runtime library paths are scoped to the Limux app process, and terminals spawned inside Limux restore the original library and loader environment, so host tools such as Flatpak do not load AppImage-private libraries first.

System dependencies, and the Wayland clipboard problem

The runtime dependencies are a short list, and on Ubuntu and Debian they are:

sudo apt install libgtk-4-1 libadwaita-1-0 libwebkitgtk-6.0-4

That is the whole set, GTK4, libadwaita and WebKitGTK, which corresponds exactly to the three rendering stacks the application uses: GTK4 for the shell, libadwaita for the widget styling and WebKitGTK for the built-in browser.

On Wayland there is one more, and the explanation of it is the most practically useful paragraph in the README. You also need wl-clipboard, installed with apt, dnf or pacman depending on the distribution.

The reason is that Limux has two different paste behaviours. Ctrl+Shift+V is Limux's own paste, but plain Ctrl+V goes to the program running in the terminal, and some programs read the clipboard themselves, fish's Ctrl+V for example. Without wl-paste, they fall back to X11 tools like xclip, and depending on the compositor the X11 clipboard may not have what you copied in Limux. The result is that Ctrl+V pastes something older than Ctrl+Shift+V.

That is a well-known Wayland problem, but it is usually described in the abstract. Here it is tied to a specific pair of key bindings in a specific terminal multiplexer, which is the level at which you can actually act on it.

The practical upshot is that on Wayland you want wl-clipboard installed, and if you are comparing Limux against another terminal, the difference in what Ctrl+V does is worth checking rather than assuming the two are the same.

Building from source, and the provenance rules around the embedded library

The source build needs a Rust toolchain on stable, Zig 0.16.0, the GTK4, libadwaita and WebKitGTK development packages, and an initialised Ghostty submodule.

The sequence is:

# Install dev dependencies (Ubuntu/Debian)
sudo apt install libgtk-4-dev libadwaita-1-dev libwebkitgtk-6.0-dev pkg-config build-essential

# Initialize the Ghostty submodule and build the embedded library
git submodule update --init --recursive
./scripts/build-ghostty.sh

# Build limux
cargo build --release

# Run (point to libghostty-internal.so location)
LD_LIBRARY_PATH=ghostty/zig-out/lib:$LD_LIBRARY_PATH ./target/release/limux

Packaging a release tarball is a single script, and the README explains what it does and what it requires:

./scripts/package.sh

It builds the binary, bundles libghostty-internal.so, the icons and an install script into a tarball, and it uses build-ghostty.sh to rebuild the library with ReleaseFast and a baseline CPU target, so Zig 0.16.0 and an initialised Ghostty submodule must be present.

The provenance system is the most interesting engineering in the README. build-ghostty.sh records the clean Ghostty commit, the library checksum and the resolved library path next to the artifact. The quality gate and the GTK smoke tests reject a missing or stale provenance record before starting Cargo or a display session. And after updating the submodule you must rebuild with build-ghostty.sh, because linking an installed library into the output directory does not establish build provenance.

That is a strict rule, and the reason is worth understanding. If the library can be swapped without the record changing, the record proves nothing. Tying the checksum to the artifact means the test can tell you that you are about to run a binary built against a Ghostty you did not build.

Two environment variables are provided for the build. ZIG selects the path to Zig 0.16.0 and LIMUX_BUILD_JOBS changes the default of four build jobs.

The rest of the development setup is documented in dedicated files: the canonical local quality gate is ./scripts/check.sh, the maintainability rules live in docs/maintainability.md, the contributing guide documents the CPU-only Rust formatting workflow, and the release procedure is in docs/releasing.md. The repository root also carries an AGENTS.md and a CLAUDE.md, plus a .codex file.

Workspace autostart, and how the agent integration fits in

The workspace autostart feature is a small thing that solves an annoying problem, and the implementation detail is what makes it good.

You right-click a workspace in the sidebar and choose Set Autostart to run a command whenever Limux creates a terminal in that workspace. The command is stored as part of the workspace session and runs inside the terminal, so interactive commands such as ssh user@server work without modifying your shell configuration. Open Edit Autostart and save an empty command to disable it.

The mechanism is unusual and deliberate. Limux writes the command to a private, self-deleting /bin/sh script and asks the interactive terminal shell to source it, so changes such as cd and export remain in that shell. It is not injecting keystrokes into the launched program.

That distinction is enforced by a specific condition. Autostart is enabled only when both the command and the initial-command in Ghostty's finalised configuration launch a recognised POSIX-compatible shell with no arguments other than interactive or login flags. Non-shell commands such as a direct path to vim, and non-interactive wrappers such as a shell with a command argument, skip autostart.

The effect is that a workspace autostart is a shell environment setup, not a program to launch. If you want a program, you launch it yourself.

The agent integration section describes how background terminal tabs behave. They show an activity spinner for five seconds after receiving output, including animated titles from tools such as Codex and output in renamed tabs. Viewing a tab clears its activity, and leaving it does not restart the spinner until new output arrives, at which point a notification dot replaces the spinner until the notification is read. Both behaviours are configurable in Settings, General, where you can turn off the tab activity indicators or change the tab activity timeout from 1 to 60 seconds.

This is a nice piece of design attention to detail. A coding agent that runs for a minute in a background tab should be visible without you having to look at it, and the fact that reading the notification is what clears the dot means the indicator cannot be dismissed by accident.

The Rust workspace layout, and what each crate is for

The Cargo.toml defines a six-member workspace, and the crate names explain the architecture better than any prose would.

The members are rust/limux-protocol, rust/limux-core, rust/limux-control, rust/limux-cli, rust/limux-ghostty-sys and rust/limux-host-linux. The resolver is version 2, the workspace edition is 2021, the version is 0.1.33 and the licence is MIT with the authors listed as the limux contributors.

The separation is a sensible reading of the problem. limux-ghostty-sys is the boundary with the embedded C or Zig library, and isolating it means the FFI details stay in one crate. limux-protocol is the wire format between the GUI and whatever is driving the terminals. limux-core holds the session and workspace model. limux-control is the control side, and limux-cli is the command line entry point, which is the piece that lets the same multiplexer be driven from a script rather than a mouse. limux-host-linux is the platform layer, which is where the GTK and Wayland specifics live.

The shared dependency list is short and tells you what the project considers its own dependencies. anyhow and thiserror handle errors, the first for application code and the second for library errors with types. clap with derive is the command line parser, serde and serde_json handle serialisation, tempfile is there for tests, and tokio with the macros, multi-threaded runtime, net, io-util, sync and time features provides the async runtime.

The choice of tokio with those features is a reasonable read of the workload. There is network and IPC involved, the control plane is asynchronous, and a work-stealing runtime fits a multiplexer that is managing many terminals and a browser process at once.

The repository layout supports the picture as well. There is a ghostty/ directory for the submodule and its build output, a rust/ directory for the crates, scripts/ for the build, package and check scripts, docs/ for the maintainability and releasing guides, hooks/ and skills/ directories, a flatpak/ directory for the Flatpak packaging, a .cargo/ directory for cargo configuration, and PKGBUILD templates for the Arch packages.

Editorial conclusion

Adopt limux if you want a terminal workspace manager with GPU rendering and a built-in browser, and you are willing to track a 0.1.x project. Do not adopt it expecting a stable API, since the version line is still in patch releases and the release notes show frequent changes. Before you install, check the libadwaita and WebKitGTK packages on your distribution, because the AppImage still needs the host GTK4 runtime, and if you build from source, follow the Ghostty submodule and build-ghostty.sh steps in order, because the quality gate rejects a missing or stale provenance record.

Frequently asked questions

Official sources

1. am-will/limux on GitHub
2. Issues
3. License: MIT
4. README
5. Releases