clin: an Obsidian-style note manager that lives in your terminal

A vault you can open over SSH

clin is a free, open source terminal note manager inspired by Obsidian, and the description says it plainly: it packs Obsidian's core features, markdown editing and rendering, canvas files, and a force-directed graph view, into a single Rust binary, while keeping the UI approachable. The single binary matters more than it might sound. A note-taking application in a terminal is something you can use over SSH on a server, in a container, or on a machine where the desktop client is heavy, and the file format is the same markdown you already have, so nothing is locked in. The migration story is one sentence in the README: drop an existing Obsidian vault into clin and it works out of the box. That claim depends on the format compatibility, and the fact that the canvas view reads the Obsidian-compatible .canvas file format suggests the same care was taken there. What is not carried over is stated in the same paragraph, that databases and Obsidian plugins are not supported, which is the significant gap for anyone who has built a workflow on the plugin ecosystem. The repository shows a Rust project with Cargo.toml, a src/ directory, tests/, a docs/ directory, a nix/ directory and flake.nix, and the crates.io package is clin-rs with a GPL-3.0-only licence.

The notes view is the file manager, the browser and the metadata panel

The highlights section describes the notes view in detail and it is the longest feature list in the README, which is a sign of where the effort goes. The view is a folder tree with recursive folder counts in the header, and alongside it sit tags, a markdown preview pane with a built-in renderer, search, filter and sort, pinning, multi-select, an inline_info toggle to control metadata rendering, and trash management. The file management operations are the usual set, copy, paste, delete, rename and move. There is a customisable bottom strip with an activity heatmap, goals and widget previews, which is where a personal dashboard lives inside the terminal. The app also auto-refreshes on external file changes, which is the feature that makes the vault genuinely shared with your other tools, since an editor that does not notice a file changing underneath it is not much use. A show-info popup gives word, character and header metrics for the current note. What is missing from the list is anything about plugins or scripting, so the extension story is closed, and the extensibility that Obsidian users rely on does not carry over.

A graph view built from your wikilinks

The graph view is described as a fully integrated force-directed graph visualisation of your note corpus, with the edges coming from wikilinks. That is the right data source, because a wikilink graph is the structure you have already created by writing, and the README is not claiming more than that. The features are physics simulation, a minimap, a legend, search, and configurable colours and layout, and there is a separate document for it. The interesting part is that it is integrated rather than bolted on, so the graph is not a separate mode you switch to but a view over the same corpus that the notes view also shows, which means the links you see in the graph are the links the editor resolves. The tool has a companion project for the drawing canvas, draw-rs, by the same author, with its own standalone draw application, and that engine is reused for the draw view. The Draw view itself is a freehand canvas with shapes for rect, ellipse, diamond, line and arrow, text, draw smoothing using a binomial filter, mouse-drag panning, zoom-to-cursor and an eraser, with its own .draw file format. The subnotes feature is the other structural idea, virtual notes attached to physical notes, browsable through a grid tab, a virtual tree folder, a radial graph and a manager popup.

Canvas, outline, editor and help, all in the same binary

The canvas view handles the Obsidian-compatible .canvas file format, with text, file, link, group and image nodes placed on an infinite two dimensional canvas and connected with edges, plus a right-click context menu, mouse-drag panning, zoom-to-cursor, drag and resize. The outline view is simpler and useful, showing the content of a markdown file as a tree with headers as parents and content as children, which is a good way to see the shape of a long note. The editor view handles title and body editing with an optional markdown preview, a built-in find popup, a soft-wrap toggle, sidebars with wikilink previews, mouse support, line numbers, undo and redo, an editor context menu, external editor integration and an insert-date action. The help view is a tabbed in-app reference with an auto-generated keybind index, per-view descriptions, a popup accordion and preset-aware tips, and the README notes a command palette on Ctrl+P that is extensible, though the description of that is cut off in the text available here. The presence of a generated keybind index is the detail that tells you the key bindings are a first-class part of the design rather than an afterthought, and an in-app help that is generated from the same source as the bindings cannot drift out of date.

Images render natively, and only if you ask for it

Native image rendering is supported through ratatui-image, with sixel, kitty, iTerm and halfblocks auto-detected, and it works in the canvas view, the notes preview and the editor preview. The halfblocks mode is the one that matters for a plain terminal, since it renders a pixel image using the half block character, which doubles the vertical resolution, and that is what makes an image legible in a terminal that has no graphics protocol at all. The feature is controlled by a features flag with images set to true, so it is a compile-time decision rather than a runtime setting, which is the right call for something that pulls in an image decoding dependency. The README also points at a separate document for the image rendering details. The build configuration shows the project takes its packaging seriously, with a PKGBUILD for Arch, a nix/ directory plus flake.nix for Nix, a .envrc, a build.rs, a clippy.toml and a deny.toml, and the lint configuration in Cargo.toml is extensive, with the pedantic clippy group enabled and a long list of individual lints allowed, which is what a project accumulates when it has been tuned against a strict linter.

The 0.14 betas and the Rust 1.90 floor

The release history shows the project is moving quickly and in public. The recent tags are v0.14.0-beta.1 on 2026-10-19, v0.14.0-beta.0 on 2026-10-18, and v0.13.2 on 2026-10-02, so two beta tags in consecutive days, which is a common pattern for a maintainer who tags as they work rather than at a release boundary. The version in Cargo.toml is 0.14.0-beta.1, the edition is 2024, and the declared minimum supported Rust version is 1.90.0, with a badge linking to the Rust 1.90.0 release announcement. The MSRV is worth noting because it is a real constraint for anyone on a distribution's packaged Rust, since a 1.90 floor is recent enough that an older toolchain will refuse to build. The licence is GPL-3.0-only, which for a note-taking application is a heavier commitment than the MIT that most Rust utilities use, and it is the one thing to check if you intend to fork it. The project is funded through Patreon, carries a Tool of the Week badge from Terminal Trove, and the repository has a CHANGELOG.md, a ROADMAP.md, a CONTRIBUTING.md and a cliff.toml for generating the changelog from commit messages. A docs/ directory with one document per view, EDITOR.md, GRAPH_VIEW.md, CANVAS.md, DRAW.md, HELP.md, SUBNOTES.md and IMAGE_RENDERING.md, is a good sign for a project of this size.

Where clin is the wrong choice

The first limit is the one the README states plainly, that databases and Obsidian plugins are not supported. If your vault has become a system, with queries, front matter handling and a plugin that generates your daily notes, then a terminal client that reads the markdown but not the plugin behaviour is a read-only view of your setup, and the value drops sharply. The second is that the editor is a TUI editor, and the README's emphasis on keeping the UI approachable is doing a lot of work. A terminal text editor cannot give you the same editing ergonomics as a browser-based editor with live preview, inline wikilink autocomplete and a plugin ecosystem, and the features that clin does offer, external editor integration and an insert-date action, are the concessions to that gap. The third is the beta. The current tag is a 0.14.0 beta, the version numbers in the 0.x range mean the interface is not settled, and the churn visible in the release list suggests changes will keep coming. The fourth is portability of the vault, since the canvas format is Obsidian compatible but the draw format and the subnotes structure are the author's own, so a vault becomes partly proprietary to this application even though the markdown stays standard. The fifth is that images are a compile-time feature, so if your notes rely on screenshots or diagrams you either accept the halfblock rendering or build with the flag on.

Editorial conclusion

Adopt clin if you keep an Obsidian vault and want to read, write and navigate it from a terminal over SSH, where a desktop app is not an option. Skip it if you rely on Obsidian databases or plugins, since neither is supported, and skip it if you need a stable release, since the current tag is a 0.14.0 beta. Verify first that your vault's markdown and canvas files are the ones the app expects, that the images feature is enabled if you want native rendering, and that your Rust toolchain meets the stated 1.90.0 minimum supported version.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. reekta92/clin-rs on GitHub
5. Releases