DiskSwell: The Menu Bar App a Developer Built After Safari Silently Ate 51 GB of His Mac

Every developer has a story about disk space vanishing for no obvious reason. Developer Oleksii Krichevsky turned his into a shipped app.

The origin story

It started when Safari quietly grew a WebKit SQLite write-ahead log to 51 GB on his Mac. Free space kept draining, and macOS offered no clear way to see what was growing or which app was responsible. Instead of just deleting the file and moving on, he built a small native monitor to catch the next runaway file early — one that would show the exact path and the likely culprit, and then get out of the way and let a human decide what to do about it.

That tool became DiskSwell, and this week it proved itself. In a recent post, Krichevsky shared that after running quietly in his menu bar for a week — long enough that he'd forgotten it was even there — it fired an alert: this time, the UniFi network controller's web management panel had devoured 47.4 GB of disk space. Mystery solved, in seconds instead of another manual hunt through ~/Library.

He's since said he's planning a round of updates to the app soon, and shared the project publicly on GitHub.

Repository: 0k-lab/DiskSwell

What DiskSwell actually does

DiskSwell is a native macOS menu bar utility, written in Swift, with one narrow job: detect abnormal disk-usage growth, show you the file or folder responsible, and identify the likely app when it can. That's it. It is explicitly detection-only — it never deletes files, truncates write-ahead logs, checkpoints databases, or kills applications. Cleanup decisions stay entirely in the user's hands.

It's built for a specific set of symptoms:

Mac disk space disappearing with no obvious explanation
A Safari or WebKit WAL file silently ballooning to tens of gigabytes
An application container expanding rapidly
Needing to know which app is creating a large file, not just that one exists

Unlike a static disk-usage browser (think a fancy du viewer), DiskSwell tracks growth over time — it's watching for trends, not just taking one snapshot.

How it works, without the deep dive

DiskSwell uses native FSEvents to watch a bounded set of locations — by default ~/Library, ~/Downloads, ~/Library/Developer, ~/Library/Containers, and the Safari container — rather than scanning the entire disk. Everything about the design is deliberately bounded: capped path counts, capped directory-walk depth, capped audit time windows. There's no du, no full-disk scan, no unbounded recursion anywhere in the pipeline.

It distinguishes between two kinds of growth:

Surge — a sharp spike over minutes to an hour (say, +2 GB in 15 minutes)
Creep — slow, sustained growth measured over 24 hours, 7 days, or 30 days

That distinction matters: a large directory that's simply stable shouldn't nag you every day, but one that keeps climbing should. DiskSwell also ships a specialized detector just for Safari/WebKit WAL files, since that's the bug that started the whole project — it flags growth at 500 MB (warning), 2 GB (critical), and anything growing faster than 250 MB per minute (emergency), all without ever opening or touching the file itself.

When it does identify a likely owner for the growth, it labels its confidence honestly: Verified (bundle metadata or container ownership clearly ties it to an app), Likely (strong circumstantial evidence), or just Filesystem when a broad directory could belong to several apps at once.

Built to stay out of your way

A few design choices stand out for a "just runs in the background" tool:

No telemetry, no accounts, no uploads. Monitoring data stays local in a SQLite history database. Networking is used only for optional GitHub Releases update checks, which the user must approve before anything downloads.
Effectively 0% idle CPU and a monitoring footprint around 30 MB — this is meant to run for months without you noticing it, until it needs to.
Notifications are earned, not spammed. An alert fires on first detection, on severity escalation, or on meaningful additional growth — with cooldowns (30 minutes for surges, 24 hours for creep) so a stable large folder doesn't nag you daily.
A "Fix Access…" assistant walks you through granting Full Disk Access when macOS blocks a location, rather than repeatedly nagging for permission.

Installation

DiskSwell requires macOS 14 or later. Install the signed and notarized package directly from GitHub Releases, or via the maintainer's Homebrew tap:

brew install --cask 0k-lab/tap/diskswell

Why this is worth watching

DiskSwell is a nice example of a developer turning a personal annoyance into a genuinely useful, narrowly-scoped tool instead of either living with the bug or reaching for a bloated "disk cleaner" suite that wants Full Disk Access and a subscription. It doesn't try to fix your disk for you — it just tells you, precisely and honestly, what's happening, and gets out of the way. That restraint (detection-only, local-only, bounded-everything) is a deliberate design stance, and it shows in how the project is documented.

The UniFi incident is a good demonstration of exactly the use case it was built for: something eats tens of gigabytes, quietly, over days — and a week later, the app that would otherwise have gone unnoticed does its one job and flags it.

DiskSwell: The Menu Bar App