Day 130: The Browser I Keep Not Shipping
The capability people ask me for most, and the one I keep not shipping, is a real browser. Pinchy’s pinchy_web_fetch reads static HTML, which is fine for a content-rich article and useless for the two page classes that matter most in practice: JavaScript single-page apps, where the HTML is an empty shell and the content renders client-side, and pages behind an anti-bot challenge that demand a real browser fingerprint. An agent that can’t read those is an agent that hits a wall on a large slice of the real web. So the demand is obvious. Why is it still not shipped?
The hard part isn’t the browser
It isn’t that a browser is hard to get. OpenClaw already ships a native browser tool: real Chromium, driven over CDP, able to navigate, click, type, and screenshot. I don’t need to build any of that, and I wouldn’t want to. The consistent posture, the same one I take with the whole runtime, is that Pinchy puts a governance layer on top of OpenClaw’s capabilities rather than reimplementing them. Building my own browser stack would be rebuilding a thing that exists, worse, and owning the maintenance forever.
The hard part is that a real browser is one of the most powerful things you can hand an agent. It can reach anything a logged-in human can reach. Exposing it is not a feature decision, it’s a security decision, and it only gets to happen after the gate around it is something I actually trust.
Why yesterday had to come first
Which is exactly why yesterday’s fail-closed allowlist wasn’t a coincidence of timing. When Pinchy’s tool gating was a deny-list, a real browser was the worst possible thing to add: one forgotten entry, one new OpenClaw built-in, and you’ve silently handed every agent a fully capable browser nobody granted. The only reason that wasn’t a live hole already was the accident that the production image ships no Chromium. An accident is not a control. You do not build the powerful feature on top of a gate you already know leaks.
With the allowlist flipped, the shape is right: the browser is denied by default, like everything else, and turning it on for an agent becomes a deliberate grant an admin makes on purpose, auditable, revocable, scoped. That is the version of a browser tool I’m willing to ship. Not “here’s Chromium, good luck,” but a capability that lives inside the same permissions model as every other tool, off until someone decides otherwise.
Day 130
There’s a pattern I keep relearning, most recently on Day 123 with the air-gap box I haven’t touched: the discipline of a governance product is mostly about the order you do things in. Ship the boring safety primitive first, the exciting capability second, even when the market is asking for the second one and nobody’s asking for the first. The browser is coming. It’s coming after the gate, not before, because a powerful feature on a weak gate isn’t a feature, it’s a liability with a nice demo. Building in public means occasionally the honest update is “here’s the thing I deliberately didn’t ship yet, and why.”