browser-harness is a self-healing browser automation harness designed specifically for LLM agents. Built by the browser-use team, it wraps Chrome DevTools Protocol with intelligent retry logic, visibility checks, and platform-aware recovery — so autonomous agents can reliably complete multi-step web tasks without human intervention.

• Self-healing DOM interactions — Rather than relying on fragile CSS selectors, the harness detects when actions fail (e.g., element not visible, button still disabled) and automatically retries with corrected selectors or waits for DOM stabilization. This dramatically reduces flaky automation in modern SPAs.
• Platform-aware daemon transport — The daemon runs as a separate process communicating over Unix sockets on Linux/macOS, with an authenticated TCP loopback fallback on Windows. This makes the harness portable across dev environments without sacrificing security.
• Built-in doctor and setup diagnostics — A --doctor mode checks Chrome connectivity, profile permissions, and daemon health on startup, surfacing actionable errors instead of silent failures. Setup flow guides users through Chrome remote debugging configuration step by step.

The community uncovered a subtle but critical bug: type_text() calls Input.insertText which bypasses React/Vue/Ember event listeners — the DOM field appears filled but the framework internal state never updates, leaving submit buttons permanently disabled.

fill_input() uses optional-chaining focus and does not verify the selector matched; it will still send key events to whatever element is currently focused, causing input to land in the wrong place when the selector is missing or late-rendered.

— @Qodo-Free-For-OSS

User @sauravpanda refined wait_for_element(visible=True) to prefer el.checkVisibility() over computed-style checks:

Even with the platform-correct modifier (Cmd on darwin, Ctrl elsewhere), press_key always emits a follow-up Input.dispatchKeyEvent of type char for any single-character key. With the modifier held, that generates unwanted character insertions.

— @sauravpanda

User @Bortlesboat ran the harness on Windows 11 and hit a crash when socket.AF_UNIX was absent:

The daemon transport assumed Unix sockets unconditionally. When AF_UNIX is absent, asyncio.start_unix_server raises AttributeError, crashing the setup flow before the doctor banner even prints.

— @Bortlesboat

@Qodo-Free-For-OSS additionally found that run_setup() calls ensure_daemon(open_inspect=False), preventing the daemon built-in Chrome Allow/403 handshake recovery from running during setup. The issue was superseded by PR #225 which landed full Windows IPC support on main.

A Codex review surfaced a P0 issue: restart_daemon() reads the PID file directly and signals that PID without verifying process identity. After a daemon crash, PID reuse could cause the harness to SIGTERM an unrelated local process.

browser-harness is a rapidly evolving project that addresses the real pain points of running autonomous agents in browsers. Its self-healing approach to DOM interactions, cross-platform daemon architecture, and active community-driven bug discovery make it one of the more thoughtful tools in the LLM browser automation space. With 11k+ stars and strong issue activity, it is well worth watching — especially if you are building agents that need to reliably navigate complex web interfaces.

Project: github.com/browser-use/browser-harness
Stars: 11,290 | Language: Python | License: MIT