Burrow: a native Mac cleanup app that hands the same controls to an MCP agent

The gap Burrow is aimed at: one engine, two consumers

Most Mac maintenance tools are a GUI wrapper around a scan routine that only the GUI can call. Burrow's stated design puts the scan routine in a separate binary, burrow-engine, and then gives that binary two front ends: a SwiftUI app and a built-in MCP server. The README describes the engine as a single source-available binary whose command surface is modelled on the Mole (`mo`) CLI by tw93. That modelling matters. It means the vocabulary of operations (clean, uninstall, analyze, optimize) is not invented per feature; it follows an existing CLI convention, which is why the README can claim there is nothing else to install.

The intended user is a Mac owner who already runs an MCP-capable coding agent and wants that agent to have system context. The README names Claude Code, Codex, Cursor and local models via LM Studio. The secondary user is someone who just wants a native cleanup app and does not care about agents at all. Burrow serves both from the same binary, and that is the whole pitch. Whether the second user benefits from the arrangement is a separate question, and the answer is mostly that they get the app without paying for the agent plumbing.

What the bundled engine actually does

The README lists the feature surface in one sentence: junk cleanup, dev-artifact purge, app uninstall with leftover removal, duplicate finding, safe maintenance, disk maps, and live system status. Those map onto named screens in the screenshot table: Status, History, Analyze, Clean, Optimize, Software, Settings, Activity, plus a menu-bar HUD.

Analyze is described as a squarified treemap of the whole disk. History is described as long-range charts over a local SQLite metric history, and the README says the app keeps months of local metric history. Status covers live CPU, memory, GPU, disk, network and battery. Software is installed apps with search, sort and multi-select uninstall, and it also shows Homebrew app updates. Activity is a running log of cleans, optimizes and scans, plus anything in flight.

Two mechanisms are worth separating out. First, removal is Trash-based by default: the README states that Trash-based removals remain recoverable until the Trash is emptied, and that permanent deletion requires separate consent and cannot be undone. Second, every agent action is consent-gated and audited. Those two sentences are the security model in miniature, and they are the most concrete claims in the document.

Installing it, and the keys you will touch

The Mac install path is a single Homebrew cask:

brew install --cask caezium/tap/burrow

Windows is a preview under the `windows/` directory, distributed as a download from the releases page rather than through a package manager. The badge in the README marks Windows 10/11 as beta, and the topics list includes both winui3 and windows, so the port is a real code path rather than a stub. Treat it as unfinished regardless.

The README does not publish a settings key reference in the material available here. What it does document is a Settings screen and a Permissions section, and the requirements badge states macOS 14 or later. The one configuration decision that changes behaviour is Full Disk Access: the README devotes a section to it, and the honest reading is that scans are bounded by whatever the app is permitted to read. If you decline that permission, expect the disk map and cleanup scan to see less, not to fail loudly.

For agent use, the MCP server is built in, so there is no separate process to install. The README's example is pointing an MCP-capable agent at Burrow and asking about the Mac in plain language; the screenshot caption names `burrow_snapshot` as a tool the agent calls. It also describes a proactive mode: if an agent notices something irregular such as low disk space while doing unrelated work, it can investigate and run cleanups without being asked. That is a design choice with consequences, and the consent gate is what keeps it from being reckless.

The licence split is the real constraint

Burrow is MIT. Burrow-engine is not. The README is explicit that the engine is a single source-available binary under the Functional Source License, FSL-1.1-ALv2. So the repository you clone and the binary you run are governed differently, and the permissive licence applies to the app layer.

For an individual installing the cask this changes nothing day to day. For anyone planning to fork, redistribute, or ship Burrow inside a product, it changes everything, because the part that does the work is the part with the restrictive terms. The README also carries a pointed disclaimer: Burrow is not affiliated with or endorsed by mole.fit, the official Mole for Mac app, and it states that its own name, mark, palette and copy are original. It goes further and tells readers who like Mole to buy mole.fit for $19. That is an unusually direct acknowledgement of where the engine's command surface came from, and it is the kind of thing a procurement reviewer will want to read in full rather than take secondhand.

This is not legal advice. Read the FSL-1.1-ALv2 text and the attribution section of the README yourself before you build anything commercial on top.

Where the agent integration can go wrong

The proactive mode is the sharpest edge in the design. The README describes agents dissecting a problem and performing secure cleanups autonomously, without the user asking. Consent gating and the audit log are the stated counterweights, and Trash-based removal means the blast radius of a bad call is usually recoverable. But recoverable is not the same as harmless: a cleanup that moves the wrong directory to the Trash still breaks a running build until someone notices, and the audit log tells you what happened after the fact rather than before.

The permanent-deletion path is the genuine failure mode. The README is clear that it requires separate consent and cannot be undone. Any workflow that pre-approves that consent, or that runs an agent unattended with broad permissions, has removed the one barrier the design relies on. If your agent runs in a loop over long sessions, that is the configuration to avoid.

There is a second, quieter limitation. The README frames the app around months of local metric history in SQLite, which is a real feature and also a real storage commitment. The material does not state a retention policy, a database size cap, or a pruning command. If you care about how large that history grows, the repository is the place to look, because the README does not answer it.

How it differs from DaisyDisk and from Mole itself

DaisyDisk is the obvious comparison for the Analyze screen, and the difference is scope rather than quality. DaisyDisk is a disk visualiser: you point it at a volume, it draws the map, you drag things to delete. Burrow draws a squarified treemap too, but the map sits inside an app that also uninstalls apps with leftover removal, purges dev build artifacts, runs maintenance tasks, and streams live CPU, memory, GPU, disk, network and battery metrics into a menu-bar HUD and a months-long history. If your only job is finding what is eating a volume, a dedicated visualiser is a smaller tool doing one thing. If you want the map and the cleanup and the live status in one window, that is the gap Burrow is filling.

The comparison the README invites is Mole, since burrow-engine's command surface is modelled on `mo`. The README positions the two as separate products with separate funding: Mole is the paid app at $19, Burrow is the free MIT app with an FSL engine. The architectural difference that matters most is the MCP server. Mole's README, which is not in the material here, would need to be checked for an equivalent; based on what is available, agent access is Burrow's distinguishing feature rather than a shared one.

Release cadence and what maintenance looks like

The release list shows v0.12.0, v0.13.0 and v0.14.0, with two of those tagged on the same day in August 2026 and the latest push to main in September 2026. That is a fast pre-1.0 cadence, and it tells you two things. The project is active. It also has not reached 1.0, so interfaces and behaviour can still move between minor versions.

For a Homebrew cask install, upgrading is the ordinary `brew upgrade --cask burrow` path, and each upgrade pulls a new engine binary, which is where the FSL terms apply again. The cost of staying current is low; the cost of pinning an old version is that you keep an older engine with whatever it did at the time. There is no stated support window for older releases in the material available.

The Windows port adds a maintenance surface the README does not quantify. It is labelled beta and lives under `windows/`, and the topics list winui3 alongside macos, which implies a second UI toolkit to keep in step with the Mac app. A beta port with a separate toolkit is the part of this project most likely to lag.

Who should install it and who should wait

Install it if you are on macOS 14 or later, you want a native app that covers cleanup, uninstall, disk analysis and live metrics without assembling four utilities, and you already run an MCP-capable agent you would like to give system context. The consent gate and the Trash-first default are the right defaults for that combination, and the audit log gives you something to read when an agent does something you did not expect.

Wait if you need the engine under a permissive licence, if you are on macOS 13 or older, or if your agent workflow depends on unattended permanent deletion. The first is a licensing boundary you cannot code around. The second is a hard requirement stated in the README badge. The third is a workflow that removes the safeguard the project built.

Before you install, do three things. Read the FSL-1.1-ALv2 terms for burrow-engine rather than assuming MIT covers the whole thing. Confirm the cask you are installing is caezium/tap/burrow and not a same-named formula from another tap. And decide whether you will grant Full Disk Access, because that decision determines what the Analyze screen can actually see on your machine.

Editorial conclusion

Adopt Burrow if you want one native Mac app that covers cleanup, uninstall, disk maps and live metrics, and if you specifically want an MCP-capable agent to read those metrics and run consent-gated actions. Do not adopt it if you need a permissively licensed engine you can fork and redistribute, or if you are on a macOS version below 14. Before installing, read the Functional Source License terms on burrow-engine, confirm the Homebrew cask resolves to caezium/tap/burrow, and decide in advance whether you will grant Full Disk Access, because the scan surface depends on it.

Official sources

1. caezium/burrow on GitHub
2. License: MIT
3. Project website
4. README
5. Releases