开发机最容易积累的东西，不是单个大文件，而是一层一层的小残留：多个项目里的 node_modules、Rust target、临时日志、包管理器缓存、AI coding 工具写下的聊天历史、调试文件和项目级配置。它们单独看都合理，堆在一起之后，就会变成磁盘占用、PATH 混乱、端口冲突和本地凭证暴露风险。

今天推荐的 cocojojo5213/Dev-Janitor 是一个把这些问题放到同一个桌面界面里的工具。它用 Tauri 2、React 19 和 Rust 构建，目标是清理开发产物、管理本地开发工具，并检查常见环境问题。GitHub 搜索页当前显示项目约 841 stars、56 forks，主要语言为 Rust，许可证为 MIT，仓库创建于 2026 年 1 月，最近更新在 2026 年 6 月，最新 tag 为 v2.4.1。

项目概览

属性详情
仓库cocojojo5213/Dev-Janitor
定位跨平台开发机清理、工具管理和环境检查桌面应用
Stars约 841
Forks56
主要语言Rust
桌面栈Tauri 2 / React 19
许可MIT
最新 tagv2.4.1

它解决的是“开发机卫生”问题

很多清理工具会把重点放在系统缓存、浏览器缓存或下载目录上。Dev Janitor 的角度更偏开发者日常：扫描项目目录里的开发产物，识别不同语言生态的缓存和构建输出，再让用户按项目、按类型决定是否删除。

README 里明确提到的扫描对象包括 node_modules、target、日志、缓存和临时文件。这些目录在活跃开发时很正常，但当项目已经归档、分支已经切走、依赖已经重装多次之后，它们就会长期占住空间。手动用 du 或资源管理器查当然可以，只是跨几十个仓库时很容易漏。

Dev Janitor 的价值不在于“自动删除一切”，而在于把这些开发残留变成可审查的列表。对开发机这种状态复杂的环境来说，先看清楚再删，比盲目清理更重要。

AI coding 工具残留被单独拿出来

这个项目最有当下感的一点，是把 AI coding 工具产生的本地残留作为独立清理对象。README 提到它会检测 AI coding tools 的临时残留，同时避免把活跃项目配置文件误判为垃圾，比如 .codex/config.toml 或 .claude/settings.json。

这条边界很关键。AI 工具现在经常在项目内或用户目录里留下会话、缓存、调试日志、工具状态和规则文件。如果只按文件名粗暴匹配，确实可能把还在使用的 agent 配置删掉。Dev Janitor 的表述更谨慎：它关注 chat history、cache、debug files，并按项目维度让用户审查。

我会把它理解成“清点和整理 AI 工具足迹”，而不是安全擦除工具。真正涉及机密的历史记录，仍然应该按团队策略处理：先确认内容类型，再决定清理、归档或轮换相关凭证。

工具管理覆盖主流开发生态

Dev Janitor 还提供 tool management。README 里列到的范围包括 Node、Python、Rust、Go 以及相关生态，可以查看已安装工具、版本，并更新常见全局包。

更具体的是，它把 Codex、Claude Code、Cursor、Gemini CLI、Aider、Continue、Kiro、iFlow、OpenCode、GitHub Copilot CLI、Qwen Code、Cline、Amp、Crush、Amazon Q Developer CLI 等 AI CLI 工具也放进同一个界面。这不是要替代各自的包管理器，而是给开发者一个总览：本机到底装了哪些 agent 工具，版本是否明显落后，是否有重复或废弃安装。

对经常试新工具的人来说，这类视图很有用。问题通常不是不知道怎么安装，而是几个月后已经忘了自己装过什么。

本地安全扫描偏向实用风险

Dev Janitor 的 security scan 也不是传统意义上的代码漏洞扫描。它更关注开发机本地配置风险：常见配置文件里是否保存了 API keys、本应只监听 localhost 的端口是否暴露、MCP server 配置里是否存在可能导致凭证暴露或 SSRF 的模式。

这类检查很适合作为“开发机体检”。现在很多工具都在本地跑 HTTP server、MCP server、browser automation endpoint 或 agent bridge。只要有一个服务绑定到了不该暴露的地址，或者某个配置文件把 token 留在了项目目录里，风险就会从单机问题变成网络可达问题。

当然，这不等于它能覆盖所有安全问题。更稳妥的姿势是把它当作快速提醒层：发现可疑项后，再回到具体工具文档和团队安全策略里确认。

系统工具解决端口和 PATH 这类小烦恼

README 还列了几类系统实用功能：查看长时间运行的开发进程、定位某个端口被哪个进程占用、检查 PATH 和 shell 配置问题，包括 Windows system/user PATH 持久项。

这些功能单独用命令都能完成。比如 lsof、netstat、PowerShell、任务管理器和 shell 配置文件都能查。但把它们放在同一个桌面工具里，适合处理“今天这台机器哪里不对劲”的场景：端口被占、命令找不到、全局工具版本错了、缓存异常膨胀、AI CLI 留下一堆历史文件。

Dev Janitor 的定位更像开发机控制面板，而不是某个单点命令行工具。

安装和开发状态

项目在 Releases 页面提供 Windows .msi 和 portable zip、macOS .dmg、Linux AppImage、.deb 和 .rpm。这说明它不是只给源码用户准备的工具，而是希望普通开发者直接下载使用。

如果要参与开发，README 给出的本地栈是 Node.js 24 LTS+、pnpm 11.5.0+ 和 Rust 1.95.0，启动命令是：

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

验证命令覆盖前端构建、Rust 格式检查、测试、clippy 和 Windows GNU target 的 cargo check。对于一个会触碰本地文件、端口、PATH 和工具配置的桌面应用来说，这种验证范围是必要的。

适合哪些人

Dev Janitor 更适合这些开发者：

  • 经常在同一台机器上维护很多前端、Rust、Go、Python 项目。
  • 经常试用 AI coding CLI，想知道它们在本机留下了什么。
  • 想按项目清理缓存、构建产物和日志，而不是一键扫全盘。
  • 想快速检查本地端口、PATH、全局工具版本和常见凭证暴露风险。
  • 需要一个跨平台桌面界面，不想每次都拼命令。

如果你的开发机项目很少，或者已经有固定的 dotfiles、包管理和清理脚本，Dev Janitor 可能不会替代现有流程。但它仍然可以作为一次性审计工具，用来发现被忽略的残留和配置漂移。

使用时需要保留的谨慎

第一，不要把清理工具当成自动化删除器。尤其是 node_modules、target、缓存和 AI 会话文件，有些可以重建，有些可能正在被任务使用。删除前应该看清路径和项目状态。

第二，安全扫描结果应该视为提示，不是最终判定。API key、MCP 配置、端口绑定这类问题，需要结合具体工具和网络环境确认。

第三，项目更新很快。GitHub 元数据显示它创建于 2026 年 1 月，当前最新 tag 已到 v2.4.1。把它放进日常流程前，建议固定一个版本，先在非关键目录试用，确认扫描规则符合自己的工作方式。

总结

cocojojo5213/Dev-Janitor 把开发者机器上那些分散的小问题收拢到一个桌面应用里：开发产物清理、AI 工具残留、全局工具版本、本地端口、PATH 和配置风险。它不追求替代 du、lsof、包管理器或安全扫描器，而是提供一个面向日常维护的审查入口。

我喜欢它的地方在于边界比较清楚：先扫描、先展示，再让用户决定是否清理。对已经频繁使用 AI coding agent、MCP server 和多语言工具链的开发者来说，本地环境的复杂度正在上升。Dev Janitor 正好切中了这类“开发机需要定期体检”的需求。

项目地址：https://github.com/cocojojo5213/Dev-Janitor