Dev Janitor: A Tauri Desktop App for Cleaning Dev Artifacts and AI CLI Leftovers

The mess Dev Janitor was built to clear

A working developer machine accumulates three different kinds of junk, and they need different handling. The first is build output: node_modules, Rust target directories, logs, caches and temporary files that live inside project folders and can be regenerated. The second is state written by AI coding tools, which is harder to reason about because some of it is disposable session data and some of it is configuration the tool needs. The third is drift in the environment itself: tools installed through several package managers, ports bound to the wrong interface, credentials sitting in plain configuration files.

Dev Janitor targets developers who use more than one AI coding CLI and who do not want to hand-audit dot directories every time disk space runs short. The README frames the scope as keeping a local development machine under control, focusing on "the files, caches, services, and configuration drift that accumulate during everyday work." That is a desktop-app scope, not a server or CI scope, and it shapes everything else about the project.

The distinction that matters most in the cleanup feature is between leftovers and active configuration. The README states that the scanner detects ephemeral leftovers from AI coding tools without flagging active project config files such as .codex/config.toml, .claude/settings.json, .goosehints or .junie/AGENTS.md as junk. Getting that boundary wrong is the failure mode that makes a cleaner dangerous, so it is worth checking on your own projects rather than trusting the list.

How the Tauri 2 shell, React front end and Rust core divide the work

Dev Janitor is built with Tauri 2, React 19 and Rust. The repository layout matches that split: src/ holds the React and TypeScript front end, src-tauri/ holds the Rust core and the Tauri command surface, and scripts/ holds Node validation scripts that run in CI rather than in the shipped app.

The front end is a Vite application. package.json lists React 19, react-dom, i18next with react-i18next for translation, zustand for state, Radix dialog primitives, and four Tauri plugins: @tauri-apps/api, plugin-opener, plugin-process and plugin-updater. The updater plugin is what backs the in-app update flow the README describes, where installed production builds check signed GitHub releases and can download, install and relaunch into an update from inside the app.

The Rust side is where scanning, tool inspection and security checks run. The test script in package.json runs cargo test against src-tauri/Cargo.toml with --locked --no-default-features --lib, which the README explains runs the Rust core tests without compiling the Tauri desktop shell. A separate script, test:rust:full, runs the full Cargo test suite and is the one to use when changing Tauri command wiring. That split tells you the core logic is testable independently of the desktop shell, which is a reasonable architecture for a tool whose risky parts are filesystem scans and process inspection.

One detail worth noting for anyone evaluating the project's maintenance discipline: the README states the AI CLI catalog is checked for local metadata drift on every CI run, and a separate weekly workflow verifies official documentation and package registry endpoints without slowing down pull requests. A catalog of 25 external tools goes stale quickly, so automating that check is the right call. It does not tell you how fast a stale entry gets fixed, only that drift is detected.

Installing Dev Janitor and running a first cleanup

Dev Janitor ships as a desktop application. The README points to the Releases page for every platform, and the latest stable version is published from the v* tag release workflow after a preflight validation pass. There is no package-manager install command documented for end users.

On Windows, the Releases page carries an .msi installer and a portable zip whose name ends in _portable.zip. On macOS, you download the .dmg, and the README warns that the first launch may require Right Click > Open because of Gatekeeper. On Linux, AppImage, .deb and .rpm packages are published.

If you want to build it from source instead, the README lists the prerequisites as Node.js 24 LTS or newer, pnpm 11.15.1 or newer, and Rust 1.97.1. The setup sequence is:

git clone https://github.com/cocojojo5213/Dev-Janitor.git
cd Dev-Janitor
corepack enable pnpm
pnpm install
pnpm tauri dev

After pnpm tauri dev finishes compiling, the desktop window opens. From there the workflow the README describes is: open the cleanup view, point it at a project directory, let it scan, and review the list before removing anything. The scan looks for node_modules, target, logs, caches and temporary files. The AI cleanup view is separate and works per project, covering chat history, cache, session state and debug files. A third view reclaims space from package manager caches, and a fourth inspects development processes and port usage.

Before trusting the cleaner on a real repository, run the validation suite the README documents so you know the checkout you built is sound:

pnpm lint
pnpm validate:release
pnpm build
pnpm test
cargo clippy --manifest-path src-tauri/Cargo.toml --all-targets -- -D warnings

The pnpm test step runs the Rust core tests only. If you changed Tauri command wiring, the README says to use pnpm test:rust:full instead.

The AI tool catalog and its install-channel limits

The tool management feature covers Node, Python, Rust, Go and related ecosystems, and the README says the app can manage 25 AI CLI tools from one interface, naming Codex, Claude Code, Kiro, Factory Droid, Mistral Vibe, Qoder CLI, Pi, OpenCode, Gemini CLI and GitHub Copilot CLI among them. For each tool the app follows the official native install and self-update flow where one exists. Legacy Amazon Q installations are guided through migration to Kiro CLI.

This is the part of the project with the most external dependencies, and the README is explicit that there are limits. It points to docs/UPDATES.md for the update commands, the AI Agent CLI and Pi extension packages involved, and the install-channel restrictions. The package.json scripts include validate:ai-catalog, which runs scripts/audit-ai-catalog.mjs, so catalog correctness is treated as a build concern rather than an afterthought.

The honest reading is that a tool manager for 25 third-party CLIs is only as good as its catalog freshness. If a vendor renames a binary, changes an install path or moves to a different package registry, the app's update path breaks until the catalog is updated. The weekly verification workflow described in the README is the mitigation. It is not a guarantee, and the README does not claim update success rates or list which tools currently fail.

One cleanup detail worth calling out because it shows the level of care: the README states the app cleans official GitHub Copilot CLI session targets without deleting the whole .copilot configuration directory. That is the correct instinct. A cleaner that removes a configuration directory to clear sessions causes a worse problem than the disk space it recovers.

Security scan: what it checks and what it cannot tell you

The security scan is a local configuration audit, not a vulnerability scanner in the dependency sense. According to the README it checks for risky local tool configurations and known vulnerable setups, flags ports that should usually listen on localhost only, detects API keys, GitHub tokens and provider credentials stored in common configuration files, and inspects MCP server configurations for patterns that can lead to credential exposure or SSRF.

The MCP inspection is the most interesting item. MCP server configuration is a common place for credentials to end up in plain text, and server entries that fetch remote resources are where SSRF patterns appear. Flagging those locally, before they reach a shared repository, is a useful check that a linter for application code would not perform.

The limitation is inherent to the approach. A pattern-based scan of configuration files can tell you that a credential-shaped string is present and that a port binding looks wrong. It cannot tell you whether the credential is still valid, whether the service behind the port is exposed beyond your machine, or whether a given MCP server is trustworthy. Treat the output as a list of things to look at, not a verdict. The README does not describe severity levels, suppression rules or a way to mark an accepted finding, so on a machine with many tools you should expect repeated findings that you have already reviewed.

Where Dev Janitor is the wrong tool

Dev Janitor is a desktop application with a graphical interface. That is a deliberate choice and it rules out several workflows. If your cleanup needs to run on a build server, in a container image, or as a pre-commit step, this app does not fit: the README documents no CLI mode and no headless operation. The validation scripts in scripts/ are for release and catalog checking, not for cleaning a machine.

The same applies to teams that want a shared, versioned policy for what counts as a disposable artifact. Dev Janitor scans and presents findings for review. It does not read a checked-in ignore file that your team maintains, and the README does not describe one. If your requirement is "every developer's machine and every CI runner deletes exactly the same paths," you need a different mechanism.

There is also a scope limit on the security side. The scan looks at local tool configuration, ports, credentials in config files and MCP server entries. It is not a dependency vulnerability scanner and the README makes no claim to be one. Installing Dev Janitor does not replace auditing your lockfiles.

Finally, the platform packaging affects adoption. macOS users hit Gatekeeper on first launch and need Right Click > Open, which the README acknowledges. In managed corporate environments where unsigned or unnotarized applications are blocked by policy, that step may not be available to you at all. The README does not state whether the macOS build is notarized, so verify that against the artifacts on the Releases page before planning a rollout.

Alternatives and the difference in approach

For pure artifact deletion, the closest alternative is a dedicated cleaner such as a package-manager cache cleaner or a project-scoped deletion script. The difference is scope and reversibility. A script that removes node_modules and target directories is fast, scriptable and fits CI. Dev Janitor instead scans first, presents what it found across several categories, and keeps the AI tool state, package manager caches, processes and port usage in the same interface. If you only need to reclaim disk space on one machine occasionally, a script is less machinery. If you need to know which of several AI CLIs left session data in a specific project, a general-purpose cleaner has no concept of that.

For the tool management side, the alternative is doing it by hand: each CLI's own installer and self-update command, plus a package manager for the language ecosystems. That approach has no catalog to go stale and no install-channel restrictions to work around, because you are using the vendor's channel directly. What you lose is the single view of what is installed and what is outdated. Dev Janitor's README notes that the tool view distinguishes confirmed up-to-date packages from ones whose updates were not checked, and preserves failure reasons. That distinction is the value: a hand-rolled script usually reports success or silence.

For the security scan, the alternative is a general-purpose secret scanner run over your configuration directories. A secret scanner typically has broader pattern coverage and better suppression controls than a purpose-built desktop audit, and it can run in CI. Dev Janitor's advantage is context: it knows which file belongs to which developer tool and can flag a port binding alongside a credential in the same view. Pick based on whether you want coverage or context.

Licence, maintenance and upgrade cost

Dev Janitor is released under the MIT License, and both the README and package.json state it. MIT is permissive: it allows use, modification and redistribution with the licence and copyright notice retained. It provides no patent grant and no warranty, which matters if you plan to redistribute a modified build inside a company. That is a general property of the licence, not a statement about this project's compliance.

Maintenance signals from the repository are current. The repository is not archived, and the last push was on 2026-09-08, which is the same day as the v2.5.1 release. The release history shows v2.5.0 on 2026-07-21 and v2.4.3 on 2026-06-08, so the cadence across those three releases is roughly six to seven weeks. The README also describes a CI workflow that checks the AI CLI catalog for metadata drift on every run, and a weekly workflow that verifies official documentation and package registry endpoints.

Upgrade cost has two parts. The application itself upgrades from inside the app: the README states installed production builds check signed GitHub releases and can download, install and relaunch into an update. The second part is the catalog of 25 external tools, which moves on the vendors' schedules, not this project's. Expect the tool management view to lag a vendor change until the catalog is updated. The README points to docs/UPDATES.md for the current update commands and install-channel restrictions, and that file is the one to read before relying on the app to update a specific CLI.

Editorial conclusion

Dev Janitor fits developers running several AI coding CLIs who want per-project cleanup and a single view of installed tools, and it is a poor fit for anyone who wants a scriptable command-line cleaner or a CI-side cache policy. Before adopting, check the release artifacts for your platform on the Releases page, confirm the .copilot session handling behaves the way you expect on a test project, and read docs/UPDATES.md to see which install channels the update commands actually cover. The last push to the repository was on 2026-09-08.

Frequently asked questions

Official sources

1. cocojojo5213/Dev-Janitor on GitHub
2. License: MIT
3. Project website
4. README
5. Releases