OTree: a terminal tree viewer for the deep YAML files nobody wants to scroll

The problem: a YAML file too deep to read as text

OTree is a command line tool to view objects, in JSON, YAML, TOML and XML, in a TUI tree widget, and the README explains the motivation in a single sentence. The author created it to better view those super deep YAML files of Kubernetes, while jnv only supports JSON.

That is a narrow, real problem. A Kubernetes manifest, a CI pipeline definition, a large values file for a deployment, an OpenAPI document: these are files where the information you need is three or four levels down, and where the line-oriented tools that usually handle structured data, `jq`, `yq`, a text editor, all make you either write a query or scroll.

A tree widget sidesteps both. You open the file, you get the shape of it immediately, and you descend into the branch you care about. The result is a viewer, and the README's own framing of the feature list confirms it: everything on that list is about reading.

The project is a Rust binary called `otree`, MIT licensed, with the primary language recorded as Rust, and the topics name the formats and the shape of the thing: cli, json, toml, treeview, tui, xml, yaml.

The licence matters here in a practical way, because a viewer for configuration files is the kind of tool people want to build into their own workflows, and MIT allows that without ceremony.

The tree widget and the three-panel layout

The UI is built on ratatui, the Rust terminal UI framework, and specifically on the `tui-tree-widget` crate, which the README credits as the basis of the project. The dependency list in `Cargo.toml` confirms both, with `ratatui` and `tui-tree-widget` among the direct dependencies.

The layout has three named parts, and they appear as separate roadmap items with the version that introduced them. The header came in v0.1. The tree overview came in v0.1, and it is the panel that shows the shape of the document. The data block also came in v0.1, and it is where the content of the selected item is rendered, with syntax highlighting added in v0.2. The footer, showing the current root and messages, came in v0.2.

So the shape is a tree on one side and the selected value on the other, with a header above and a status footer below. That is a familiar layout for this kind of tool, and it is well suited to a terminal where horizontal space is the scarce resource.

The tree is navigable in several ways. There is an action to change the current selected item as the root, which effectively re-roots the tree at that node, and an action to go back to the previous root. There are actions to jump to the parent item, to jump to the parent item and close, to expand a selected item's children, to expand all items, and to close all opened items. There is an action to scale the tree widget up and down, and one to switch between the tree overview and the data block.

The root re-rooting plus the back action is the interesting pair. It is what makes deep files workable, because you descend once to the subtree you need and then work inside it rather than scrolling back out.

Filtering, help popups and the debug flag

Three features stand out among the actions, because they are the ones that turn a tree viewer into a tool you keep.

Filtering arrived in v0.5, and the roadmap item is marked in bold: filter items, like jnv. The filter input UI also came in v0.5, and a separate v0.6 item added highlighting of filtering keywords, so matched text is marked in the tree rather than just narrowed.

Help and error messages are handled by a popup widget that came in v0.2, and a specific action to pop up help messages came in v0.5. So the tool has both a general popup for errors or help, and a dedicated help action.

The debug flag came in v0.4 and writes debug logs to a file when you pass `--debug`. For a tool that renders a document into panels, that log is the only way to see what happened when the tree looks wrong.

Clipboard support also came in v0.2, and the roadmap is honest about the limitation: copying the current item's content might need an external program like `wl-copy` or `pbcopy`. That is the standard trade on Linux and macOS, and it means the copy action depends on a helper being present rather than doing the work itself.

Mouse support is there too, with click actions and scroll actions, and opening the current selected item in an editor in read-only mode came in v0.2. That last one is the right shape for a viewer. You inspect, and if you need to change something you leave the tool and open the file properly.

Installing: release binaries, cargo, AUR and Homebrew

There are four routes, and the README leads with the one that avoids a toolchain.

Binary files are downloaded from the release page. You can also build it from source, which requires cargo installed:

cargo install --git https://github.com/fioncat/otree

On Arch Linux, `otree` is available from the AUR and can be installed with an AUR helper:

paru -S otree

On macOS and Linux, the Homebrew formula is the route:

brew install otree

That is a well covered install matrix for a single-binary tool, and the split between Homebrew for macOS and Linux and the AUR for Arch is the normal arrangement.

The Cargo.toml shows what a build involves. The package is `otree` at version 0.7.1, edition 2021, with a `build.rs`, and the build dependencies are `vergen` with the build, rustc, cargo and si features, which is how the version and build metadata get stamped into the binary, and `simple-error`. The release profile is tuned: `lto = true`, `strip = true` and `incremental = false`.

The dependency list also reveals the scope. `clap` with the derive feature is the command line parser, `serde` and `serde_json` with the `preserve_order` feature, plus `toml` with `preserve_order`, which is what keeps key order stable in a tree view. `quick-xml` with the serialize feature handles XML, `hcl-rs` handles HCL, `minijinja` with builtins and serde is a template engine, `notify` watches the filesystem, `humansize` formats byte sizes, and `regex`, `console`, `crossterm` and `dirs` fill out the terminal and configuration work.

Configuration lives in a TOML file you own

The README is explicit that the tool is configurable, and points at two files for the details. TUI keys, colours and more are configured in `~/.config/otree.toml`, with the default configuration checked in at `config/default.toml`. The full list of available actions and their default key bindings is in `docs/actions.md`, and there is a separate colours document at `docs/colors.md`.

Having the defaults in the repository is the detail that matters here. A key binding table in a documentation page is a copy of the truth at some point in time, whereas a `default.toml` in the tree is the truth, and diffing your own file against it is how you find out what a new release changed. That is the difference between a tool you can keep current and one that quietly drifts.

The roadmap item for customisation is v0.1, so configuration has been there from the start rather than bolted on later, and it lists allowing the user to customize TUI colors and key bindings, and other things you can imagine.

The other detail is the `~/.config/otree.toml` location on every platform, which is the XDG convention, and it is handled by the `dirs` crate in the dependency list rather than by hand-rolled path logic.

Where OTree is the wrong tool

The first wrong-tool case is editing. The action list includes opening the selected item in an editor in read-only mode, and there is no write path anywhere in the roadmap. If your task is to change a value in a YAML file, OTree will make it easy to find the value and then send you somewhere else to change it, and a text editor with a good YAML plugin will be faster.

The second is a file that does not fit the tree model. The examples directory in the repository lists the formats that are covered, with `edge.json`, `edge.toml`, `edge.yaml`, `example.hcl`, `example.json`, `example.jsonl`, `example.toml`, `example.xml` and `example.yaml`, and the presence of an `edge.json` and an `edge.toml` and an `edge.yaml` suggests the author thought about awkward inputs. A very large flat file with no nesting is a case where a pager and `grep` beat a tree view, and the tool's own filter is the concession to that, since filtering is the feature that lets you treat it like a search tool.

The third is automation. This is an interactive terminal program, with a GUI-style action model, popups and a tree overview. If you want to extract a value from a file as part of a script, you want `jq` or `yq` or a language binding, not a TUI.

The alternative worth naming is the tool the author started from, jnv, which the README credits as the inspiration for the filtering behaviour. The difference in approach is that jnv supports JSON only, while OTree handles JSON, YAML, TOML, XML, HCL and JSONL through one tree, and adds a navigation model with a data block, syntax highlighting, re-rooting and mouse support. The trade is that OTree is Rust with a small dependency footprint but no library API for programmatic use, where a parser library would give you the values directly and leave the presentation to you.

Maintenance state, the roadmap, and the licence

The last push to the default branch was on 2026-10-19, and the repository is not archived. The recent releases are v0.7.1 and v0.7.0, both tagged on 2026-07-07, with v0.6.5 on 2026-03-03. So the last release was in July 2026 and the branch has moved on since, which for a single-author utility project is a healthy but unhurried rhythm.

The roadmap is a completed checklist, and every item is ticked. It starts with the UI at v0.1, moves through the footer and popup at v0.2, the debug flag at v0.4, the filter input and filter and expand actions at v0.5, and the keyword highlighting at v0.6. The last release, v0.7.x, sits above all of those, which means the feature set described in the README is a set that has already shipped rather than a plan.

The last roadmap item is the one that matters for trust in a viewer: with the `--debug` flag, write some debug logs to a file. For a tool whose whole job is to render someone else's data correctly, having a log of what it did is not a luxury.

The licence is MIT, with the `LICENSE` file at the top of the tree, and the package metadata records the same. For a tool you might bundle into a team image or wrap in a script, that is the most permissive arrangement available and only requires keeping the copyright notice.

One quality detail in the manifest is worth noting for anyone thinking about contributing. The clippy lints are set to pedantic at warn level with a priority of minus one, which means the pedantic set is enabled but does not fail the build on its own, and a few specific lints are allowed outright, with a comment explaining that matching on Options is visually cleaner and that `too_many_lines` is necessary evil for now. That is a project with an opinion about its own lint budget, which is usually a sign that the code is actually looked at.

Editorial conclusion

Adopt OTree when you regularly read large structured files and want to move through them by structure rather than by searching text, since the tree overview, the data block and the filter are built for exactly that. Do not adopt it as an editor, since the action list includes opening the selected item in an editor in read-only mode and there is no write path, and do not adopt it expecting full format coverage beyond what the README lists. Before you install, check the release page for a prebuilt binary for your platform, since installing from source needs cargo and the release page is the faster route, and read `docs/actions.md` for the default key bindings, because the action list is long and configurable from `~/.config/otree.toml`.

Frequently asked questions

Official sources

1. fioncat/otree on GitHub
2. Issues
3. License: MIT
4. README
5. Releases