browser-use/browser-harness

Browser Harness connects an LLM agent directly to your running browser over a single Chrome DevTools Protocol websocket. The core mechanic is deliberately simple: the agent gets a skill document that describes the browser workflow, and when it encounters something the harness doesn't yet handle—uploading a file, say—it writes a helper function into a local workspace file and proceeds. That helper persists. The next time a similar task comes up, the function is already there.

This is a specific and honest answer to a real problem. Most browser automation tools ship a fixed API surface, which means the agent either finds the right call or fails. Browser Harness sidesteps that by treating the helper layer as mutable. The agent is the author of its own tooling, not just a consumer of someone else's. The protected core library stays untouched; only the workspace grows.

The setup story is worth examining. You paste a single prompt into Claude Code or Codex, and the agent installs the package, registers the skill, and walks you through enabling remote debugging in Chrome. It asks whether you want local recordings. That's the entire onboarding. The design assumes you already have a coding agent running and just want to hand it a browser.

The local-versus-cloud split is explicit and sensible. Local browser access is for personal, authenticated work—the sessions where you're already logged in and don't want to re-authenticate inside a headless container. The cloud offering handles parallelism, proxies, and CAPTCHA solving. These are genuinely different use cases, and the README doesn't pretend otherwise.

What's less clear from the README is how the helper-writing mechanism handles drift or conflict when the same domain gets different helpers written across different sessions. The workspace file is described as editable and persistent, but there's no mention of versioning, deduplication, or what happens when two generated helpers for the same site contradict each other. For personal single-user use that's probably fine. For anything shared or long-running, it's an open question.

The demo—downloading the latest twenty videos from an X profile—is a good choice of benchmark. It requires login state, dynamic content, and file I/O, which are exactly the cases where headless automation tends to break. Whether the helper-accumulation model holds up across a wide task distribution over weeks of use is the real test, and the README doesn't claim to have run it.