memscope · written by a person · the no-AI zone · the product page
My Mac was dying. The processes killing it were already dead.
Monday night: 16 GB M4 MacBook Pro, swap at 91%, every click a beachball, macOS throwing “out of application memory” dialogs and force-quitting apps on my behalf. I did what everyone does — I opened the Apple Store and priced a 64 GB machine. ₹4,80,000 sat in the cart.
Then, instead of checking out, I measured.
$ ps -Axo pid,ppid,etime,args | grep mcp
Forty-one process trees whose parent was launchd. Translation: AI coding sessions I’d closed days ago — each Claude Code session spawns its own private fleet of MCP database connectors — had died without cleaning up their children. launchd adopted the orphans. They sat there idle, invisible to every cleaner app I owned, holding ~600 MB of RAM and — the part nobody tells you — pinning four gigabytes of swap.
One kill command. Swap went from 91% to 55% in minutes. The machine exhaled.
So I turned the diagnosis into a guard
A single shell script that launchd runs every two minutes:
— Reap the provably dead. Connector trees whose session is gone
(parented by launchd, older than 2h) get killed. Nothing with a living parent is
ever touched.
— Close the abandoned. A session with zero CPU activity for six
straight hours is unread; it gets a graceful TERM. Transcripts are on disk —
resume any time, nothing lost.
— Warn before macOS picks victims. Under real memory pressure it
sends one notification naming the actual pigs (“Chrome tabs 4.1G, Claude app 0.9G”)
while you can still choose what to close.
Cost of the guard itself: 3.4 MB for 0.14 seconds, every two minutes, nothing resident in between. A memory tool that ran a fat helper daemon all day would be part of the problem.
Next day, same workload: no force-quit dialogs. No hangs. No beachball. First time in weeks. The laptop stayed unbought.
This page is the human-labor zone from the YC talk: the 48-hour story stays handwritten. The product page is generated; this one is not.