The Chrome DevTools Port Is Just Sitting There

Chrome has been running a little WebSocket server on port 9222 for years — a full programmatic interface into everything the browser knows, everything it's doing, every tab, every network request, every DOM mutation — and most people walk past it every day without noticing.

The Chrome DevTools Protocol is not a secret. It's how Puppeteer works. It's how Playwright works. It's how Chrome's own DevTools panel talks to the engine underneath it. The documentation exists. The tooling exists. And yet somehow it still feels like you discovered a side entrance.

I had Claude Code build me a CLI for it. Took maybe twenty minutes of back-and-forth, including the part where I explained what I actually wanted versus what I said I wanted — which are never the same thing. The tool connects to whatever Chrome instance is already running with --remote-debugging-port, wraps the CDP calls I use most, and lets me drive the browser from the terminal like it's nothing.

It works beautifully.

That's the part that still surprises me, slightly — not that Claude Code can write code (it can, fine, we know this), but that the thing it made fits. It fits my workflow the way a tool you built yourself fits, not the way an npm package fits. Bespoke. Frictionless. Mine.

There's an old argument that programmers who use high-level abstractions lose touch with what's happening underneath. I'm not sure Claude Code breaks that pattern so much as it moves the floor. You still have to know that the CDP exists. You still have to know what to ask for. The tool doesn't replace understanding — it just eliminates the three hours of boilerplate between understanding and having something that works.

Which is a trade I will take every single time.