# yazi is a 31-crate Rust workspace that calls itself public beta and expects breaking changes > yazi is a terminal file manager written in Rust on non-blocking async I/O, with Lua plugins, a virtual filesystem, and a publish-subscribe layer for sharing state between instances. The build configuration is where the sharp edges sit: two of thirty-one crates are default members, release builds abort on panic while the Windows profile unwinds, and the file calls the project a public beta that expects breaking changes. **sxyazi/yazi** — 💥 Blazing fast terminal file manager written in Rust, based on async I/O. - Repository: https://github.com/sxyazi/yazi - Website: https://yazi-rs.github.io - Stars: 42,445 · Forks: 1,026 - Language: Rust - License: MIT - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/sxyazi-yazi ## 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-09-21, and two tagged releases sit close 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, but the file gives you no changelog policy, no deprecation window and no list of what is allowed to break. ## 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-one 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-one. 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.98.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. So on an ordinary Linux desktop session, 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. Cross-directory selection and multi-tab work sit on the same foundation. 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. The file itself does not connect them to SSH. There is no configuration snippet, no host key note, no mention of authentication, and no line telling you which component you would configure. If you arrived looking for how to run yazi over an SSH session, everything you need is in the crate and in the docs site, and nothing is in the README. 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 docs entry in the file is a single usage link at https://yazi-rs.github.io/docs/installation, which is an installation page, not a remote access page. ## 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. There is a third licensing thread. Yazi gives special thanks to the RustRover team for providing open-source licenses to support maintenance, and says active code contributors can contact sxyazi to get a license if any are still available. 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, and the file does not say which components fall under which. A packager who copies the icon set has to read LICENSE-ICONS separately, and the contributor licence arrangement described in the special thanks section is separate from both. ## 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 protocols 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 a yazi-sftp crate is in the workspace but the file never explains it. 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.98.0. ## FAQ ### What is yazi used for? It is a terminal file manager written in Rust based on non-blocking async I/O, aimed at efficient, user-friendly and customizable file management. It includes multi-tab support, cross-directory selection, a scrollable preview for videos, PDFs, archives, code and directories, bulk rename and create, archive extraction, visual mode, a file chooser, a trash bin and a theme system. ### What is the best terminal file manager for Linux? The README makes no comparison with other file managers. It states that yazi is a terminal file manager written in Rust based on non-blocking async I/O, that all I/O operations are asynchronous and that CPU tasks are spread across multiple threads. For image preview on X11 or Wayland it needs Überzug++ alongside. ### What language is YAZI written in? Rust, with the workspace set to edition 2024 and rust-version 1.98.0. The plugin layer is Lua, described as just some pieces of Lua, and the tree carries stylua.toml and .luarc.json for it alongside rustfmt.toml for the Rust side. ### How do I use Yazi over SSH? The README does not address it. The workspace contains a yazi-sftp crate and the Virtual Filesystem feature covers remote file management with a custom VFS provider, but no SSH configuration appears in the file. The usage documentation is at https://yazi-rs.github.io/docs/installation. ## Sources - [Official documentation](https://yazi-rs.github.io) - [Official README](https://github.com/sxyazi/yazi#readme) - [Project repository](https://github.com/sxyazi/yazi) - [Release notes](https://github.com/sxyazi/yazi/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sxyazi-yazi