Dev Janitor: a Tauri desktop app for cleaning dev artifacts and auditing AI CLI configs
Cross-platform desktop app for cleaning development artifacts, managing local developer tools, and checking common environment issues.
At a glance
- What is it?
- Dev Janitor is a Rust and Tauri 2 desktop application that scans project directories for build leftovers, manages 25 AI coding CLIs, and flags risky local configuration. It is a local machine hygiene tool, not a CI or container solution, and its security scan is heuristic rather than a substitute for secret scanning in version control.
- Who is it for?
- Adopt Dev Janitor if you work on a Windows, macOS, or Linux workstation where node_modules, target, and package manager caches accumulate faster than you clean them, or if you run several AI coding CLIs and want one interface to check their versions. Skip it if your cleanup runs in CI, if you need a headless CLI for scripted deletion, or if your security review depends on deterministic rules you can diff in a pull request.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The disk-space and config-drift problem Dev Janitor targets
A working developer machine accumulates two kinds of residue. The first is physical: node_modules trees, Rust target directories, package manager caches, logs, and temporary files that survive long after the branch that created them. The second is configurational: AI coding tools write session state, chat history, and cache files into project directories, and those files sit next to real project configuration. The README draws that distinction explicitly. Dev Janitor scans for development artifacts while avoiding active project config files such as .codex/config.toml, .claude/settings.json, .goosehints, and .junie/AGENTS.md. That list is the interesting part, because a naive cleaner that deletes anything dot-prefixed would break a working Codex or Claude Code setup. The target user is an individual developer on a desktop machine, not a build farm. Everything in the feature list is scoped to a local workstation: installed tools, long-running processes, port ownership, PATH entries, and persisted Windows system or user PATH values.
How the cleanup scan separates artifacts from live configuration
The README describes a scan over project directories that looks for common artifact names: node_modules, target, logs, caches, and temporary files. It does not publish the matching algorithm, so the precise rules for what counts as an artifact are not verifiable from the supplied material. What is documented is the exclusion set for AI tooling. Dev Janitor is said to detect ephemeral leftovers from AI coding tools without flagging active project config files, and the four examples given are .codex/config.toml, .claude/settings.json, .goosehints, and .junie/AGENTS.md. Cleanup of AI chat history, cache, session state, and debug files is presented as per-project, which means the review step is scoped to a directory you choose rather than to the whole home folder. One documented boundary is worth noting: the Copilot cleanup path removes official GitHub Copilot CLI session targets without deleting the entire .copilot configuration directory. That is a deliberate partial deletion rather than a directory wipe, and it suggests the tool treats configuration directories as containers that may hold both disposable and non-disposable content.
Tool management across 25 AI CLIs and five language ecosystems
The tool management side inspects installed tools across Node, Python, Rust, Go, and related ecosystems, and it manages 25 AI CLI tools from one interface. Named examples in the README include Codex, Claude Code, Kiro, Factory Droid, Mistral Vibe, Qoder CLI, Pi, OpenCode, Gemini CLI, and GitHub Copilot CLI. The update model follows official native install and self-update flows where those exist. The README states that legacy Amazon Q installations are guided through migration to Kiro CLI, which is a concrete sign that the catalog tracks vendor renames rather than only version numbers. Update status is presented with a distinction between confirmed up to date and not yet checked, and failure reasons are preserved rather than collapsed into a generic error. A separate document, docs/UPDATES.md, lists update commands for AI Agent CLIs, Pi extension packages, and package managers, along with installation channel restrictions. The README also notes that the AI CLI catalog is checked for local metadata drift on every CI run, and a weekly workflow verifies official documentation and package registry endpoints. That weekly cadence is the maintenance cost of the project, and it is also the reason a catalog like this goes stale if the workflow stops.
What the security scan actually checks, and where it stops
The security scan covers four areas according to the README: risky local tool configurations, ports that should usually listen on localhost only, API keys, GitHub tokens, and provider credentials stored in common configuration files, and MCP server configurations for patterns that can lead to credential exposure or SSRF. The MCP item is the most specific. MCP servers are configured as local processes or remote endpoints, and a misconfigured entry can point at an attacker-controlled URL or pass credentials into a process that logs them. Dev Janitor inspects those configurations for patterns, which is pattern matching rather than proof of exploitability. The credential detection has the same character. Finding a token-shaped string in a config file is a signal, not a verdict, and the README does not document the detection rules, the entropy thresholds, or the false positive rate. Treat the output as a list of files to open and read, not as a clean bill of health. The port check is narrower and more deterministic: it flags listeners that should usually be bound to localhost only, which is a configuration property you can confirm by reading the binding yourself.
Installing and running Dev Janitor from releases or source
The release page at github.com/cocojojo5213/Dev-Janitor/releases is the distribution point. Windows users get an .msi installer or a portable zip named with a _portable suffix. macOS users get a .dmg, and the README notes that the first launch may require Right Click then Open because of Gatekeeper. Linux packages are AppImage, .deb, and .rpm. The README states that installed production builds check signed GitHub releases and can download, install, and relaunch into an update from inside the app, and that the latest stable version is published from the v* tag release workflow after a preflight validation pass. For source builds the prerequisites are Node.js 24 LTS or newer, pnpm 11.15.1 or newer, and Rust 1.97.1. The documented setup sequence is git clone, cd Dev-Janitor, corepack enable pnpm, pnpm install, then pnpm tauri dev. Validation commands are pnpm lint, pnpm validate:release, pnpm build, pnpm test, cargo fmt --check --manifest-path src-tauri/Cargo.toml, cargo clippy with -D warnings, and a cross-target cargo check against x86_64-pc-windows-gnu. One detail matters for contributors: pnpm test runs the Rust core tests without compiling the Tauri desktop shell, so use pnpm test:rust:full when changing Tauri command wiring. The desktop feature is enabled by default in normal Cargo and Tauri builds.
Where Dev Janitor is the wrong tool
The first limitation is structural: this is a desktop GUI application built on Tauri 2 and React 19. The README documents no headless mode, no CLI entry point for scripted cleanup, and no server component. If your cleanup needs to run on a schedule across many machines, or inside a container image build, this is not the shape of tool you want. The second limitation is scope. Every feature is local to one machine: installed tools, local processes, local ports, local PATH, local config files. There is no repository scanning, no pull request integration, and no shared policy file that a team could review and enforce. The third is the security scan itself. Pattern matching over configuration files produces findings that need human reading, and the README does not describe severity levels, suppression rules, or a way to baseline accepted findings. A team that wants deterministic, reviewable rules would be better served by a purpose-built secret scanner wired into pre-commit hooks and CI, because that class of tool fails a build on a match and keeps the rule set in version control. Dev Janitor's value is in the interactive review step, which is exactly what makes it unsuitable as a gate.
Maintenance, release cadence, and the MIT licence
The repository is MIT licensed, which permits commercial and private use, modification, and redistribution provided the copyright notice and permission notice are included. That is a permissive arrangement with no copyleft obligation, and it means you can bundle the binary internally without publishing your own changes. It is not legal advice; read the LICENSE file in the repository for the operative text. On cadence, the release history shows v2.4.3 in June 2026, v2.5.0 in July 2026, and v2.5.1 in September 2026, with the last push to main on the same day as v2.5.1. That is a roughly two-month rhythm across the visible window, which is frequent enough that a pinned older build will fall behind the AI CLI catalog. The catalog is the part most exposed to upstream drift: vendor renames, changed install channels, and new self-update flows all require catalog edits. The README describes a weekly workflow that verifies official documentation and package registry endpoints, so the practical upgrade cost is low for users (the app updates itself from signed releases) and continuous for maintainers. If you build from source, budget for the Rust and Node toolchain versions named above, since the prerequisites are pinned to specific minimums.
Editorial conclusion
Adopt Dev Janitor if you work on a Windows, macOS, or Linux workstation where node_modules, target, and package manager caches accumulate faster than you clean them, or if you run several AI coding CLIs and want one interface to check their versions. Skip it if your cleanup runs in CI, if you need a headless CLI for scripted deletion, or if your security review depends on deterministic rules you can diff in a pull request. Before trusting the security scan, open the flagged config files yourself and confirm each finding; the README describes detection of API keys and tokens in common configuration files but does not document the matching rules or their false positive rate. Verify the GitHub Copilot CLI cleanup path on a scratch profile first, because the README states it removes session targets without deleting the whole .copilot directory, and that boundary is the part worth confirming on your machine.
Community notes