GO — Healthy across all four use cases

• Last commit today
• 2 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Concentrated ownership — top contributor handles 59% of recent commits
• ⚠ Scorecard: default branch unprotected (0/10)

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests + OpenSSF Scorecard}

Dusty is a free, open-source macOS disk cleanup utility written in Swift that identifies and safely deletes reclaimable disk space (caches, logs, Xcode DerivedData, simulators, package manager artifacts) across three safety levels without deleting user data. It runs as a menu bar application that scans in the background and only deletes from a fixed allowlist, providing visibility into every file before deletion. Two-layer architecture: CleanerEngine (Swift Package at CleanerEngine/) is the core scanning and deletion logic with CleanupTarget abstractions and SafetyValidator guards; Dusty/ (Xcode project) is the SwiftUI/AppKit menu bar frontend that consumes CleanerEngine. Tests live in CleanerEngine/Tests/CleanerEngineTests/ with integration tests (EngineHardeningTests.swift) validating end-to-end safety.

macOS users (especially developers with Xcode, iOS simulators, and package managers) who want a free alternative to CleanMyMac; developers comfortable with Swift and interested in building system utilities or contributing to open-source macOS applications.

Actively developed and production-ready: the project has CI/CD workflows (ci.yml, release.yml), comprehensive test coverage in CleanerEngine/Tests/ with specific test files (SafetyValidatorTests.swift, DeletionBehaviorTests.swift, EngineHardeningTests.swift), signed/notarized releases via Homebrew, and a clear architectural separation between engine and UI. Verdict: mature enough for daily use with active maintenance.

Single-maintainer risk (yagcioglutoprak namespace), but mitigated by MIT license and open-source contribution path (CONTRIBUTING.md present). No vendored dependencies visible in the file list—leverages Swift Package Manager (CleanerEngine/Package.swift), reducing supply-chain risk. System-level file deletion logic requires careful validation, which is evidenced by dedicated SafetyValidator.swift and comprehensive deletion behavior tests.

No recent PR/issue data visible in file list, but the presence of new_target.yml issue template suggests ongoing community requests for new cleanup targets. The DeletionLog.swift and AutoScanPolicy.swift indicate active work on background scanning and audit logging features.

git clone https://github.com/yagcioglutoprak/dusty.git
cd dusty
open Dusty/Dusty.xcodeproj

Then build/run via Xcode (no external dependency management visible—pure Swift Package Manager). Or: brew install --cask yagcioglutoprak/tap/dusty to use the prebuilt binary.

Daily commands: Open Dusty/Dusty.xcodeproj in Xcode and press Cmd+R, or xcodebuild -scheme Dusty -configuration Release from CLI. The menu bar app launches to your macOS menu bar automatically.

• CleanerEngine/Sources/CleanerEngine/CleanerEngine.swift: Core engine orchestrating scans and deletions; entry point for all cleanup operations
• CleanerEngine/Sources/CleanerEngine/CleanupTargetRegistry.swift: Defines and registers all cleanup targets (caches, logs, DerivedData, simulators, etc.); maps safety levels to target groups
• CleanerEngine/Sources/CleanerEngine/SafetyValidator.swift: Critical safety validation pipeline preventing deletion of system or user files; audited by EngineHardeningTests.swift
• CleanerEngine/Sources/CleanerEngine/CleanupTarget.swift: Protocol defining the interface for any cleanup target; all targets (browser caches, Xcode, simulators) conform to this
• CleanerEngine/Package.swift: Swift Package Manager manifest; declares engine as a reusable library consumed by the Dusty app
• CleanerEngine/Tests/CleanerEngineTests/DeletionBehaviorTests.swift: Tests the actual deletion logic to ensure no critical files are removed; critical for production safety
• .github/workflows/ci.yml: Continuous integration pipeline; runs tests and builds on every commit to ensure quality
• .github/workflows/release.yml: Automated release process; handles signing, notarization, and Homebrew tap updates

Adding a new cleanup target: Create a new file in CleanerEngine/Sources/CleanerEngine/ implementing the CleanupTarget protocol (see structure mirrored in CleanupTargetRegistry.swift), add tests in CleanerEngine/Tests/CleanerEngineTests/, update the registry. UI changes: Edit Dusty/Dusty/ Swift files (check xcassets for icon/asset changes). Safety logic: Modify SafetyValidator.swift and write tests in SafetyValidatorTests.swift.

File system sandboxing: The app may require special entitlements to access certain ~/Library/ paths on modern macOS (sandboxing issues). Time Machine snapshots: TimeMachineSnapshotHelper.swift has special logic—removing snapshots requires specific APIs and permissions. Simulator cleanup: SimulatorHelper.swift logic depends on Xcode installation path and simulator state database locations, which can vary. Concurrency: BoundedConcurrency.swift limits parallel scans; monitor performance on large drives. Test isolation: Deletion tests must work in-memory or use temp directories; no obvious test fixtures directory visible.

• Allowlist-based deletion — Dusty's core safety model—only deletes from a pre-approved list of paths rather than pattern-matching; understanding this prevents accidental data loss in SafetyValidator.swift
• Bounded concurrency / semaphore pooling — BoundedConcurrency.swift limits parallel file system scans to prevent I/O thrashing on large disks; critical for responsive UX during background scanning
• Menu bar application (status item) — Dusty lives in the macOS menu bar showing free space in real-time; requires understanding NSStatusBar and app lifecycle, not typical document-based apps
• Swift Package Manager (SPM) modular architecture — CleanerEngine is packaged as an SPM library separate from the UI app; enables reusable, testable core logic and potential CLI tool development
• File system metadata caching / SizeCache — SizeCache.swift avoids redundant file stat() calls during rescans; trade-off between accuracy and performance in disk space calculation
• macOS code signing and notarization — The release.yml workflow signs and notarizes the DMG; required for Gatekeeper bypass on modern macOS and distribution via Homebrew
• Registry pattern (CleanupTargetRegistry) — Dynamically registers cleanup targets by safety level; enables adding new targets (browser caches, app-specific junk) without modifying core logic

• freespace/freespace — Lightweight disk space analyzer for macOS; alternative cleanup approach focusing on visualization rather than automatic deletion
• Homebrew/brew — Package manager that Dusty integrates with (manages homebrew caches); critical dependency for many of Dusty's package manager cleanup targets
• mas-cli/mas — Mac App Store CLI; complements Dusty for managing app updates and cleanup workflows on macOS
• xcpretty/xcpretty — Xcode build output formatter; relevant to developers using Dusty who want cleaner build logs alongside cache cleanup

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for CleanupTargetRegistry and target selection logic

The repo has unit tests for SelectionLogicTests.swift and SafetyValidatorTests.swift, but CleanupTargetRegistry.swift (the core registry managing all cleanup targets) lacks dedicated test coverage. Given the safety-critical nature of file deletion, integration tests ensuring targets are properly registered, prioritized, and selected across different CleanupLevel values would prevent regressions in target behavior.

• [ ] Create CleanerEngine/Tests/CleanerEngineTests/CleanupTargetRegistryTests.swift
• [ ] Add tests for target registration, retrieval by level (Safe/Developer/Deep), and conflict detection
• [ ] Test interaction between CleanupTargetRegistry and SafetyValidator to ensure unsafe targets can't be selected
• [ ] Add tests verifying all cleanup targets are properly initialized and discoverable

Add automated test coverage for DiskSpaceMonitor and SizeCache edge cases

SizeCacheTests.swift exists, but DiskSpaceMonitor.swift (responsible for tracking available disk space) has no dedicated tests. Given the app's core function of monitoring and reclaiming disk space, tests for threshold detection, cache invalidation, and concurrent access patterns would improve reliability.

• [ ] Create CleanerEngine/Tests/CleanerEngineTests/DiskSpaceMonitorTests.swift
• [ ] Add tests for low disk space threshold detection and notifications
• [ ] Add thread-safety tests for concurrent read/write access to disk space data
• [ ] Add tests verifying cache invalidation triggers correctly when space changes

Implement GitHub Actions workflow for building and signing macOS .app releases

The repo has ci.yml and release.yml workflows, but no apparent automated macOS .app build/signing pipeline. The release workflow likely creates a GitHub Release, but contributors and users cannot easily build signed binaries. Adding a workflow to build, notarize, and create a distributable .dmg would match the repository's stated goal of being free and open-source.

• [ ] Create .github/workflows/macos-build.yml with steps to build Dusty.xcodeproj in Release configuration
• [ ] Add code signing for macOS using provisioning profiles or ad-hoc signing
• [ ] Add notarization step using notarytool (required for macOS 13+, as per README badge)
• [ ] Generate .dmg distribution package and upload as release artifact
• [ ] Document build prerequisites (Xcode version, signing certificates) in CONTRIBUTING.md

• Add tests for SizeCalculator.swift (visible in file list but no corresponding test file)—implement unit tests covering edge cases like symlinks, hard links, and zero-byte files
• Document the CleanupTarget protocol with inline examples in CleanupTarget.swift; add a code sample showing how to implement a new target (e.g., custom app cache)
• Create integration tests for the AutoScanPolicy.swift background scanning policy (tests exist but may be incomplete)—cover timer behavior, policy switching, and scan interruption

Dusty appears to be a well-structured macOS cleaning utility with a security-conscious architecture (SafetyValidator, DeletionLog, test suites). However, the security posture cannot be fully assessed without reviewing actual source code contents. Primary concerns are: (1) insufficient visibility into dependency security, (2) unvalidated file system operations that could enable symlink attacks or path traversal, (3) potential privilege escalation risks from cleanup operations, and (4) incomplete security policy documentation. The project demonstrates good security practices through dedicated safety validators and comprehensive testing, but implementation details require code-level review. Recommend: code audit focusing on file operations, dependency scanning, and enhanced security documentation.

• Medium · Missing SECURITY.md Policy Details — .github/SECURITY.md. The repository contains a .github/SECURITY.md file, but its actual content was not provided for review. Security policy files should clearly outline vulnerability disclosure procedures, supported versions, and responsible disclosure guidelines. Fix: Ensure SECURITY.md contains: (1) Clear vulnerability reporting instructions, (2) Expected response timeframes, (3) Supported versions receiving security updates, (4) PGP key for encrypted reports if applicable.
• Medium · Insufficient Dependency Visibility — CleanerEngine/Package.swift. The Package.swift file content was not provided for analysis. Swift Package Manager dependencies could contain vulnerable libraries or unmaintained packages that pose security risks. Fix: Review and provide Package.swift contents. Implement: (1) Dependency pinning with specific versions, (2) Regular dependency audits using Swift package security tools, (3) Automated dependency update checks in CI/CD.
• Low · File System Operations Without Validated Safety — CleanerEngine/Sources/CleanerEngine/SafetyValidator.swift, DeletionLog.swift, SimulatorHelper.swift. Files like SafetyValidator.swift, DeletionLog.swift, and SimulatorHelper.swift suggest file system operations. Without code review, potential risks include: race conditions during file deletion, symlink following attacks, or improper permission validation. Fix: Implement: (1) Proper symlink attack mitigation (use O_NOFOLLOW flags), (2) TOCTOU (Time-of-Check-Time-of-Use) protection, (3) Validate all paths before deletion, (4) Use proper file system APIs with safety guarantees.
• Low · Insufficient Input Validation in Cleanup Targets — CleanerEngine/Sources/CleanerEngine/CleanupTarget.swift, CleanupTargetRegistry.swift. The CleanupTarget.swift and CleanupTargetRegistry.swift files handle configuration of cleanup paths. If user-configurable paths aren't properly validated, malicious inputs could target critical system files. Fix: Implement strict validation: (1) Whitelist allowed cleanup directories, (2) Reject paths to critical system locations, (3) Validate against bypass attempts (../, symlinks), (4) Add path normalization.
• Low · Potential Privilege Escalation Risk — CleanerEngine/Sources/CleanerEngine/CleanerEngine.swift, DiskSpaceMonitor.swift. macOS disk cleanup operations may require elevated privileges. The absence of explicit privilege boundary checks in visible code suggests potential elevation of privilege (EoP) risks. Fix: Ensure: (1) Minimal necessary privileges are requested, (2) Operations don't exceed privilege scope, (3) Use XPC services for privilege separation, (4) Audit all root-level operations.
• Low · Missing Test Security Coverage — CleanerEngine/Tests/CleanerEngineTests/. Test files exist but their content wasn't provided. Security-critical tests for deletion safety, validation logic, and edge cases may be incomplete. Fix: Ensure comprehensive test coverage: (1) SafetyValidator and DeletionBehavior tests cover bypass attempts, (2) Path validation tests include edge cases, (3) Concurrency tests validate thread safety, (4) Add fuzzing for configuration inputs.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/yagcioglutoprak/dusty shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live yagcioglutoprak/dusty repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/yagcioglutoprak/dusty.

What it runs against: a local clone of yagcioglutoprak/dusty — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in yagcioglutoprak/dusty | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of yagcioglutoprak/dusty. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/yagcioglutoprak/dusty.git
#   cd dusty
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of yagcioglutoprak/dusty and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "yagcioglutoprak/dusty(\\.git)?\\b" \\
  && ok "origin remote is yagcioglutoprak/dusty" \\
  || miss "origin remote is not yagcioglutoprak/dusty (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/yagcioglutoprak/dusty"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.