I built an Open Source Linux cleaner because I couldn't find one I wanted to use

Recently I started building something called TuxCleaner, a safety-first cleanup and disk analysis tool for Linux.

What began as a small way to avoid looking up the same package-manager commands turned into a terminal app for cleaning caches, uninstalling applications, finding large files, and removing old project artifacts across different Linux distributions.

Part of the inspiration came from Mole, whose focused terminal experience and safety-first interaction model showed me how approachable a cleanup tool could feel. TuxCleaner brings that idea to Linux with independently implemented cleanup rules and distribution-specific adapters.

This post is about why I built it, why deleting files turned out to be the least interesting part, and why I think a cleanup tool should spend more time earning your trust than asking for your password.

Linux Cleanup Is Still a Collection of Commands

Linux gives you all the tools you need to clean a machine. The problem is that it gives them to you separately.

Package caches live behind apt, dnf, or pacman. Flatpak has its own unused runtimes. Docker has its own cleanup commands. Browsers, package managers, and build tools leave caches in different places. Old projects quietly collect node_modules, target, .venv, build, and dist directories.

None of these is especially difficult to handle on its own.

The friction comes from remembering what is safe, what is reproducible, what needs root access, and which command applies to the distribution I am currently using. A cleanup session becomes a chain of documentation searches and commands copied from old notes.

And because the task involves deleting things, “probably correct” is not a very reassuring standard.

I wanted one place to answer a few basic questions:

• What is using space on this machine?
• Which data can be recreated safely?
• What exactly will be removed?
• Can I inspect the plan before anything changes?

I did not need a magic optimize button. I needed a careful interface around operations Linux already knows how to perform.

The Uncomfortable Part Was Trust

The first version could have been a short shell script. Scan a handful of directories, run the native package-manager cleanup command, print the reclaimed space, done.

But a cleaner is one of the worst places to be clever.

A broad glob, a followed symlink, or an unexpected path can turn a convenient script into a very bad afternoon. Hiding several destructive commands behind one friendly label does not make them safer. It only makes them harder to inspect.

That became the main design constraint for TuxCleaner: discovery and deletion must be separate operations.

A scanner can report a candidate, but it cannot remove it. The executor can remove something, but only after independently validating the exact path or command against an allowlist. Every changing workflow requires an explicit selection or confirmation, and every one supports a dry run.

In practice, the flow looks like this:

scan
  -> show exact candidates
  -> select explicitly
  -> validate again
  -> preview the operation
  -> confirm
  -> execute each action independently
  -> record the result

--yes can skip prompts for automation, but it cannot bypass path validation, command validation, protected-package checks, or checksum verification.

That distinction matters. Convenience should remove repetitive input, not remove safety boundaries.

A Small CLI That Kept Growing

Once the safety model was in place, the scope expanded naturally.

TuxCleaner now has a persistent terminal interface built with Ratatui. Running tuxcleaner opens one place for cleanup, application uninstall, disk analysis, project artifact removal, system status, operation history, and updates.

The cleanup view groups known package, user, browser, developer, Docker, and Flatpak data. Nothing is removed when the scan starts. You choose the groups you want, review them, and confirm the operation.

The uninstall view follows an even stricter path. It lists explicitly installed desktop applications and Flatpaks, keeps the selection empty by default, and asks the native package manager for a transaction preview before removal. Critical system packages are refused, while application configuration and user data are preserved.

The disk explorer keeps large personal files separate from hidden application data. Large files can be selected individually, but hidden data remains read-only. Project cleanup follows the same idea: TuxCleaner can find old reproducible artifacts such as node_modules, target, or .venv, but it never selects them automatically.

The interface is useful, but the boundaries underneath it are the actual product.

One Tool, Different Linux Families

Another part I wanted to avoid was pretending that “Linux” has one cleanup workflow.

TuxCleaner detects the distribution through /etc/os-release and uses a small adapter for its native package manager:

• Arch-based systems use pacman and paccache.
• Debian and Ubuntu-based systems use APT.
• Fedora and RHEL-based systems use DNF.
• Flatpak is handled independently of the distribution.

Unknown distributions can still use the user-cache scanner, developer-cache scanner, disk analysis, project purge, Flatpak uninstall, and system status features. Native package operations are skipped with a warning instead of guessed.

That last part is important to me. Unsupported should mean unsupported, not “run something that looks close enough and hope.”

Why Rust

Rust was a practical fit for this project.

TuxCleaner ships as a single binary, filesystem operations use typed paths instead of interpolated shell strings, and the command runner is isolated behind a trait so tests can replace real package-manager calls with fixtures.

The code is split into small modules for distribution detection, scanning, disk analysis, uninstall discovery, safety validation, history, status, updates, and the terminal UI. This makes it possible to test policy without touching the development machine.

The project also exposes JSON output for automation. Read-only inventory stays read-only unless an explicit destructive flag and exact selection are provided, so the CLI and TUI share the same safety rules.

Local Means Inspectable

TuxCleaner does not need an account, a daemon, or a hosted service. It runs locally and uses the tools already installed on the machine.

When administrator privileges are required, the TUI temporarily returns to the normal terminal for a visible sudo prompt. It never tries to collect a password inside the interface. After authorization, it restores the UI and continues with non-interactive elevated commands.

Operations are stored in an append-only JSONL history, so there is a record of what was attempted, what succeeded, and whether the run was only a preview.

Even self-updates follow the same philosophy: the release archive is matched to the current Linux target, verified against its SHA-256 checksum, and then replaced atomically.

Not a “Make Linux Faster” Button

I am not trying to claim that deleting caches will transform an old laptop or that every unused byte is a problem.

Caches exist for a reason. Build artifacts are useful while a project is active. Docker data may be expensive to recreate. A large file is not automatically a useless file.

TuxCleaner is meant to help with review and intentional cleanup, not manufacture urgency with a giant red warning and a suspicious health score.

Sometimes the correct result of a scan is to remove nothing. A good cleanup tool should be completely comfortable with that.

Try It

TuxCleaner is still an MVP, but it already supports x86_64 and ARM64 builds for GNU libc and musl systems.

You can install the latest release with:

curl -LsSf https://raw.githubusercontent.com/debba/tuxcleaner/main/install.sh | sh

If you prefer to inspect installers before running them, which is especially reasonable for a system utility:

curl -LsSf https://raw.githubusercontent.com/debba/tuxcleaner/main/install.sh -o install.sh
less install.sh
sh install.sh

Then run:

tuxcleaner

There is still plenty I want to improve: broader distribution coverage, better analysis workflows, more cleanup rules with narrowly defined safety boundaries, and a smoother first run.

But the direction feels right. Linux cleanup does not need to be mysterious or aggressive. It can be explicit, inspectable, and boring in the best possible way.

If that sounds useful, feel free to try TuxCleaner on GitHub, open an issue, or tell me which cleanup task you still handle with a command copied from an old note.

https://github.com/debba/tuxcleaner