Browser Control hands an agent the browser you are already logged into

Driving the browser you are already logged into

Browser Control lets a coding agent run browser automation against the Chromium browser already open on your machine, using your real profile with its logged-in sessions and installed extensions, rather than starting a clean headless browser.

The problem that solves is authentication. Conventional automation launches a fresh browser with no cookies, so anything behind a login requires scripting the login, storing credentials somewhere a script can read them, and surviving whatever multi-factor step the site imposes. Driving the browser where you are already signed in removes that entire category of work, because the session exists before the agent arrives.

The architecture is a chain of four hops, and the README draws it: the agent or command line talks to a local relay, the relay talks to a browser extension, and the extension drives your browser.

One line defines the scope more usefully than the feature list. The driver runs locally and contains no model and makes no planning decisions. Its interface is code: an agent sends a snippet of browser automation and receives the result, the logs, any warnings, and a summary of what changed. The judgement stays with the agent, and this is the hands.

Three installation steps, and the third one is manual

Setup has three parts and the README is clear that the protocol server is a fourth, optional piece rather than a requirement.

The package installs globally and brings two commands, one for command line and skill-driven agents and one for protocol clients.

npm install --global @opencode-ai/browser-control

Teaching the agent how to use it is separate, shipped as a skill installed through a dedicated tool. The README describes what that skill carries: inspecting before acting, preserving session identity, handling steps only a person can complete, and recovering when the browser fails.

npx skills add anomalyco/browser-control --skill browser-control -g

Notably, the project does not edit your agent configuration itself, and offers a command that prints the bundled instruction text so you can inspect or install it by hand. For a tool that will be handed control of an authenticated browser, refusing to silently modify configuration is the right instinct.

The third step is manual and will stay in the way until it changes: the extension ships unpacked inside the package, so you print its directory, open the browser's extension page, enable developer mode, load the unpacked directory and pin the toolbar button. Enabling developer mode is itself a change to the browser's posture, and anyone with a managed browser policy should expect this step to be where adoption stops.

Verifying the installation is one command, and it exercises the whole chain.

browser-control execute 'await page.goto("https://example.com"); return { title: await page.title(), url: page.url() }'

A successful run returns the page title, a session identifier and the exact command to continue in that session. The relay starts detached on a fixed local port and stays running between calls.

The read-only commands never start anything

A small design decision runs through the command surface and deserves calling out, because it is the kind of thing that only matters once you are debugging at an awkward moment.

Diagnostic commands are read-only. They report a stopped relay rather than starting one, and a separate command exists for running the relay in the foreground when you actually want to watch it.

browser-control doctor
browser-control status

The same rule extends to the protocol server. Initialisation, tool discovery, printing the skill and asking which session is current do not contact or start the relay. Only the first operational call does, and observational tools backed by the relay report it as unavailable rather than quietly launching it.

That distinction is worth more than it sounds. A diagnostic that starts the thing it is diagnosing destroys the evidence, and an agent that discovers tools should not thereby launch a background process on your machine. Getting this right suggests someone thought about what happens when the system misbehaves rather than only about the happy path.

Sessions follow the same clarity. A bare execution creates a fresh session, and passing its identifier continues with the same page. Command line and protocol clients share one detached relay while each execution session keeps its own default page and persistent state, so restarting a protocol process does not interrupt an active command line session.

The typed client is where the security thinking shows

Beyond sending automation snippets, the package exports a typed client for applications that need browser-authenticated requests without executing generated code, and its constraints are the most interesting part of the project.

Requests go through the page's own fetch in the session's current page, so cookies stay in the browser and are never handed to the calling program. Paths must be same-origin. Redirects are blocked. Responses are bounded. Mutations are never retried automatically.

Each of those closes a specific hole. Same-origin and blocked redirects prevent an authenticated request being steered somewhere else. Bounded responses prevent a hostile page exhausting the caller. Refusing to retry mutations is the one most systems get wrong, because an automatic retry of a request whose outcome is unknown is how duplicate payments happen.

Values can be marked sensitive, which returns them wrapped so they are not printed by accident, with an explicit call required to unwrap them. Sensitive requests bypass the execution journal and are rejected outright while session network capture is active, which is a thoughtful interlock: the journal and the capture are both places a secret would otherwise be written down.

A separate mechanism runs a trusted child process with secrets supplied as environment variables, where the parent never receives the raw values and known values are redacted from the child's captured output. The public interface deliberately does not expose raw profile reads.

This is a serious amount of care for a version 0.7 tool, and it is the right amount given what the tool does.

What you are actually agreeing to

The honest framing is in the project's own description: this is for trusted agents. An agent driving your authenticated browser can do anything you can do in that browser, which includes reading your mail, moving money and changing account settings, and no same-origin rule prevents that, because those actions are same-origin.

The protections described above are real and they address a different threat, namely a hostile or confused page rather than a misbehaving agent. Nothing here constrains what a trusted agent may do with a session you have already authenticated.

Practical consequences follow. Use it with agents and prompts you control. Expect the developer-mode extension requirement to be disqualifying on a managed device. Prefer a browser profile that is not the one holding your most sensitive logins, since the profile is the blast radius.

Other limits are more ordinary. The version is 0.7.1, so the interface is not settled. The runtime floor is Node 22.19, which is recent. The extension being unpacked means it is loaded outside the normal extension distribution path, so it does not update the way a published extension would.

The last push and the most recent release both fall on 2026-09-15, and that release is a patch covering snapshot labelling, clarification that execution target selection is per call, and keeping a runtime dependency aligned so clean installations start successfully. Small, specific and recent is what you want to see.

Headless automation is the alternative, and the split is the session

The alternative is conventional automation: launch a fresh browser under the automation library's control, in a container if you like, with no profile and no extensions.

The difference is reproducibility against access. A clean browser starts identical every time, runs on a build server, parallelises across workers, and leaves no trace in anything you use personally. It also starts logged out, so every authenticated flow becomes a credential management problem, and sites that challenge unfamiliar sessions will challenge it.

Browser Control inverts both sides. You get the logged-in session for free and you give up reproducibility, because the starting state is whatever your browser happens to be in, and you cannot parallelise beyond the browsers you actually run. It is also tied to a machine with a person's browser on it.

That makes the choice unusually clean. For automated testing, scheduled scraping or anything in continuous integration, headless is correct and this is not a candidate. For an agent doing a one-off task on your behalf inside services you are already signed into, this removes the hardest part of the job, and the security question moves from credential storage to whether you trust the agent.

MIT terms and the shape of the repository

Browser Control is MIT licensed, which for a developer tool of this kind is the expected choice.

The repository is arranged like something maintained rather than published once: a changeset directory for release notes, a changelog, a documentation directory, the extension source, a skills directory holding the agent instructions, a test directory, a performance directory, an unused-code checker configuration, and workspace configuration for a monorepo. Instruction files for coding agents sit at the root alongside context and planning documents, so the project is developed with the kind of agent it serves.

Shipping the agent instructions as a versioned artifact in the repository, rather than as prose in a README someone copies, is the detail worth borrowing. The instructions are part of the product, they change with the interface, and treating them as code means they stay in step.

Upgrade cost has one awkward corner. Updating the package is ordinary, but the extension is loaded unpacked from inside the package directory, so an upgrade that changes the extension may require reloading it in the browser. That is the price of the current distribution method, and the README's description of it as the way the extension currently ships suggests the project knows it.

Editorial conclusion

Browser Control fits an agent doing work on your behalf inside services you are already signed into, where launching a clean browser would mean building credential handling you do not want to build. Keep it away from continuous integration and scheduled jobs, where a headless browser's reproducibility and parallelism matter more than an existing session. Before installing, note that the extension ships unpacked and requires developer mode in the browser, which will fail on a managed device, and consider pointing it at a browser profile that does not hold your most sensitive logins, because a trusted agent in that profile can do anything you can do there.

Frequently asked questions

Official sources

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