yazi is a 32-crate Rust workspace that calls itself public beta and expects breaking changes

The status section says daily driver and breaking changes in the same breath

Two sentences sit under Project status. The first calls Yazi a public beta that can be used as a daily driver. The second says it is currently in heavy development and expects breaking changes. Neither is hedged and they pull in opposite directions.

The dates around them say the work is real rather than dormant. The last push is 2026-11-02, and two tagged releases sit behind it, v26.9.1 on 2026-09-01 and v26.8.15 on 2026-08-15.

The consequence is a specific kind of risk. A daily driver is a thing you point at your own files, so a breaking change in configuration keys, plugin APIs or preview behaviour lands on you rather than on a sandbox. Treating the first sentence as the promise and the second as the footnote is a reasonable reading.

The nightly release tag is dated 2024-08-07 while the stable tags are dated 2026

The release list mixes two schemes. Alongside v26.9.1 and v26.8.15 there is an entry named nightly, with Nightly Build as its title, dated 2024-08-07. The stable tags beside it are dated 2026-09-01 and 2026-08-15.

The version numbers themselves are date shaped. The workspace version is 26.9.1, matching a 2026-09-01 release, and the previous one is 26.8.15, matching 2026-08-15. So year, month and day are readable straight off the version, which is convenient for ordering tags and useful for pinning.

The consequence sits in the nightly entry. If you subscribe to a nightly channel expecting a rolling build ahead of stable, this record shows a nightly dated more than two years before the newest stable tag. Nothing in the file explains whether that entry is abandoned, renamed, or simply the last time a tag of that name was cut.

Release builds abort on panic and Windows release builds unwind

The release profile sets `panic = "abort"`. The Windows release profile inherits that profile and then overrides exactly one line, setting `panic = "unwind"`. Every other optimization is shared: `codegen-units = 1`, `lto = true` and `strip = true`.

That single difference is easy to skim past and hard to debug. Code that catches a panic, including plugin code, behaves differently on Windows than on macOS and Linux in a shipped build. On the Unix side the process ends at the first panic; on the Windows side the unwind runs. A bug that reproduces on one platform and not the other may be this line and nothing else.

There is a second profile worth knowing, `dev-opt`, which inherits release and then turns the optimizations off: `lto = false`, `codegen-units = 256`, `debug = true`, `incremental = true`, `strip = false`. That is the fast-iteration profile, and it is not a proxy for a shipped binary, because anything depending on cross-crate inlining behaves differently there.

cargo build at the root covers 2 of the 31 workspace crates

The workspace declares `members = [ "yazi-*" ]` and `default-members = [ "yazi-fm", "yazi-cli" ]`. Counting the crate directories at the top level gives thirty-two names beginning with yazi-, including yazi-actor, yazi-adapter, yazi-boot, yazi-core, yazi-dds, yazi-fs, yazi-parser, yazi-plugin, yazi-scheduler, yazi-sftp, yazi-term, yazi-tty, yazi-vfs, yazi-watcher and yazi-widgets.

So a plain build in the root directory touches the file manager and the CLI and nothing else, while building the full graph pulls in all thirty-two. The compile bill lives entirely in that second case, and nothing in the file suggests which one you want.

There is also a toolchain floor to clear before either. The workspace asks for `edition = "2024"` and `rust-version = "1.99.0"`, so a distribution's packaged Rust is a real constraint rather than a formality. The tree also carries flake.nix, flake.lock, a nix/ directory and a .envrc, which is a Nix-flavoured answer to that constraint and not a general one.

The last two rows of the image table need a second program installed

Fourteen terminals are marked built-in, spread across four graphics protocols: kitty unicode placeholders, the old kitty protocol, the iTerm2 inline images protocol, and Sixel. That covers kitty, iTerm2, WezTerm, Konsole, foot, Ghostty, Windows Terminal, st with the Sixel patch, Warp, Tabby, VSCode, Rio, Black Box and Bobcat. Version floors are attached to some of them, including kitty at or above 0.28.0, Windows Terminal at or above v1.22.10352.0 and Rio at or above 0.3.9. Warp is marked macOS and Linux only.

Then the table stops being self contained. The X11 and Wayland row is not built in, it needs Überzug++ required. The Fallback row is ASCII art using Unicode blocks, and it needs Chafa at or above 1.16.0.

In a terminal that is not in the built-in list, image preview is not something yazi does alone. You install and run Überzug++ alongside it, and if that is missing too you drop through to Chafa rendering text art. The file gives you the requirement but not the failure message, and the details sit on a separate image-preview page.

The DDS shares state between instances without a daemon process

The Data Distribution Service is described as built on a client-server architecture with no additional server process required, integrated with a Lua-based publish-subscribe model, achieving cross-instance communication and state persistence. There is a yazi-dds crate for it, alongside yazi-proxy, yazi-runner and yazi-scheduler.

The no-server part is the interesting claim, and it has a shape worth naming. A conventional pub-sub needs something listening; here the instances are the participants and state is persisted through them.

The constraint that comes with it is that the model is Lua based. Anything you want to publish, subscribe to or keep across restarts has to be expressible in Lua, and the plugin system is described as just some pieces of Lua. So the extension surface for shared state is the same small scripting layer the rest of the plugin system uses, not a second language and not a compiled addon.

A yazi-sftp crate sits in the workspace and the file never mentions SSH

The workspace contains yazi-sftp, and the Virtual Filesystem feature is described as covering remote file management, a custom VFS provider, and custom search engines, with yazi-vfs as the crate. Between those two, remote access is clearly a design goal of the project.

Neither the Virtual Filesystem bullet nor the crate name tells you how to configure remote access.

That is a documentation boundary rather than a missing feature, but it is one you hit at exactly the moment it costs you, because remote access is a question people ask once they already trust the tool. The README's Documentation section links Usage at https://yazi-rs.github.io/docs/installation and Features at https://yazi-rs.github.io/features.

The code is MIT but the icons carry their own license file

The tree holds two license files, LICENSE and LICENSE-ICONS, and the workspace package sets `license = "MIT"` while the project is described as MIT-licensed. So the code and the artwork are not on the same terms, and the split is visible in the file names rather than hidden in a single notice.

The consequence is for anyone redistributing. A theme, an icon set, a package or a container image built on this project may pull in both LICENSE and LICENSE-ICONS. A packager who copies the icon set has to read LICENSE-ICONS separately.

Editorial conclusion

Adopt yazi if you want a file manager where every I/O operation is asynchronous and you are willing to learn its own input model, and if your terminal speaks one of the fourteen terminals in its image table. Hold off if you need a stable configuration surface, because the status line pairs being a usable daily driver with expecting breaking changes, and if you need SSH, because remote access belongs to the Virtual Filesystem feature (a yazi-sftp crate is in the workspace) and you should confirm SSH setup in the docs first. Before you install anything, check three things: that your terminal is new enough (kitty at or above 0.28.0, Windows Terminal at or above v1.22.10352.0, Rio at or above 0.3.9), whether your X11 or Wayland session needs Überzug++ or Chafa installed alongside, and which toolchain you have, since the workspace asks for edition 2024 and rust-version 1.99.0.

Frequently asked questions

Official sources

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