From Resource Monitor to Cleanup Assistant — When Safety Is the Product Itself

Pier 2.x is a menu-bar resource monitor: ports, processes, system stats, Docker, Homebrew services. The basic unit is ports and processes, and it assumes the user understands these low-level objects and can decide for themselves whether to act. 3.0 is a repositioning — from “developer resource monitor” to “local dev cleanup assistant for after AI coding.” This post is about the judgment behind that pivot, and the iron rule it forced out: safety isn’t a marketing word, it’s the product itself.

The starting point: vibe coders don’t know processes

The target user changed. 3.0 is aimed at people who heavily use Cursor, Claude Code, Windsurf, terminal agents — they let AI get a project running, but don’t necessarily understand what ports, process trees, Docker, or LaunchAgents are.

The problem is what happens after the AI is done. An AI agent spins up a pile of background resources: dev servers, file watchers, browser-automation processes, MCP helpers, sandboxes, containers — and when the task ends, those things often don’t get stopped cleanly. Day after day, the Mac gets slower, ports stay occupied, memory climbs. And when a vibe coder opens Activity Monitor, they see a screenful of node, python, docker-proxy, with no idea which one is safe to close.

So 3.0 moves the basic unit up from “port/process” to “project/dev session,” and the core question it answers is a single line:

What did my AI coding tools leave running? What can I safely stop to get my Mac back to normal?

Pier translates low-level process, port, and connection data into evidence-backed cleanup suggestions organized by project. It’s not a general Mac cleaner, not antivirus, not a system-optimization suite — the boundary is hard: only local dev resources.

Why safety is the product, not a feature

This pivot brings a brutal constraint: a cleanup tool aimed at non-expert developers gets exactly one chance to be wrong.

Imagine Pier suggests stopping a dev server that is the very page the user is staring at in their browser; or it fumbles a database, a stateful persistent service. To a user who can’t read processes, that isn’t “oh, a small bug,” it’s “this software made the thing I was working on disappear” — trust drops to zero instantly, and they never open it a second time.

A professional developer can catch themselves: they know how to recover from a wrong kill. A vibe coder can’t. So the 2.x model of “show information, let the user decide” has to become, in 3.0, “Pier holds the safety boundary for the user.” Safety goes from being a feature to being the foundation that decides whether the product stands up at all.

That judgment crystallizes into six product principles:

1. Prefer a miss over a wrong kill. Pier may skip some cleanable targets, but must never put a risky one into the default cleanup;
2. Evidence before action. Every suggestion must explain why Pier thinks it’s cleanable, needs confirmation, or must be protected;
3. Projects first, processes second. The default view is organized by project; PID / command / port live in the expanded detail;
4. Gentle stop by default. Prefer SIGTERM or the tool’s own graceful stop; SIGKILL is only an advanced fallback, and 3.0 won’t even auto-escalate to it;
5. No automatic cleanup. Pier can suggest, but stops nothing without an explicit user click;
6. Local, private, explainable. All judgments happen on-device; core functionality depends on no telemetry or cloud.

Three-color grading: let users click boldly, but not blindly

The productized safety boundary is a three-color grading shown inside each project card:

• Green (safe to clean up): high confidence, Pier is willing to put it in one-click cleanup. But a green card must surface two or three strong pieces of evidence — “no browser/API found connecting,” “parent terminal has exited,” “identified as Vite dev server,” “located in the project directory” — to let the user click boldly, but not click blindly;
• Yellow (needs confirmation): probably unused, but the evidence isn’t enough to decide for the user. Never mixed into one-click cleanup by default; the user must read the explanation and check it manually;
• Red (protected): Pier won’t touch it by default, and it’s designed as a trust-building protected zone — “someone is connecting to this port, so Pier won’t put it in safe cleanup.”

Crucially, “aimed at vibe coders” is carried into the copy layer too: the default UI avoids low-level jargon — no Kill / SIGTERM / PID / established connection, instead “stop dev service,” “free the port,” “someone is connecting,” “possibly a service left by a coding agent.” The technical terms are reserved for advanced users in the expanded detail.

Agent residue: a first-class citizen of 3.0

The most distinctive part of 3.0 is proactively hunting for resources “an AI agent started but never released after the session ended.” Their CPU and memory aren’t necessarily high, but they pile up, and a vibe coder can almost never identify them alone.

The hard part is attribution — how do you judge that a lone node process is “probably left by a coding agent.” There’s an iron rule here: attribution must be structured evidence, not a path substring. A claude or cursor string appearing in the project path must never produce attribution — that’s far too easy to get wrong. The agent binary itself is recognized only by exact executable basename or App bundle evidence.

Trickier still is when the agent has exited but its children live on. The parent terminal closes, the dev server gets reparented to launchd, the parent-child link breaks, and the source evidence is about to be lost. The fix is an AgentLineageTracker: it uses (PID + stable start time + user) as a process’s stable identity, and after the agent parent exits and the child is reparented to launchd, it still preserves the evidence that “this background service originated from that agent session.” And the moment the PID is reused, the start time changes, or a stable start time can’t be obtained, the historical attribution invalidates immediately — better no attribution than a mistaken one.

So the UI can put it plainly, without overclaiming:

Possibly a background service left by a coding agent
No browser/API found connecting
The parent terminal has exited

The word “possibly” is deliberate — Pier explains why it’s worth your attention, without pretending to know the source with 100% certainty.

Takeaways

• Changing the user rewrites the basic unit. Move from “developers who understand processes” to “vibe coders who don’t,” and the product’s atomic unit has to move up from port/process to project/session — otherwise you’re still making users face things they can’t read;
• In some products, safety is the foundation, not a feature. When the actor makes mistakes (AI), the user can’t recover (non-expert), and the action is irreversible (stopping a process), safety can’t be one checkbox among many — it decides whether the product is viable. “Prefer a miss over a wrong kill” belongs in principle number one, not in the bug list;
• When in doubt, don’t attribute. For “possibly left by an agent,” use structured evidence (exact basename, stable process identity), not path substrings; and the moment the evidence becomes unreliable (PID reuse, changed start time), invalidate it. Better to say “source uncertain” than to misattribute — a wrong attribution hurts trust more than none;
• Terminology is part of safety, too. Showing a screenful of PIDs to someone who can’t read a PID is itself offloading risk onto the user. The default UI speaks plainly; technical detail is reserved for advanced users who drill in.

3.0 turns Pier from “here’s the data, you decide” into “I’ll hold the boundary and give you evidence-backed suggestions.” The next posts open up the internals of this safety machinery: the fail-closed grading engine, how to stop a process that keeps changing under you, and how to restart a stopped service safely without going through a shell.