Yazelix Nova: a Nix-packaged popup terminal workspace with Zellij and Helix forks

The problem Yazelix Nova solves, and who it is for

A terminal workspace usually means a pile of tools that each keep their own configuration format. Yazelix Nova is an attempt to ship that pile as one Nix package with one owner per concern. The README names the parts: Nova Rio (a minimal terminal emulator derived from Rio), a Nova Zellij fork, the Nova Helix fork used by default, Yazi, Nushell, Bash, Zsh and Fish with Atuin history, a lazygit popup and an optional coding agent popup. A configurable widget bar covers CPU, RAM and AI usage, alongside cursor effects and terminal animations.

The audience is narrow but specific. You need Nix with flakes enabled, and the README treats Linux as the dogfooded platform. CI builds all packages and a Home Manager activation on aarch64-darwin, and the README states that sustained interactive macOS beta use has found no known regression, while the earlier per-command checklist and the Rio GUI remain unverified. If you live in tmux or Zellij with Helix and Yazi already, this is a packaged version of that habit. If you want a terminal emulator you can install from a distro repository, this is not it.

The project also carries its own history as a design argument. The README compares Nova v1.0.0 with Classic: 23,272 lines of code and configuration against 91,545, and 19,872 lines of Rust against 80,957. The README describes Classic's main repository as product runtime, component control plane, configuration repair system, compatibility layer and maintainer toolbox at once. Nova's answer is firm package boundaries, where each first-party component owns its implementation and contract and Nova pins and composes their outputs. Treat those numbers as the maintainer's own accounting, not an independent measurement.

How the Nova composition works: forks, pins and two entry commands

The architecture is a composition, not a monolith. The repository layout puts Rust code under crates/, Nix expressions in flake.nix and flake.lock, defaults in defaults/, and a runtime/ directory alongside packaging/ and home-manager/. The README describes Nova as pinning and composing the package outputs of first-party components rather than carrying their maintenance machinery. That is the whole ownership model in one sentence: the forks stay separately versioned, and the flake decides which revisions appear together.

Entry is split in two. yzx launch opens the desktop workspace through Rio in a graphical session. yzx enter starts the same workspace in any capable terminal emulator or over SSH. That split matters more than it looks. launch assumes a graphical session and hands the window to Rio; enter assumes only a terminal, which is why the same workspace can be reached on a remote host. The README does not document what happens when launch runs without a display server, so treat that path as unverified.

Channels are part of the mechanism. The stable branch advances from a checked and dogfooded main revision at most once per week. main moves more constantly, an immutable nova-v* tag pins an exact release, and edge is the opt-in experimental dogfood channel. The package identity is visible in the launcher label and inside sessions as NOVA 1.1 STABLE, NOVA 1.1 MAIN or NOVA 1.1 EDGE. Stable uses the default yazelix package while Main and Edge use explicit yazelix-main and yazelix-edge outputs, so the package you installed is the thing that names itself. That is a small detail with real diagnostic value: when a bug report arrives, the label says which channel produced it.

Input is layered rather than remapped wholesale. Yazelix extends the Helix and Vim h/j/k/l motion model into a workspace key grid, where Alt and Ctrl Alt move focus, tabs or panes, and Alt Shift groups four workspace surfaces. Ratconfig, opened with Alt Shift K, is a settings surface with numbered tabs, search across All settings, and a key to remove the selected explicit override. The command palette sits behind Alt Shift M.

Installing Yazelix Nova and running the first five minutes

The README requires Nix with flakes enabled. To try it without installing anything, run the launch command, which opens the packaged Rio window in a graphical session.

nix run github:Yazelix/nova/stable -- launch

On a machine without a graphical session, or over SSH, use the enter subcommand instead. It starts the same workspace in the current terminal.

nix run github:Yazelix/nova/stable -- enter

If the one-off launch fails, the README points at the owned runtime setup rather than the GUI. This command inspects that setup without opening Rio or Zellij.

nix run github:Yazelix/nova/stable -- doctor

For a persistent install, add the flake to a Nix profile and then use the yzx entry point. Note that the profile command does not include the -- launch suffix; yzx is the command you run afterwards.

nix profile add --refresh github:Yazelix/nova/stable
yzx launch

Home Manager users are directed to the Home Manager module documented in docs/installation.md rather than to the profile command. Once inside, the README's first-five-minutes advice is to start the guided tour, then learn the Alt-based grid. yzx help lists every command.

yzx tutor begin

One naming trap: the README's install commands point at the github:Yazelix/nova flake, while the repository you are reading about is luccahuguet/yazelix. The README does not explain the relationship between the two names, so confirm which flake reference your installation actually resolves before filing an issue against either.

Where Yazelix Nova is the wrong tool

The clearest limitation is the platform statement. Linux is the dogfooded platform. macOS appears in CI as a build target and a Home Manager activation on aarch64-darwin, and the README reports no known regression from sustained interactive beta use, but it also says the earlier per-command checklist and the Rio GUI remain unverified. A user who needs a terminal emulator they can trust on macOS today is reading an unverified path, not a supported one.

The second limitation is the cutover itself. The README states that the Nova cutover intentionally replaces the old main history, and that existing Git clones should be replaced with a fresh clone rather than updated with an ordinary pull. Anyone with local branches on an old clone has to plan that migration rather than pull through it. Classic remains on a frozen classic branch, and the immutable v17.12 tag is described as the migration and rollback bridge. The README does not document rollback for Nova itself, only the bridge back to Classic.

Third, the migration bridge is deliberately partial. Classic v17.12 translates mutable Classic settings.jsonc or config.toml files into Nova configuration, and the README says it does not rewrite Home Manager declarations or Home Manager-owned files. If your Classic setup lives in Home Manager, the bridge will not carry it. Home Manager users must replace Classic-only options with Nova's narrow module surface before switching.

Finally, leftovers are reported, not cleaned. After switching, yzx doctor reports recognized Classic configs/ and sessions/ state, generated Nushell extern artifacts, and migration backups in the active Yazelix roots. The README is explicit that these are read-only warnings, that nova=unused means Nova did not load the path while ownership=ambiguous means the contents or owner cannot be proven from the pathname alone, and that Nova does not archive or remove the reported paths. External scripts may still reference them. If you expected a migration tool to tidy up after itself, this one tells you what it found and stops there.

Yazelix Nova versus assembling Zellij, Helix, Yazi and Nushell yourself

The obvious alternative is the manual stack: install Zellij, Helix, Yazi and Nushell from your package manager or from their own release channels, then write the glue that makes them cooperate. The difference is ownership. In the manual stack, you own the versions, the keybindings that connect the tools, and every breakage when one of them changes a config key. Yazelix Nova moves that ownership into a flake that pins first-party forks and composes them, which is exactly the trade the README's Nova-versus-Classic table describes at the project's own scale: one owner per concern instead of overlapping responsibilities.

The cost of that trade is that you inherit the forks. The default editor is the Nova Helix fork, and the multiplexer is a Nova Zellij fork. The README does leave escape hatches: editor.command can select your preferred terminal editor, and the git popup is lazygit by default but other git clients can be configured. So the workspace is not sealed, but the default path runs through code maintained by the Yazelix project rather than upstream.

There is a second difference that matters for anyone already invested in Zellij or Helix configuration. If you have years of keybindings and plugin configuration in upstream tools, adopting Nova means reconciling them with the Nova forks and with the workspace key grid, where Alt and Ctrl Alt layers move focus, tabs and panes. The README documents the grid but does not document a compatibility mode for upstream keybinding files. For a user with a heavily customized setup, the manual stack may cost less than the migration.

Maintenance, channels and what the licence implies

The last push to the repository was on 2026-08-10, and the most recent release is nova-v1.1.0 on the same date, following nova-v1.0.0 on 2026-08-09 and nova-v1.0.0-beta.5 on 2026-08-07. The repository is not archived. That is a burst of releases in early August rather than a long, evenly spaced history, and the README's own channel description is the more useful signal for upgrade cost: stable advances from a checked and dogfooded main revision at most once per week, main updates more constantly, and edge is the experimental channel. Choosing stable buys you a bounded update cadence; choosing main or edge means you are the one testing.

Upgrade cost is mostly Nix's, not Yazelix's. A profile install upgrades through the flake reference, and the README's install command uses --refresh, which is how Nix is told not to reuse a cached flake resolution. Home Manager users pay a different cost: the README describes Nova's module surface as narrow, and Classic-only options must be replaced rather than translated. The README does not document a Nova-to-Nova rollback procedure, only the Classic bridge at the v17.12 tag, so pinning an immutable nova-v* tag is the mechanism the README offers for holding a known release.

The licence is Apache-2.0, which is a permissive licence with an explicit patent grant and requires preservation of notices. That is a statement about the licence identifier in this repository, not legal advice, and it says nothing about the forks: Nova Rio, Nova Zellij and Nova Helix are separate repositories, and the README does not state their licences. If you plan to redistribute a packaged workspace, check each component's licence individually rather than assuming the top-level identifier covers the composition.

Editorial conclusion

Adopt Yazelix Nova if you already run Nix with flakes and want a popup-oriented workspace where each component is a pinned, independently versioned package. Do not adopt it if you cannot enable flakes, if you need a supported macOS GUI path today, or if you want to keep the mutable Classic settings files: the README says Classic v17.12 is the migration and rollback bridge, and Home Manager users must replace Classic-only options before switching. Verify first with yzx doctor, which reports the owned runtime setup without opening Rio or Zellij, and read docs/installation.md before touching a Home Manager configuration.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes