# Kondo: a CLI and GUI cleaner for node_modules, target and build directories

> Kondo scans a directory tree for recognised project types and deletes their dependency and build output folders. It is a Rust workspace with a CLI and a Druid-based GUI, MIT licensed, and it is best understood as rm -rf with a prompt.

**tbillington/kondo** — Cleans dependencies and build artifacts from your projects.

- Repository: https://github.com/tbillington/kondo
- Stars: 2,427 · Forks: 69
- Language: Rust
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/tbillington-kondo

## The disk-space problem Kondo was written for

A single JavaScript checkout can carry hundreds of megabytes of node_modules. A Rust workspace carries target. A Unity project carries Library and Temp. None of that is source, and all of it is regenerable, but it accumulates quietly across every project you have ever cloned. Kondo exists for the moment when you want to back up your code without the dependencies, or when you try out a lot of projects and the disk fills faster than you expect. It targets developers who keep a directory of checkouts on one machine and want to reclaim space without visiting each project by hand. The README lists more than 20 supported project types, including Cargo, CMake, Composer, Elixir, Godot 4.x, Gradle, Jupyter Notebook, Pixi, Maven, Node, Pub, Python, SBT, Stack, Cabal, Swift, Unity, Unreal Engine, Zig, .NET, Turborepo, Terraform and React Native. The breadth is the point: one scan covers a polyglot home directory, not just one ecosystem.

## How Kondo decides what to delete

Kondo walks a directory tree and looks for the marker files that identify a project type. When it recognises one, it knows which subdirectories belong to that type's dependency and build output, and those are the candidates it offers to remove. The repository is split into three crates: kondo-lib holds the scanning and deletion logic, kondo is the command line binary, and kondo-ui is the graphical front end. The workspace Cargo.toml lists exactly those three members, with kondo as the default member, so a plain cargo build from the root builds the CLI. The README points at a specific line in kondo-lib/src/lib.rs when it describes the tool as essentially rm -rf with a prompt, which is an honest description of the data flow: detection, then a confirmation, then a recursive delete. There is no staging area and no trash can in the described behaviour. The GUI is built on Druid, and the README notes that Linux users may need platform specific dependencies for it. The release profile in Cargo.toml sets lto, codegen-units = 1, panic = "abort" and strip = true, with a comment that without these the bevy executable is over 200 MB, which is a leftover from the project's history rather than anything to do with Kondo's own runtime.

## Installing Kondo and running a first scan

The README gives package-manager installs for several platforms. On Windows via winget:

```powershell
winget install kondo
```

On macOS via Homebrew:

```sh
brew install kondo
```

MacPorts and Arch Linux are also covered, with sudo port install kondo and pacman -S kondo respectively. If you prefer to build from source, the README requires Rust and gives this sequence:

```sh
git clone https://github.com/tbillington/kondo.git
cargo install --path kondo/kondo
```

Binaries are also published on the releases page. Once installed, running kondo with no arguments scans the current directory:

```sh
kondo
```

You can pass one or more paths to choose where the scan starts:

```sh
kondo code/my_project code/my_project_2
```

The README does not describe the exact output format, but the screenshots show a list of discovered projects with the space each would free. The --older flag filters to projects that have not been modified for at least the given period, which is useful when you want to keep recently touched work intact:

```sh
kondo --older 3M
```

The shorthand -o3M does the same thing. The README says further options such as quiet mode, following symlinks and filesystem restriction are visible with kondo --help, so that flag is the authoritative list rather than the README text.

## The deletion is real, and that is the main limitation

The README repeats a warning in both the installation and usage sections: Kondo is essentially rm -rf with a prompt, and you should always have a backup of your projects. That warning is the limitation. A build directory is usually disposable, but not always. A Unity project's Library folder is regenerated on open, yet a project with local modifications that were never committed loses them along with everything else in the target directory. The same applies to any project where generated output has been edited by hand or where the dependency directory contains a patched package. Kondo has no concept of a project being dirty, no check against version control, and no documented undo. If a scan misidentifies a directory as a project type, the prompt is the only thing between you and the delete. The tool is also the wrong choice when you want to reclaim space from a single large project: cargo clean or a manual rm does the job with less scanning, and Kondo's value comes from covering many projects at once. Anyone who cannot tolerate an accidental recursive delete on a working tree should not run it unattended, and the README does not offer a mode that changes that.

## Kondo against npkill and the cargo-specific cleaners

The README's own similar-projects list is the best guide to alternatives, and the split is instructive. npkill targets Node projects only, so it does one ecosystem and does it interactively; Kondo covers Node among 20-plus types, which matters if your disk holds Rust, Unity and Python checkouts alongside JavaScript. The Tin Summer and Detox sit in a similar broad-cleaner space. On the narrow end, Cargo Cleanall, Cargo Sweep, Cargo Wipe and cargo-clean-recursive are all Cargo subcommands, so they run as cargo sweep or similar inside a Rust project and know nothing about node_modules. That difference in approach is the real decision: a cargo subcommand integrates with the toolchain you already use and needs no separate install, while Kondo is a standalone binary that has to be installed and invoked separately but sees every project type in one pass. If your disk pressure comes entirely from Rust target directories, a cargo subcommand is the smaller tool for the job. If it comes from a mixed pile of checkouts, Kondo's scanning breadth is the reason to pick it.

## Maintenance, release cadence and the MIT licence

The last push to the repository was on 2026-04-24, and the repository is not archived. The release history is uneven: v0.7 in July 2023, v0.8 in December 2023, then a gap until v0.9 in January 2026. That pattern suggests bursts of work rather than a steady cadence, and anyone depending on quick fixes for a newly released project type should weigh that. The upgrade cost is low in practice because the tool has no configuration file and no on-disk state to migrate: you install a new binary and the behaviour changes. Kondo is MIT licensed, which permits commercial and private use and modification, with the usual requirement to keep the licence notice. The README does not discuss licence obligations for redistribution, and nothing here is legal advice; read the LICENSE file in the repository if you plan to ship a modified binary.

## Conclusion

Adopt Kondo if you keep many checkouts on one disk and can accept that every deletion is a plain recursive remove with only a prompt in front of it. Do not adopt it for projects whose build directory holds the only copy of anything, and do not expect it to recover what it deletes: the README does not document an undo. Before running it on a real tree, run kondo --dry-run once and confirm the list matches what you expect, then check kondo --help for the current flag set, because the README does not enumerate every option.

## FAQ

### What is Kondo and what does it delete?

Kondo is a Rust CLI and GUI that scans your projects and removes dependency and build output directories such as node_modules, target and build. The README lists more than 20 supported project types, from Cargo and Node to Unity and Unreal Engine.

### How do I use Kondo to clean my projects?

Run kondo with no arguments to scan the current directory, or pass one or more paths to choose where the scan starts. The --older flag, or its -o shorthand, filters to projects that have not been modified for at least the given period, for example kondo --older 3M.

### How do I install Kondo?

The README gives winget install kondo on Windows, brew install kondo on macOS, sudo port install kondo via MacPorts and pacman -S kondo on Arch Linux. From source, it requires Rust and uses cargo install --path kondo/kondo after cloning the repository. Binaries are also on the releases page.

### Is Kondo safe to run on my projects?

The README warns twice that Kondo is essentially rm -rf with a prompt and says you should always have a backup of your projects. Detection is followed by a confirmation and then a recursive delete, and no undo is documented.

### Does Kondo have a graphical interface?

Yes. The kondo-ui crate is a separate binary built on Druid, installable with winget install kondo-ui on Windows or pacman -S kondo-ui on Arch Linux, or built from source with cargo install --path kondo/kondo-ui. The README notes that Linux may need platform specific dependencies for it.

## Sources

- [Issues](https://github.com/tbillington/kondo/issues)
- [License: MIT](https://github.com/tbillington/kondo/blob/master/LICENSE)
- [README](https://github.com/tbillington/kondo/blob/master/README.md)
- [Releases](https://github.com/tbillington/kondo/releases)
- [tbillington/kondo on GitHub](https://github.com/tbillington/kondo)

---

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