The Problem
LLM-based browser agents typically rely on rigid frameworks with pre-built actions and workflows. When an agent encounters an unfamiliar task—uploading a file, handling a cross-origin iframe, or scraping a site with unusual selectors—it either fails or requires human intervention to extend the framework. The browser-harness repo takes the opposite approach: a deliberately thin CDP (Chrome DevTools Protocol) bridge that lets the agent write its own missing functionality mid-task.
What This Does
The harness is a minimal Python layer (~592 lines total) between an LLM and a Chrome browser. run.py (~36 lines) executes plain Python with helpers.py (~195 lines) preloaded; helpers.py contains the starting tool calls the agent can extend. admin.py and daemon.py (~361 lines) handle the daemon bootstrap and the CDP websocket/socket bridge.
The repo's real substance is two directories of Markdown skill files. interaction-skills/ (17 files) covers browser mechanics—downloads.md, shadow-dom.md, uploads.md, cross-origin-iframes.md. domain-skills/ (68 files) documents site-specific scraping or task flows: amazon/product-search.md, sec-edgar/scraping.md, linkedin/, salesforce/, tiktok/upload.md. The README explicitly states these skills are agent-generated, not hand-authored—the agent files what it learns during real tasks.
How To Use It
Setup: The repo is Python-based (pyproject.toml present). The README's setup prompt tells the agent to read install.md first, then SKILL.md. No lockfile exists, so install with pip install -e . or uv sync from the repo root—exact commands aren't documented in the README.
Configuration: .env.example defines required environment variables. The setup requires Chrome to run with remote debugging enabled; docs/setup-remote-debugging.png shows the browser flag to enable.
Running it: There is no documented CLI entry point. The workflow is conversational: paste the setup prompt into Claude Code or Codex, and the agent handles installation, browser connection, and task execution. run.py is the underlying execution path but isn't invoked directly.
Real-World Use
A typical session: an agent needs to scrape Glassdoor job postings. It connects via the daemon's CDP websocket, reads domain-skills/glassdoor/scraping.md for known selectors and anti-bot patterns, executes the flow through helpers.py functions. If it hits an unexpected pagination pattern, it writes a new helper, updates the skill file, and continues—no human coding required.
Code Health & Issues
Med - No test files - The entire codebase has zero tests despite containing a websocket bridge and daemon process. Network-heavy code paths are untested. Med - No CI/CD pipeline - No .github/ or CI config detected. No automated gate for regressions. Low - No dependency lockfile - pyproject.toml declares dependencies without a lockfile, so builds aren't reproducible. Low - Thin Python core - 4 Python files total (~592 lines) means the actual code surface is small; most value lives in Markdown skill files, which are unvalidated prose.
The Bottom Line
This is a pragmatic, philosophy-driven tool for teams already using Claude Code or Codex for browser automation. The agent-generated skill library is a clever way to accumulate hard-won scraping knowledge. The absence of tests and CI is a real concern for production use, but for an exploratory tool where the agent is the test harness, it's a defensible trade-off. Best suited to teams experimenting with agentic browser workflows, not as a drop-in automation platform.