veet
A terminal UI and CLI uninstaller for Linux that goes further than package managers do on their own. It scans 17+ package managers at once (pacman/AUR, apt, dnf, Flatpak, Snap, AppImage, npm, pipx, cargo, and others), finds the leftover config, cache, and state directories that normal uninstalls leave behind, and removes them in one transaction behind a single sudo prompt.
- stars
- 101
- forks
- 6
- watchers
- 0
- package managers supported
- 17+
- themes
- 7
- commits
- 28
Uninstalling software with the usual Linux package managers (pacman -R, apt remove, dnf remove, flatpak uninstall) removes the package-managed system files. The user-space data stays behind: ~/.config, ~/.cache, ~/.local/share, Flatpak sandbox data, Snap snapshots, and rotated log archives. Over time that adds up to gigabytes of orphaned files.
veet is meant to close that gap. It scans 17+ sources concurrently, including native package managers, sandboxed containers, portable bundles, and language toolchains (npm, pipx, cargo, gem, go install), then stages every residual path it finds so you can inspect the list before anything is deleted.
What it does
- Queries pacman/AUR, apt, dnf, zypper, Flatpak, Snap, AppImage, Homebrew, Nix, and language-level installs at the same time.
- Finds and stages leftover configs, caches, and sandboxed app data instead of deleting them silently.
- Shows a live TUI dashboard with per-detector progress, color-coded status, and an elapsed timer.
- Detects unneeded dependencies through each package manager's own tooling (
pacman -Qdt,apt autoremove, and so on). - Protects core system components (glibc, kernel, systemd, the active shell) from selection, and batches all elevated operations into one sudo prompt.
- Supports search filters in the TUI: by source (
@flatpak), size (>200M), or protected status. - Ships with 7 themes: Catppuccin, Nord, Dracula, Gruvbox, Tokyo Night, Monokai, and a default cyan palette.
TUI and headless CLI
veet opens the interactive dashboard. veet scan, veet clean, veet orphans, and veet cache do the same work from scripts, with --dry-run and --json output.
The hard part
- Safe deletion at scale: with 17+ sources and deep filesystem scanning, it was easy to hit something critical (kernel modules, an active shell config, systemd units), so the tool has an explicit protected-package registry rather than relying on the user to be careful.
- Concurrent scanning: querying that many package managers and directory trees in parallel without a stuttering UI meant building a streaming scan matrix that updates per detector as results arrive.
- Fewer privilege prompts: most removals need root, and prompting per file or per manager is terrible UX, so the whole delete plan is staged first and elevated once per transaction.
- Cross-manager consistency: pacman, apt, dnf, Flatpak, Snap, and language tools all report things differently. Normalizing them into one
AppInfomodel let the UI and CLI treat every source the same way.
Outcome
- veet is installable through AUR, a one-line install script,
go install, or a manual build, with CI passing on the repo. - The same codebase provides the interactive TUI and a scriptable CLI (
scan,clean,orphans,cache,history). - Coverage goes beyond BleachBit or the package managers alone: the README comparison shows it's the only one handling sandboxed data (
~/.var/app,~/snap) and orphan pruning together. - It ships with 7 complete theme palettes and full keyboard navigation, polish that CLI-first tools often skip.
What I'd do differently
- Building the protected-components registry early instead of bolting it on later is what made the tool trustworthy enough to recommend to other people for destructive operations.
- Keeping the headless CLI subcommands separate from the TUI while backing both with the same detector and uninstaller engine avoided duplicated logic and kept scripts and interactive use in sync.
- Independent parallel detector handlers under
internal/detector/made adding a new package manager a contained change that didn't touch the staging and removal engine. - For a tool that deletes files across 17+ sources, dry-run mode was necessary from the start so users could inspect staged paths before committing.
Architecture & screenshots
