87 tools, not 100.

The request, verbatim: "up to 100 various tools that is actually really useful, from popular to less popular."

The Tools panel had 14. By the end of the day it had 87, sectioned by how often you'll reach for them, with a search field, because at 87 a flat sidebar stops being navigable. This post is about the two interesting parts: how 73 tools shipped in a day without 73 new screens, and why the number stops at 87 when the ask said 100.

Tools stopped being code

The original 14 tools are each a hand-built SwiftUI view — Keep Awake has its duration picker, Open On Phone draws a QR code. That's right for interactive tools, and it's also why the panel stayed at 14 for so long: every new tool cost a screen.

The 73 new ones are not views. Each is a data literal — a name, the command it runs, an optional validated input, a timeout, a flag for "this one deletes things." One generic view renders all of them: mono command chip up top (you see exactly what a terminal user would type), the input if there is one, a Run button, and the output in a monospace box — because for most of these, the output is the product. "What's on port 3000" is not a side effect; it's an answer.

The practical consequence: tool #88 is a ten-line diff. And because the one generic view is built on the design system's components, a new tool cannot ship off-system chrome even if we're careless.

What 87 actually covers

Ports and processes first — what's on a port, kill its owner (TERM, not -9; the process gets to clean up), top CPU and memory. Then network and DNS: your LAN and public IP, dig, ping, traceroute, Apple's built-in speed test. HTTP: response headers, and a status-plus-timing breakdown that shows where a slow request actually spends its time. Docker and Homebrew: containers, services, disk usage, prunes — with a dry run offered before the destructive cleanup. Developer disk hygiene: DerivedData (size first, delete second), npm/pip/yarn caches, a node_modules finder. Clipboard utilities: UUID, pretty-print JSON, base64 both ways, hashes. And system one-shots: battery, thermal state, memory pressure, toggle dark mode.

The ordering inside each section is editorial — the things a localhost developer reaches for weekly outrank the ones they reach for monthly. That was the request ("popular to less popular"), and it's also just how a good toolbox is arranged.

Safety by shape, not by review

A panel that runs 87 shell commands is a panel with 87 chances to do something stupid. The rules are structural, so a future tool can't quietly break them:

• Nothing needs sudo. If a command would (purge, Spotlight rebuilds), it doesn't ship. There is no "enter your password" anywhere in this app, and there never will be.
• Typed input never touches a shell. Anything you type is passed to the command as a discrete argument, not interpolated into a shell string. The one pipeline that needs your input (kill-by-port) only accepts a number, validated as a number, so there's nothing to inject. Free-text inputs also reject a leading - — an input that starts with a dash is how you smuggle flags into someone's argv.
• Destructive tools say so. They're labelled, they get the red-hairline button treatment, and the genuinely irreversible ones we simply didn't include: the Trash tool shows you its size and tells you to empty it in Finder. Some clicks should stay yours.

The GUI PATH trap

One bug is worth telling, because it silently breaks every Mac app that shells out to developer tools: apps launched from Finder don't inherit your terminal's PATH. They get the bare system one — no Homebrew, no nvm. So brew services list and docker ps, which work in every terminal you own, resolve to command not found when an app runs them. Every Docker and Homebrew tool in the catalog would have shipped broken.

The runner prepends Homebrew's prefixes to the PATH before every run. And because this mystery bites everyone eventually, there's now a tool that just shows you the PATH GUI apps actually see — the answer to "why doesn't my alias work when Xcode runs the script."

Why not 100

Because the last 13 would have been filler, and one filler tool costs more trust than ten good ones earn. Every candidate had to answer: would a developer actually reach for this? The rejects tell the story — a Bonjour browser that never exits (a tool that has to be force-killed isn't a tool), a TLS certificate checker that needed stdin games the safety rules don't allow, anything requiring sudo. "Up to 100" is satisfied at 87 the same way a good toolbox is full without a third kind of hammer.

If a tool you reach for is missing, say so. It's a ten-line diff now.