Rules

The real fear isn't wasted space, it's losing work. That's what Devbroom's rules are for, and none of them is a setting.

Scanning only reads

Scanning doesn't change a single file. Unless you set a rule to “Do it by itself” in Automatic upkeep, nothing is touched that you haven't seen in the preview and confirmed.

Every verdict comes with a reason

No item is Ready or Blocked without a reason. Each verdict's reasons are shown beside the item, and on the command line with --details.

Blocked and Unknown can't be selected

This is a limit, not a preference. Review items are cleaned only with “Include anyway”; on the command line that's --include-review, and it asks for confirmation in the terminal.

Checked again right before deleting

When you press Clean, every item is checked again against the processes running at that moment. An item whose verdict or contents changed since the scan is left alone, and you're told why it was skipped.

Trash first

The Trash is the default, and every item can be put back from History. Deleting permanently is a separate choice, confirmed by holding its button; your organization can turn it off. Space moved to the Trash doesn't count as freed until you empty the Trash.

Worktrees: never --force

  • A worktree with uncommitted changes, or untracked or staged files, is Blocked. Git won't remove it without --force; Devbroom never uses --force.
  • Ignored files make it Review, because git worktree remove deletes them without asking.
  • Unpushed commits on a branch stay when the worktree is removed; on a detached HEAD they wouldn't. So before removing, Devbroom saves the HEAD under refs/devbroom/removed; if it can't, it doesn't remove.
  • There are only three worktree actions: remove (remove), prune (prune) and repair (repair).

Hands off running work

If an agent session runs in that folder or its parent, a process runs from it, or a file in it is held open, the item is Blocked. For build folders, a session running in the parent folder makes it Review.

Devbroom never touches the processes of a running agent session. It asks processes agents left behind to quit only when you say so, and only after checking again; never system processes or other users' processes.

A name isn't enough

A folder's name alone is no evidence:

Folder To be Ready
node_modules A package.json beside it
.next A Next.js config or package.json beside it
.turbo A turbo.json or package.json beside it
target Cargo's marker inside (CACHEDIR.TAG)
.venv A pyvenv.cfg inside
DerivedData Xcode's files inside
dist, build, vendor A project file beside it, and a build script that produces it

Without the marker the folder stays Review. It must also be a folder git ignores, with no file inside that git tracks.

Real size

Space shared with other folders through hard links and APFS clones (as pnpm does) isn't counted. The number you see is what deleting frees. Symbolic links aren't followed, and mounted volumes are skipped.

The agent's own way

Agent databases and credentials are never touched. When an agent has its own cleanup command, that's the way it's done or shown to you. Claude Code's history is either deleted with claude purge or archived: the conversations are first written to an archive in Devbroom's folder and verified against the originals, and only then moved to the Trash; the project's memory (memory/) stays in place, and the archive can be reopened from History. For Codex sessions, codex delete is shown. Other agents' sessions are only read.

Everything on your Mac

No account, no telemetry; nothing about you is sent. The app checks for updates; if you enter a Pro license it activates it once and quietly checks it again about once a month (the license key and your Mac's name only). Without a license, the update check is the only network request. From session logs it takes only token counts and model names; searching sessions reads the logs at that moment, keeps no index or log, and hides strings that look like secrets in excerpts. Details on the Privacy page.

Last updated: October 7, 2026