BrowserCode, a coding agent that drives Chrome through the DevTools protocol

One primitive: run JavaScript that drives Chrome

BrowserCode is described as the browser-native agent, a lean coding agent that drives real browsers through unconstrained CDP. The README calls it a fork of OpenCode with a vendored TypeScript port of Browser Harness, and states plainly that it is not built by the OpenCode team and is not affiliated with OpenCode in any way.

What it adds over a normal coding agent is described as one core browser primitive:

browser_execute(code)
  -> runs JavaScript in-process
  -> talks to Chrome through the DevTools Protocol
  -> keeps the browser session alive across calls
  -> returns logs, values, and screenshots to the agent

Read that carefully, because it explains both the capability and the constraint. The agent writes JavaScript rather than calling a fixed set of browser automation commands. It executes in-process, talks to Chrome over CDP, and the session survives between calls so that state set up in one call is available in the next. The return value carries logs, values and screenshots, so the agent gets the same three kinds of feedback a person would.

The README's stated philosophy is that browser ability and code-writing ability are deeply connected, and that the project turned browser interaction into a coding problem with minimal abstractions. That is a defensible design bet. A fixed command API like click, type and scroll covers most automation and runs into a wall on any site that needs a judgement call about which element is the right one, whereas writing JavaScript lets the agent reason about the page and use whatever DOM access it needs.

Scripts the agent writes are stored under .bcode/agent-workspace/, so the work is reusable after the run rather than discarded with the session.

Installing, the TUI and running headless

The install is a one-liner in a bash-capable terminal:

curl -fsSL https://bcode.sh/install | bash

The command installs the binary, which is then run as bcode to open the terminal interface:

bcode

For scripted or unattended use, the same binary runs an agent headlessly with a task as an argument:

bcode run "On Google flights return all flight details from New York to SF tomorrow"

Running from source is also documented, and it shows the shape of the project. It is a bun workspace with a fork of OpenCode under packages/opencode:

git clone https://github.com/browser-use/browsercode.git
cd browsercode
bun install
bun run --cwd packages/opencode dev

The workspace list in the root package.json is wide: packages/ holds the core and the browser-specific packages, packages/console has a console app, packages/stats a statistics app, packages/sdk/js a JavaScript SDK and packages/slack a Slack integration. There is a desktop package and a web package as well. The packageManager field pins bun 1.3.14 and the repository carries a bun.lock file, a turbo.json for task orchestration, nix and flake files, an SST config and infra directories for deployment.

The release tags tell you where the project is. The listed releases are prereleases with descriptive suffixes: v0.1.21-transport-recovery.2 on 2026-10-08, v0.1.21-transport-recovery.1 before it, and v0.1.21-screenshot-files.4 on 2026-10-05. A version number in the low zero one range with prerelease tags means the surface is still moving.

Choosing a model and connecting a browser

BrowserCode supports any model reachable with an API key, plus every provider OpenCode supports. You connect a model with the /connect command in the TUI, or by setting provider API keys in the environment.

The README lists recommended models from current BU Bench evaluations: claude-opus-4-8 as the best performing, kimi-k3 as the best open-weight option, and gpt-5.6-luna at xhigh reasoning effort as the best value. Note that these are the maintainer's own eval results and the images carrying the fuller tables are the evidence behind them, so treat the ranking as a starting point rather than a result you can rely on for your own workload.

Browser connection is where the agent takes more initiative. The README describes three prompt styles. Ask it to connect to your current tab on a site and find something, and it takes control of your actual browser. Ask it to make a new browser profile and QA test a local URL, and it works locally in its own profile. Ask it to open a remote browser and extract data, and it drives a Browser Use Cloud browser and returns a link to watch it.

For cloud browsers, the README states that Browser Use Cloud offers unlimited free browsers limited to three concurrent sessions, with stealth, captcha solving and proxies, activated by setting BROWSER_USE_API_KEY in the environment. It also notes that the agent can sign up for the service autonomously if asked.

That last point deserves a pause. An agent that can create accounts on your behalf changes the compliance surface of a tool considerably, and it is worth deciding as a team whether that behaviour is acceptable before enabling it in an environment with real credentials.

Hosting it in the cloud and the telemetry question

There is a hosted path. The README shows a direct API call that starts a run on Browser Use Cloud:

curl -X POST https://api.browser-use.com/api/v4/runs \
  -H "X-Browser-Use-API-Key: $BROWSER_USE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"task": "Your task"}'

The header name makes the coupling to that specific provider explicit, and the endpoint is under api.browser-use.com/api/v4.

Telemetry is disclosed in its own README section. BrowserCode sends anonymous usage traces to help improve the project, and the opt-out is an environment variable, DO_NOT_TRACK=1. That is a simple mechanism and a reasonable default for an open source project, but it is opt-out rather than opt-in, so an organisation with a strict policy on outbound telemetry has to set the variable deliberately rather than rely on a prompt.

The repository also carries a SECURITY.md, a CODEOWNERS-style .github directory, gitleaks configuration in .gitleaksignore, and a gitguardian.yaml, which is the shape of a project that expects outside contributors. A .husky directory and a prepare script running husky, an oxlint configuration, prettier configuration and a typecheck script through turbo indicate the usual pre-commit and CI discipline. There is a STATS.md file at the top level, a CONTEXT.md and an AGENTS.md for agent-facing instructions, and an opencode-sync.md that presumably documents how the fork tracks upstream, with an UPSTREAM.md alongside it.

How BrowserCode compares with a plain browser automation script

The obvious alternative is writing the browser automation yourself with Playwright or Puppeteer. The difference in approach is who writes the script. With Playwright, you decide the steps, and the script is deterministic and reviewable. With BrowserCode, an agent decides the steps at runtime, writes the code, and the script is an output rather than an input.

That buys adaptability. A fixed script breaks when the page changes, and the fix is a code change and a redeploy. An agent that reads the page can cope with a flow it has never seen, which is why the README claims the agent adapts to every site at runtime. It also costs predictability, since an agent's script for the same task can differ between runs, and the debugging story becomes reading generated code rather than reading your code.

The second alternative is a coding agent without browser access, with browser work delegated to a separate tool. The README's argument is that separating them costs context: the agent has to describe what it sees in text and then act in text, and each round trip loses information. Driving Chrome directly over CDP keeps the browser and the code in the same loop.

The honest caveat is that this is a fork. The README is explicit that BrowserCode is not built by the OpenCode team, and the repository carries patches, a UPSTREAM.md and an opencode-sync.md, which means upstream changes have to be merged in by hand. That is a maintenance cost you accept when you adopt a fork rather than the upstream project, and it is the main reason to expect the prerelease tags to persist for a while.

Editorial conclusion

Adopt BrowserCode if your team wants a coding agent that can operate a real browser, test a local web application end to end, and reuse the resulting scripts, and you are willing to work with a project that is still shipping prerelease tags. Do not adopt it if you need a stable release cadence, if your environment blocks outbound traffic to model providers, or if you cannot accept anonymous usage traces, since opting out requires setting DO_NOT_TRACK. Verify first by running the installer and starting the TUI with a key for one model, then confirm on a page you control that the session persists across separate browser_execute calls.

Frequently asked questions

Official sources

1. browser-use/browsercode on GitHub
2. Issues
3. License: MIT
4. README
5. Releases