# denisidoro/navi: an interactive cheatsheet tool for the command line

> navi turns plain-text .cheat files into a searchable, fillable command picker that runs in your terminal. It is aimed at people who know what they want to do but not the exact flags, and its main dependency is fzf or skim.

**denisidoro/navi** — An interactive cheatsheet tool for the command-line

- Repository: https://github.com/denisidoro/navi
- Stars: 17,692 · Forks: 573
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/denisidoro-navi

## What navi solves, and who it is actually for

The README lists four benefits in plain terms: it spares you from knowing CLIs by heart, from copy-pasting output from intermediate commands, from typing, and it teaches new one-liners. That is a fair description of the problem. Most people do not forget what git rebase does; they forget the order of arguments, or they need the output of one command as the argument to another. navi targets that gap.

The intended user is someone who lives in a terminal and is willing to write or collect cheatsheets. The README states that you may write cheatsheets yourself or download them from maintainers. That sentence carries the real cost of adoption: navi is a browser and an executor, not a knowledge base. If you never write a .cheat file and never import a repository, you have installed a search box with nothing in it.

It is a poor fit for someone who wants a single curated reference for a specific tool. It is also a poor fit for a locked-down workstation, since the whole point is to execute the commands it shows you.

## How the fzf-backed selection loop works

The README is explicit that navi uses fzf or skim under the hood and can run either as a command or as a shell widget in the style of Ctrl-R. The repository layout backs this up: src/ holds the Rust crate, shell/ holds shell integration, and the dependencies in Cargo.toml include crossterm, walkdir, regex and serde_yaml rather than any fuzzy-finder library. navi delegates the interactive selection to an external binary.

That delegation is the core design decision. fzf owns the keystrokes, the filtering and the layout; navi owns the cheatsheet format, the parsing and the execution. It also means your existing fzf configuration can influence the experience, which the README acknowledges by pointing to a section titled overriding fzf options in docs/configuration/README.md.

Cheatsheets are .cheat files. The README gives one example and describes the shape: a tag line starting with %, a comment line starting with #, the command itself, and a $ line that supplies candidate values for a placeholder. The $ line is a shell command whose output populates a list, which is what the README means when it says suggested values for arguments are dynamically displayed. So the data flow is: parse .cheat files, let fzf pick an entry, run the $ commands to collect candidate values, let fzf pick a value, substitute it into the command, then execute. Each of those steps is a place where a slow $ command makes the whole interaction feel slow, and the README does not discuss caching.

## Installing navi and running a first cheatsheet

The recommended install is Homebrew. The README states this directly and points to docs/installation/README.md for other package managers, with a Repology badge showing packaging status across distributions.

```bash
brew install navi
```

After that, the README says running navi for the first time will help you download and manage cheatsheets, stored by default at ~/.local/share/navi/cheats/. So the first real use is simply launching it and following the prompts.

```bash
navi
```

To see every flag and subcommand, the README gives one command. This is the fastest way to confirm what your build supports, since the docs folder is the authoritative reference and the README is a summary.

```bash
navi --help
```

For a first cheatsheet of your own, the README shows this format. The % line carries tags, the # line is a description, the bare line is the command, and the $ line defines a placeholder named branch whose candidates come from git branch piped through awk.

```sh
% git, code

# Change branch
git checkout <branch>

$ branch: git branch | awk '{print $NF}'
```

When you select this entry, navi runs the $ command, shows the branch names in a list, and substitutes your pick into the command before running it. The README also documents using cheatsheets from other tools such as tldr and cheat.sh, importing from git repositories, and auto-updating repositories, all under docs/.

## Where navi gets in the way

The dependency on fzf or skim is the first constraint, and the README treats it as a given rather than something navi bundles. If neither is on the machine, the interactive path has nothing to drive it. That is a real prerequisite to check before you plan a rollout.

The second constraint is the write-your-own model. The README's list of what you can do is almost entirely about managing cheatsheets: browse featured ones, import from git, write your own, share them, use cheatsheets from other tools, auto-update. Nothing in it promises that the default set covers your stack. Teams that expect a turnkey library will be disappointed, and teams that expect everyone to author .cheat files will find that maintenance follows the same decay curve as any internal wiki.

The third is execution. navi runs commands, and the repository exposes two Cargo features named disable-command-execution and disable-repo-management. Their presence in Cargo.toml tells you the maintainers consider both capabilities optional, which is useful for packaging, but the README does not explain how a build with those features behaves at runtime. If you need that guarantee, read the source or the docs rather than assuming.

Finally, the release history is uneven. v2.24.0 is dated 2025-01-29, v2.23.0 is dated 2023-12-10, and v2.25.0-beta1 is dated 2025-04-09. The last push to the repository was on 2026-09-20. A long gap between stable releases is not the same as abandonment, but anyone pinning a version should look at the tag list rather than the README badge.

## How navi differs from tldr and cheat.sh

The README names tldr and cheat.sh, but as sources of cheatsheets to consume, not as competitors. That framing is accurate and worth understanding before choosing.

tldr pages are community-written explanations of a command, rendered for reading. You look up tar, you read the page, you copy the line you need. There is no argument prompting because the page is static text. cheat.sh serves similar content over HTTP from the terminal, so the lookup is a network request and the result is again text you read.

navi inverts the direction. It does not primarily help you read; it helps you assemble and run. The placeholder mechanism, where a $ line supplies candidate values, exists so that the final command is complete before you press enter. That is a different job. You could use navi to browse tldr content, since the README lists that as a supported source, and many people will do exactly that.

The trade-off is content quality. tldr and cheat.sh have centralized, reviewed corpora. navi's default experience depends on whichever repositories you import, so two navi users can have entirely different results from the same binary. If you want a consistent answer across a team, that consistency has to be built, not installed.

## Licence, upgrade cost and long-term maintenance

navi is Apache-2.0, stated in Cargo.toml and shipped as a LICENSE file at the repository root. Apache-2.0 is a permissive licence with an explicit patent grant, which matters for corporate packaging. This is not legal advice; check with your own counsel if you redistribute a modified build.

Upgrade cost is mostly about the cheatsheet corpus rather than the binary. The README documents auto-updating repositories, which means imported cheatsheets can change under you. If your team depends on a specific command shape, a repository update can silently alter it. The docs folder has a section on repositories that is the place to confirm how updates are triggered before you enable them.

On the Rust side, the crate is edition 2021 and pins a toolchain via rust-toolchain.toml, so building from source is reproducible in the usual Rust way. The Makefile is thin: install, uninstall, fix, test and build all delegate to scripts/ or cargo. There is no separate build system to learn.

The maintenance signal from the repository itself is the last push on 2026-09-20, which is recent. The stable release cadence is slower, with the most recent stable tag before that being v2.24.0 from 2025-01-29. Plan for a project that moves in bursts rather than continuously.

## Conclusion

Adopt navi if you already use fzf or skim and want your own .cheat files to be searchable from the shell, the tmux widget or a script. Do not adopt it if you expect a curated command database out of the box: the README says running navi for the first time helps you download and manage cheatsheets, so the content is a separate decision from the binary. Before committing, verify that your package manager carries a recent build, and read docs/configuration/README.md to confirm where your config file and cheatsheets will live. Also check the Cargo.toml features disable-command-execution and disable-repo-management if you plan to ship navi in a restricted environment.

## FAQ

### What is denisidoro/navi and what does it do?

It is an interactive cheatsheet tool for the command line, written in Rust. The README says it lets you browse through cheatsheets that you write yourself or download from maintainers, and execute the commands, with suggested values for arguments shown in a list.

### How do I install navi on Ubuntu or another Linux distribution?

The README recommends Homebrew with brew install navi and points to docs/installation/README.md for more detail, along with a Repology badge showing which package managers carry it. The README itself does not list per-distribution commands.

### Does navi need fzf installed to work?

The README states that navi uses fzf or skim under the hood, and it can be used as a command or as a shell widget. Neither fzf nor skim is bundled, so an interactive session depends on one of them being available.

### Where does navi store my cheatsheets?

By default they are stored at ~/.local/share/navi/cheats/, according to the README. The README also points to docs/configuration/README.md for setting custom paths for the config file and cheat sheets.

## Sources

- [denisidoro/navi on GitHub](https://github.com/denisidoro/navi)
- [Issues](https://github.com/denisidoro/navi/issues)
- [License: Apache-2.0](https://github.com/denisidoro/navi/blob/master/LICENSE)
- [README](https://github.com/denisidoro/navi/blob/master/README.md)
- [Releases](https://github.com/denisidoro/navi/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/denisidoro-navi