Find the stale developer junk on your machine — branches, worktrees, build artifacts, Docker, caches — and prune only what you can afford to lose.

_{One real run on one real machine: 33.8 GB reclaimable, sorted by what it costs to lose it.
f narrows to the safe tier, R 1 takes all of it — 4.13 GB, none of it work.}

Agents changed how fast a machine fills up.

A branch per idea. A worktree per agent, so three of them can build at once without tripping over each other. A container to check it against. A node_modules and a target inside every one of those worktrees, because each is a real checkout. Work that used to take a week of branches now takes an afternoon — and leaves the same debris behind, at ten times the rate.

A month later there are two hundred branches, a dozen worktrees, and 80 GB you cannot account for. Some of it is genuinely finished. Some of it is the only copy of an afternoon's work. They look identical, and that is why the disk never gets cleaned: the cost of guessing wrong is worse than the disk being full.

reap evaluates the cases it knows how to prove, and shows the rest as decisions rather than pretending to be a universal disk oracle.

╭──────────────────────────────────────────────────────────────────────────────────────────────╮
│ reap  298 items found                                                    54.7 GB reclaimable │
│ ● 20.3 GB safe   ● 31.4 GB rebuildable   ▲ 2.98 GB irreversi… 162 GB free of 494 GB → 217 GB │
╰──────────────────────────────────────────────────────────────────────────────────────────────╯
╭─ Categories ─────────────────────╮╭─ Everything · biggest first (298) ───────────────────────╮
│   Everything (298)       54.7 GB ││ ◉ BuildKit cache (all reclaimable)      4d    19.1 GB  ● │
│  ─────────────────────────────── ││   $ docker builder prune --all --force                   │
│ ▸ Git (200)               285 MB ││ ○ NuGet global packages                 1d    8.87 GB  ● │
│  ─────────────────────────────── ││   ~/.nuget/packages · every restored .NET package — re-… │
│ ▸ Build artifacts (20)   12.0 GB ││ ○ JetBrains                             4d    3.27 GB  ● │
│  ███████──────────────────────── ││   ~/Library/Caches/JetBrains · rebuilt by the owning app │
│ ▸ Docker (70)            25.5 GB ││ ○ com.microsoft.VSCode.ShipIt           3d    1.57 GB  ● │
│  ██████████████───────────────── ││   ~/Library/Caches/com.microsoft.VSCode.ShipIt · rebuil… │
│ ▸ Caches (8)             16.8 GB ││ ○ mongo:latest                          3d    1.13 GB  ● │
│  ██████████───────────────────── ││   no containers · 1.27 GB total, 142 MB shared with oth… │
╰──────────────────────────────────╯╰──────────────────────────────────────────────────────────╯
╭──────────────────────────────────────────────────────────────────────────────────────────────╮
│ ◉ 1 selected · frees 19.1 GB     R quick · space pick · a all · / find · d reap · ? help     │
╰──────────────────────────────────────────────────────────────────────────────────────────────╯

On a real machine this took 189 branches that all looked equally scary and reduced them to 10 that actually needed a decision.

brew tap woksin/reap
brew trust woksin/reap   # Homebrew 6 gates third-party taps
brew install reap

# macOS, Apple silicon
curl -fsSL https://github.com/woksin/reap/releases/latest/download/reap-macos-arm64.tar.gz | tar xz
# Linux, x86_64
curl -fsSL https://github.com/woksin/reap/releases/latest/download/reap-linux-x86_64.tar.gz | tar xz

sudo mv reap /usr/local/bin/

Invoke-WebRequest https://github.com/woksin/reap/releases/latest/download/reap-windows-x86_64.exe -OutFile reap.exe

cargo install --git https://github.com/woksin/reap

git and docker are used if present and skipped if not.

reap guide

The same walkthrough ? shows inside the interface: what the five categories are, what the risk levels mean, how selection works, and what happens when you press d.

reap update

reap works out how it was installed from where its binary sits, and hands the job to whoever put it there — brew upgrade reap, or cargo install --force. A binary you placed by hand is left alone: it prints the two lines that would replace it rather than overwriting something in /usr/local/bin behind a sudo you did not ask for.

The interface says so in the footer when a release is out. That check runs on its own thread, gives up after five seconds and remembers the answer for a day, so it is never the reason reap feels slow — and it stays quiet when there is no terminal to read it, so it cannot end up in a cron log or in --json. REAP_NO_UPDATE_CHECK=1 turns it off entirely.

reap --list    # see what it finds and how risky each item is; changes nothing
reap           # open the interface, pick, and reap
reap guide     # the walkthrough, in your terminal

reap                      # scan and open the interface
reap --list               # print findings and exit
reap --dry-run            # interface, but deletion is simulated
reap --trash              # move paths to the Trash instead of deleting them
reap -p ~/work -p ~/oss   # scan specific directories
reap --stale-days 90      # require 90 days where an age can be measured
reap --min-size 100MB     # hide the small fry
reap --no-inventory       # skip the read-only occupied-space catalogue
reap --no-docker          # skip the Docker scan
reap --no-agents          # skip agent caches, packages and session history
reap --no-personal        # skip downloads, installers and device backups
reap --no-cache           # re-measure everything instead of reusing sizes
reap --ignore '*/vendor'  # skip anything matching, without editing the config
reap --write-config       # write a documented starter config

With no --path, reap looks in the usual places under $HOME: repos, src, Developer, Projects, code, dev, work, git, and the two the Windows tooling picks by default — source/repos and Documents/GitHub. It also probes those exact names and direct child Git checkouts below local mounted volumes, such as /Volumes/sourcecode/repos and /Volumes/sourcecode/reap; it does not recursively walk /Volumes, network mounts, or arbitrary external-drive contents.

Once you are in, / narrows the list as you type — across every category at once, so one query reaches docker's build cache and a package manager's on the same screen:

reap --json                              # findings as JSON, for anything that decides for itself
reap --reap                              # print the plan and change nothing
reap --reap --yes                        # take everything safe
reap --reap --risk rebuildable --yes     # raise the ceiling
reap --reap --recipe d --yes             # whatever the `d` recipe covers

--reap defaults to --risk safe and does nothing at all without --yes. The interface makes you look at the selection and type a word for the irreversible; neither exists here, so the deliberate act is the flags — --yes to touch anything, and a ceiling that has to be raised by hand before work can be lost. Failures come back as a non-zero exit, so a cron job that half-worked says so.

0 4 * * 1  /usr/local/bin/reap --reap --recipe d --yes >> ~/.local/state/reap.log 2>&1

After the first couple of runs, the ticking is the same ticking. R opens the recipes:

╭ Quick reap ────────────────────────────────────────────────────────────╮
│                                                                        │
│   1  Everything safe                            412    18.2 GB         │
│   2  Everything but the irreversible            451    46.4 GB         │
│   3  Absolutely everything                      503    49.0 GB         │
│ ▸ g  Git · branches already upstream            160     285 MB         │
│   w  Git · worktrees with nothing in them         5     170 MB         │
│   G  Git · everything it can spare              181     455 MB         │
│   b  Build artifacts                             20    12.0 GB         │
│   d  Docker · safe                               41    21.2 GB         │
│   D  Docker · everything but the volumes         66    25.5 GB         │
│   c  Caches                                       8    16.8 GB         │
│   A  Coding agents · caches and packages         11    1.31 GB         │
│   a  Apps · what they will simply rebuild        34    9.28 GB         │
│                                                                        │
│   merged and squash-merged · already in the integration branch         │
│   a key runs it · ↑↓ move · enter run · esc back                       │
╰────────────────────────────────────────────────────────────────────────╯

Every recipe shows what it would take before you press it, and the highlighted one says what it leaves behind.

A recipe only selects. It drops you into the same confirm dialog as ticking by hand — same risk split, same typed acknowledgement when anything irreversible is in there. One key is a shortcut through the tedium, never through the safety.

And they are yours to define:

[[recipe]]
key = "n"
name = "Node · every node_modules"
detail = "pnpm install brings them all back"
match = ["build artifacts/node_modules"]
max_risk = "rebuildable"

[[recipe]]
key = "p"
name = "This project only"
match = ["~/work/big-monorepo/*"]
max_risk = "rebuildable"

match takes the same patterns as ignore, so a pattern learned in one place works in the other. Reuse a built-in key and yours takes it over.

Branches and worktrees are not merely listed. reap checks whether their work is reachable from the integration branch or a remote, and groups them by the evidence it can establish.

_{Four groups, four different answers. The last one holds commits that exist in this clone and nowhere else, and every entry says how many and where the upstream went.
Filmed against a throwaway fixture — invented branches, but real repositories with real remotes, and every verdict reached the way it would be on yours.}

Worktrees are judged by what git worktree remove actually destroys. An attached branch survives removal, so commits on that branch remain reachable even when they were never pushed. A detached HEAD must be named by another ref or it is irreversible. Modified and untracked files are irreversible; ignored paths recognised as generated build output are rebuildable, while unknown ignored paths such as .env remain irreversible. Locked worktrees are catalogued as protected. Immediately before removal reap checks HEAD and the full status again; for a rebuildable detached HEAD it also proves a containing ref still exists. Any changed premise aborts the removal and requires a rescan.

▲ Screenplay.Generation: ~/.cache/pi-worktrees/Generation-bare-specification-rejection
  [fix/bare-specification-rejection] 22 ignored files may exist only here; commits are all pushed

[[override]]
match = ["~/.vscode/extensions"]
risk = "rebuildable"

$ stat -f '%Sm' ~/.pi/agent/sessions/--Volumes-sourcecode-repos-cratis-Strategy--
Aug 24 22:17:25          # the directory
Aug 24 22:39:39          # the transcript inside it, still being written

▲ Claude Code · Chronicle      2mo   443 MB   /Volumes/sourcecode/repos/cratis/Chronicle · every session for that project · nothing written for 2mo
▲ pi · Screenplay-esm-kernel   5mo  3.71 MB   no directory of that name is on this machine now — deleted, renamed, or on a volume that is not mounted · nothing written for 5mo

Every candidate carries a risk level, shown as a coloured dot and used by the confirm dialog:

Selecting anything irreversible locks the confirm button until you type reap. Press s to select everything except those.

_{R 3 selects absolutely everything. The dialog comes up red, enter reads locked, and it stays that way until the word is typed out — then this one backs out with esc instead. Recorded with --dry-run, which is why it says so.}

Beyond that:

• A recursive delete refuses any path fewer than three components deep, $HOME itself, and the system directories and everything inside them — whatever the scanners produce.
• That refusal is re-checked against where the path actually leads, not merely how it is spelled. The leaf is never followed — a symlink is unlinked rather than descended — but the kernel resolves the ancestors, so a redirected ~/.cache would otherwise let a cache sweep delete whatever it points at while the path still reads as ordinary. The resolved answer can only ever add a refusal, never grant one.
• Linked worktrees share one object store with their main worktree, so each set is collapsed to a single repository. Otherwise every branch, stash and gc gets reported once per checkout.
• git gc runs without --prune=now. reap also deletes branches, and pruning immediately would throw away the reflog that makes those recoverable.
• Branch deletion pins the scanned OID and the exact ref/tip supporting its recoverability grade. After rechecking the proof, one git update-ref transaction verifies that proof ref and expected branch OID while deleting, so neither can move through a stale row.
• Stashes remain visible but protected/manual. Git identifies them by mutable reflog positions and exposes no atomic compare-and-drop operation for an arbitrary entry, so reap refuses to risk deleting a different stash after concurrent activity.
• Overlapping selections are removed shallowest-first, and anything already taken by a parent is skipped rather than counted twice.
• A cache whose owner is running is kept, and says which one. A few caches are not merely rebuildable but live: removing a package manager's store mid-resolve corrupts an operation already in flight instead of costing a re-download, and the failure surfaces inside the other tool a long way from the cause. owner on a rule names the programs that mean this. Not knowing is not idle — if the process table cannot be read, reap keeps the cache and says that is why, the same way an unreadable Docker size is reported as unknown rather than as zero. Most rules name no owner; browsers deliberately do not, since a render cache is genuinely disposable.
• A locked git worktree is never offered.
• esc does not quit. Leaving a tool that deletes files should take a specific keystroke.

With --trash, path removals are renamed into the volume's trash instead of unlinked, making them recoverable from Finder. macOS keeps a separate trash per volume — ~/.Trash for the boot volume, <mount>/.Trashes/<uid> for the rest — and a rename cannot cross filesystems, so reap picks the directory by device id. Two APFS volumes sharing one container are still separate filesystems here.

Every project has a node_modules and every Downloads folder has a setup.dmg, so trash names collide constantly. reap reserves the free name rather than testing for one: removals run concurrently and all of them rename into the same directory, and rename replaces a file without a word. Two items of the same name trashed at once both survive, under distinct names.

If a path cannot be trashed, reap reports the failure rather than silently falling back to an unrecoverable delete.

--trash applies only to filesystem path removals. Command actions — Git branch and worktree operations, Docker prune/remove commands, and tool-specific cache cleaners — run normally and do not become recoverable merely because --trash is present.

Per-item figures are measured directory sizes, so the total is an estimate. The report also states what free space actually did, read from the filesystem before and after. The two differ when items were trashed, when something failed, or when sizes drifted since the scan.

The built-in rule tables are exposed to the configuration layer. Which directories count as build output, which caches are worth offering, what never to descend into, and which key reaps what can all be extended, disabled, replaced or re-graded through ~/.config/reap/config.toml (or $XDG_CONFIG_HOME).

reap --write-config     # documented starter file

Command-line flags override the config, which overrides the defaults.

All of that was configurable and almost none of it was visible. Dozens of cache and build rules, the recipes and scan thresholds decide what you are shown, and the only way to read any of it was to open the source. C puts the whole lot on one screen:

╭─ Configuration ──────────────────────────────────────────────────────────────────────────────╮
│                                                                                              │
│  ▾ Where to look (1)              directories searched for repositories and build output     │
│     ~/work                                                                          yours    │
│     + a directory to search                                                                  │
│  ▾ Scanning (9)                   thresholds, and which scanners run at all                  │
│     stale after      90 days      days untouched before something counts as stale   yours    │
│     hide anything under  1MB      the floor under everything reap reports        built-in    │
│     scan your own files  off      downloads, installers, device backups             yours ✗  │
│  ▾ Caches (85)                    a path, what clears it, and what it costs to lose          │
│     my own cache                     ~/.cache/mine    rebuildable                   yours ✓  │
│     npm cache                    ~/.npm/_cacache      safe                       built-in ✓  │
│  ▸  Firefox cache        ~/Library/Caches/Firefox     safe                       built-in ✗  │
│     NuGet global packages          ~/.nuget/packages  safe ✎                     built-in ✓  │
│  ▸ Never offer (2)     ▸ Re-graded (1)     ▸ Quick reaps (12)                                │
╰──────────────────────────────────────────────────────────────────────────────────────────────╯
  x on/off · g re-grade · a add · L legend · esc back    every change is written as you make it

Every row says where it came from and whether it is on. e changes a path, pattern or value; n renames a rule of yours; a adds one; x turns a rule off and turns it back on; g re-grades what something costs you; d deletes something you added.

Changes are written as you make them, in the same shapes a hand-written config uses — an ignore, an [[override]], a [[cache]]. Nothing learned here stops being true at the command line, and a file you wrote by hand is edited in place rather than replaced.

This is also what makes x reversible. It used to write a line to a file nobody was looking at; now there is a screen to take it back on.

Patterns match against a candidate's path, its label, and its category/group. * matches any run of characters, and a pattern with no wildcard also matches everything beneath it.

The path matched is the tree the candidate affects, not the mechanism reap would use on it — so naming a directory protects it whether reap would unlink it, run git worktree remove on it, or hand it to the owning tool's own cache cleaner.

ignore = [
  "~/.nuget/packages",       # one cache, always
  "*/vendor",                # any vendor directory, anywhere
  "git/unpushed branches",   # a whole group
  "docker/unused volumes",
]

Pressing x on a candidate appends the right pattern and writes the file — a path when there is one, so the rule survives a rename, otherwise the group.

An absolute pattern is also matched with its symlinks resolved, so a directory reached through a link can be protected by the name you actually reach it by. reap canonicalises its scan roots — ~/src -> /Volumes/sourcecode is scanned once, not twice — so a finding reports the resolved path while you would naturally write ~/src/…. Both spellings protect it.

[[artifact]]
dir = "my-build-output"
evidence = ["Makefile"]       # sibling files proving what it is
regen = "make"
risk = "rebuildable"          # safe | rebuildable | irreversible

[[cache]]
path = "~/.cache/my-tool"
label = "my-tool cache"
detail = "re-downloaded on next run"
risk = "safe"
prune = ["my-tool", "cache", "clean"]   # run this instead of deleting
owner = ["my-tool"]                     # keep it while this is running

evidence is what keeps the artifact rules honest — without it, any directory sharing the name would match. These entries add to the built-ins; set replace_builtin_artifacts, replace_builtin_caches or replace_builtin_recipes to use only your own.

The built-in risk levels are one person's judgement. A cache you re-download over a fast link is safe to you; a stopped container you are keeping to debug is not. Risk is what s and the recipes select by, so correcting it is what makes those keys fit rather than nearly fit.

[[override]]
match = ["caches/*"]           # same patterns as `ignore`
risk = "safe"

[[override]]
match = ["~/.cache/precious"]  # the last matching rule wins, so exceptions go below
risk = "irreversible"

Ignoring beats re-grading: something you said never to offer stays unoffered.

macOS, Linux and Windows, tested on representative targets for all three in CI. That means the supported code paths build and run in CI; it does not mean every filesystem layout, vendor cache location or enterprise policy is known.

Rules naming a path a machine does not have simply do not apply, so one rule set covers all of them — the Xcode entries are inert on Linux, the %LOCALAPPDATA% ones anywhere that is not Windows. Not ~/.cache, which this used to claim was the Linux answer: a great deal of developer tooling is cross-platform first and writes there whatever the platform's own convention is, so it is swept on macOS too. A cache rule's path takes ~ for your home directory and %VARIABLE% for an environment variable, which is the whole of the branching. The pieces that genuinely differ:

The guards that refuse to recursively delete a system directory are written per platform rather than shared, because they are the one place a wrong answer is unrecoverable: /usr, /System and friends on unix; C:\Windows, Program Files, ProgramData and $Recycle.Bin on Windows, along with a depth floor that accounts for the drive letter being a component of its own.

reap has two deliberately separate layers. Disk usage is a read-only, coarse catalogue of host-allocated bytes under the home directory, conventional source roots, mounted local source volumes, and several platform data roots. Reclaim findings remain curated and carry the evidence and action required to remove something safely. Ordinary source, application state and unknown data can therefore explain the disk without acquiring a delete button.

Repository and artifact discovery starts in the conventional roots listed under Use, including conventional directories directly below local mounted volumes, and stops at the configured depth. It recognizes bare repositories, linked worktrees, submodules and nested or hidden checkouts that fall within those roots, but does not cross symlinked directories, network mounts, or directories it cannot read.

Artifact and cache detection comes from finite rule tables plus the configurable unnamed cache sweep. New toolchains, renamed vendor directories, network storage, cloud-only data, arbitrary temporary folders and files outside those roots are not automatically covered. Docker findings come from the Docker CLI's current context and the builder/system view it reports; Podman, containerd and other runtimes are outside this scanner.

stale_days controls eligibility, not visibility. Recognised bytes below the threshold remain visible as recent but cannot be selected. Active and protected rows work the same way. Some objects, notably Docker volumes and dangling networks, do not expose an age in the data reap reads; they remain eligible with unknown age rather than being quietly called recent. Permissions, unavailable Git remotes and absent tools are surfaced as coverage/protected rows instead of silently contributing zero.

Selecting a whole group is a with that group highlighted in the sidebar — the item list is already narrowed to it.

The header separates catalogued usage, recent recognised data, and reclaimable bytes. The risk split applies only to selectable reclaim findings. system/unclassified is the storage pool's occupied bytes not accounted for by readable inventory rows; APFS snapshots, protected system data, permissions and catalogue floors can all contribute.

Nested opportunities are assigned once. A worktree containing node_modules, bin and obj no longer promises the whole worktree plus all three children. Selection totals use the union of affected paths, including command actions such as git worktree remove.

The tree opens on Everything, one cross-category list sorted biggest-first. A highlighted selectable row swaps its description for the exact command that will run; usage, recent, active and protected rows keep their explanation because they have no action.

Sizes are SI — 1 GB is 1000³ bytes — matching macOS and docker system df, so figures can be compared against those directly. This differs from du -h, which is 1024-based and reads about 7% smaller for the same bytes.

Reclaim findings use logical file lengths because that is the portable estimate associated with deleting a path. Read-only inventory uses allocated blocks, so a sparse 1 TB Docker.raw is shown as the tens of gigabytes it occupies rather than as a terabyte. Docker daemon figures remain logical estimates supplied by Docker; its host backing-store row explicitly links to them and the two totals must not be added. Docker Desktop may also compact sparse storage later rather than returning every logical byte immediately.

The interactive disk projection is shown only when every non-empty selectable finding has a host path in the current stable storage-pool identity. A different filesystem, unreadable path, or pathless logical resource such as Docker suppresses the combined projection. The system/unclassified remainder is likewise shown only when every catalogued local mount is in one pool. JSON attributes each candidate from its actual footprint, emits per-filesystem projections, and keeps pathless logical resources in a separate total.

A full scan of ~900 candidates across 5 repositories, 189 branches, 633 artifact directories and Docker: ~3.4 s.

Everything that can be parallel is. Directory sizing fans out at every level, and deletion works the same way — the overlap analysis already identifies which selected paths are pairwise disjoint, and those are unlinked concurrently. Commands stay serial, because their order matters and they touch shared state.

The scan used to take 11.8 s. Profiling said the cost was not sizing at all but the git process spawned per branch, run one repository after another; evaluating repositories concurrently took it to 3.4 s and cut system time from 29 s to 6 s.

Measured sizes are cached in ~/.cache/reap/sizes.json and reused while the directory's own mtime is unchanged and the reading is under a week old.

cargo test
cargo test specs::                            # behavioural specifications only
cargo test preview -- --ignored --nocapture   # print a rendered frame

# check the figures against the docker daemon on this machine
cargo test daemon_on_this_machine -- --ignored --nocapture

The GIFs above are scripted, not screen-captured — every one of them re-renders from a .tape file with vhs:

cargo build --release && vhs assets/demo.tape

assets/RECORDING.md covers how they were made and why each one earns its place.

Behaviour is specified separately from the unit tests: for_<subject> names what is under specification, when_<scenario> names the situation, and each should_<expectation> observes exactly one thing — so a failure reads as a sentence and names precisely what broke.

for_branch_prunability
  when_a_branch_was_squash_merged
    should_recognise_the_work_is_already_upstream
    should_consider_it_safe_to_delete
    should_explain_that_the_content_is_upstream
    should_force_the_delete_since_git_still_calls_it_unmerged
  when_a_branchs_upstream_was_deleted_while_it_held_local_commits
    should_treat_it_as_irreversible_rather_than_assume_a_squash_merge
    should_say_the_upstream_was_deleted_rather_than_that_it_lacks_the_commits

Each scenario establishes its context through given, performs the act once in BECAUSE, and only observes thereafter. The fixtures build real git repositories with real remotes and real directory trees rather than mocking them — whether a branch is recoverable turns on what a remote can actually reach, so a mock would only assert that the fixture agrees with itself.

Docker is the exception, since a daemon cannot be built inside a test. Its fixture is output captured from a real one, sanitised of names but verbatim in shape and in every figure's spelling — which is the part that matters, as the sizes are parsed from display strings. The capture can only prove reap still reads the docker that produced it, so the cross-check above asks the live daemon instead.

The UI is rendered through ratatui's TestBackend and asserted against the real cell buffer, including terminals far too small to draw. The deletion paths are covered directly: refusing broad paths, dry-run leaving the disk alone, trashing keeping contents recoverable, emptying refusing anything outside a trash, and overlapping selections counting their bytes once.

There is no version to bump. Label a pull request major, minor or patch, and merging it cuts the release: the next semantic version is worked out and tagged, and the release workflow builds and attaches binaries for all six targets and pushes the Homebrew formula. The version is stamped into Cargo.toml at build time rather than committed, so reap --version reports the release it came from. A merge with none of those labels releases nothing.

See CHANGELOG.md.

• homebrew-reap — the Homebrew tap that installs reap.

MIT © 2026 Sindre Wilting