menyoki and the command line screencast that grew into an image toolkit

A screencast tool that outgrew terminal windows

menyoki is described as a screencast and screenshot utility that can also perform various image related operations such as making and splitting GIFs and modifying, analyzing and viewing image files. The stated aim is to be a lightweight command line tool for either helping out on day-to-day life operations or complicated detail-centric issues.

The origin story is in the same paragraph, and it explains the shape of the tool. Originally it was designed to record or screenshot terminal windows, and it can be tweaked easily for other purposes with command line arguments, environment variables, or a configuration file.

That origin is still visible in the command set. The table of contents in the documentation lists the general actions alongside record, split, make, capture, edit, analyze and view, with an "Other" section that groups format-specific work for GIF and APNG, PNG, JPG, WEBP and PNM, plus a save action. A general mode sits alongside the specific ones, which is how a tool designed around one use case ends up with a general fallback.

The repository is Rust, GPL-3.0 licensed, with the homepage at menyoki.cli.rs. The last push was on 2026-08-29 and the most recent release is v1.8.0, tagged the same day. Before that there is a long gap, with v1.7.0 from 2023-03-01 and v1.6.1 from 2022-07-17, so the project ships rarely and ships big.

The repository layout matches a polished Rust command line project: a src directory, a completions directory for shell completions, a man directory for the manual pages, a config directory, a Cargo.toml and Cargo.lock, a Dockerfile, a CHANGELOG and a RELEASE file, plus an IMPLEMENTATION.md that the platform support section links to for people implementing the tool for other platforms.

Record and capture need a window system, the rest does not

The platform support table is where the honest limits of the tool appear, and it is worth reading carefully before you install it anywhere.

Linux is the supported platform. X11 is marked as fully supported. Wayland is supported for output record and capture, and for window on Hyprland, which is a narrower statement than it first appears. Windows and macOS are both listed with no record or capture.

The explanation follows immediately. menyoki requires a window system implementation of the supported platform for record and capture actions, and other features are expected to work normally since they do not require a window system running, or a window to grab. The documentation gives the concrete example: despite macOS not being listed as a supported platform, menyoki can still perform image operations such as edit, analyze and view if it is compiled on macOS.

So the split is clean. Recording and capturing are display server work, and they are Linux only, with the Wayland window path tied to Hyprland. Everything that operates on a file you already have is portable, and the format list, which is long, applies wherever you can compile the binary.

That Hyprland qualifier is the detail to notice. A Wayland session on GNOME or KDE will not get the same window capture behaviour, and the project points at an IMPLEMENTATION.md for anyone adding support for another platform, which reads as an invitation to contribute a backend rather than a closed door.

The format list is long, and the gaps are named

Supported formats are listed as a checklist, and the tool is broadly capable of reading and writing images. GIF, APNG, PNG, JPEG, BMP, ICO, TIFF, PNM, TGA, farbfeld, OpenEXR and WebP are all marked as supported. AVIF and MP4 are marked as not supported.

That list is longer than most command line image tools manage, and it comes from the underlying Rust image crate configuration. The Cargo.toml pins the image crate with an explicit feature list that includes bmp, exr, ff, gif, ico, jpeg, png, pnm, rayon, tga, tiff and webp, and the dependencies section adds separate pins for webp, png, and the optional imgref and rgb crates.

The optional crates are worth pausing on because they explain the build flags. The features section of the manifest sets default to a feature called ski, which enables the gifski encoder and pulls in the rgb and imgref crates. There is a second optional feature, sixel, which enables viewing sixel images through the viuer crate.

The gifski encoder is the reason the default feature set exists. Producing a good animated GIF is not something every encoder does well, and gifski is a purpose-built one. Since it is on by default, the standard build includes an animated GIF encoder without any flags, which explains why the make and split commands work on GIFs out of the box.

The sixel feature is off by default, which is the right default for a feature that only matters if your terminal supports sixel graphics.

Installing through cargo, a package manager or a container

The requirements are modest and stated up front. Rust 1.88 or newer is needed, and the manifest pins rust-version to 1.88 with edition 2021. The native dependencies are only needed for the X11 backend, since the Wayland one is pure Rust. For X11 the libraries are libx11 and libxrandr, packaged as libx11-dev and librust-x11-dev plus libxrandr-dev on Debian and Ubuntu, libX11-devel and libXrandr on Fedora, and libx11 and libxrandr on Arch Linux.

Installing from crates.io with cargo is the shortest path:

cargo install menyoki

And to update an existing installation the documentation says to use the force option:

cargo install menyoki --force

Arch Linux users have two routes, the extra repository and an AUR package:

pacman -S menyoki

There is a container image as well, and the README links a Docker Hub repository. The Dockerfile in the repository shows what goes into it, and the multi-stage shape is the interesting part. A cargo-chef planner stage computes the dependency recipe, a builder stage compiles with cargo build --release --locked, and the runner stage is debian:bookworm-slim carrying only libx11-6 and libxrandr2 plus the binary at /usr/local/bin, with the entrypoint set to the tool itself.

The locked build and the removal of the intermediate binary copies are the details that make the image small, and the dependency list in the runner stage is minimal because the Rust binary links the X11 libraries dynamically rather than statically.

Features are chosen at compile time, which shapes the binary

The features section of the manifest is short and each entry is a deliberate trade:

[features]
default = ["ski"]
# enable gifski encoder
ski = ["gifski", "rgb", "imgref"]
# enable support for viewing sixel images
sixel = ["viuer/sixel"]
# run window system tests
test-ws = []

The ski feature is on by default, and as noted, it exists to enable the gifski encoder. Turning it off produces a smaller binary with no animated GIF encoding, which matters if you only need the file operation commands.

The sixel feature is opt in and pulls the sixel support from viuer, which is what lets the tool view images in a terminal that speaks sixel.

The test-ws feature is a testing switch rather than a user-facing one. It runs window system tests, which is a hint at how the project validates the part of the code that is hardest to test, since the display server interaction cannot be exercised on a headless machine without something to attach to.

There is also a set of per-target dependency sections in the manifest. The Windows and macOS target sections are present but empty, and the Linux one carries the x11, wayland-client, wayland-protocols-wlr and wayland-protocols-hyprland crates. A comment in the manifest explains the choice: a pure-Rust backend by default, so no libwayland is needed to build. That comment is the reason the Linux dependency list is as short as it is, and it is a deliberate portability decision rather than an accident.

Where menyoki is the wrong tool

The first wrong case is a platform that is not Linux for recording work. The support table is explicit that Windows and macOS have no record or capture. A macOS user who wants to screencast a terminal has to fall back to something else, and the file operation commands being available there does not help with the actual use case.

The second wrong case is a Wayland session that is not Hyprland. The documentation lists Wayland support as output record and capture with window on Hyprland, so a compositor such as GNOME or KDE gets the output path and not necessarily the window path. For a tool whose original purpose was capturing a terminal window, that is a meaningful gap.

The third is format expectations. AVIF and MP4 are listed as unsupported, so a workflow that ends in a modern image format or a video container needs a different tool for the encode step.

The alternative worth naming is a purpose-built screencast utility, and the difference in approach is instructive. A dedicated recorder gives you frame rate selection, region selection, audio capture, hotkeys and an encoder chosen for video, and it is tuned for producing a shareable file. menyoki is a general command line utility that grew a record mode, so its strengths are elsewhere: it is scriptable, it composes with other command line tools, and it handles the image work in the same breath as the capture. If your need is one clean video file for a team update, a dedicated recorder is the better buy. If your need is to record a terminal, convert it, split it and analyse the frames in one session, the subcommand set is the argument.

A third option is to script the pieces yourself with an existing capture library and an image tool, which gives you full control and none of menyoki's convenience.

Editorial conclusion

menyoki fits a Linux user who wants to record a terminal, a screencast or a quick image edit without opening a graphics application, and who is comfortable with a command line tool rather than a desktop program. It is the wrong choice for recording on Windows or macOS, where the documentation states there is no record or capture support, and the wrong choice when you need AVIF or MP4, which are listed as unsupported formats. Before you depend on it, check the Wayland caveat, since the window capture path is described as working on Hyprland rather than across Wayland compositors generally.

Frequently asked questions

Official sources

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