Official Google Chrome
ClawChrome runs real google-chrome-stable instead of a Chromium fork, patched browser, or hosted browser abstraction. Agents start from the same browser baseline a person would use.
Features
Browser control built for agents, not test scripts.
ClawChrome gives agents a real Chrome session, custom OS browser control, useful page-state output, and persistent browser context for workflows that break under raw CDP, WebDriver, or hosted browser sessions.
observe current page
Cookie preferences
Returned to the agent
visible_layer: cookie_preferences
clickable: Accept, Customize
blocked: page buttons behind overlay
The system calculates the page layers structurally. The agent receives the state it can act on, instead of a misleading list of elements hidden behind a blocking overlay.
Problem
Most browser tools were not designed for autonomous use.
- CDP and Playwright are excellent testing and debugging tools, but brittle when an agent has to drive unknown production websites.
- Banners, modals, native prompts, and overlays often hide the page from the agent or make the next action ambiguous.
- Proxy flags, patched fingerprints, and forked browser runtimes create browser profiles that do not match a normal desktop Chrome session.
Core features
The pieces that make agent browsing less brittle.
Custom OS browser control
Actions are driven outside the browser-side automation protocols that sites commonly inspect. Agents get browser control without making CDP or WebDriver the center of the workflow.
Structural page-layer handling
ClawChrome calculates the page layers so modal overlays, cookie banners, and blocking elements change what the agent sees and can click, the same way they do for a human user.
Agent-focused snapshots
The browser output is scoped to the useful interactive state of the page, not a raw debugging dump. When an element is blocked, the agent can be told what blocks it instead of guessing.
Persistent sessions and cookies
Chrome sessions can keep cookies and browser state across agent runs. When account access is needed, cookie sync can move an authenticated session into the agent workflow.
Custom OS network routing
Proxy configuration lives below Chrome instead of inside Chrome flags. Browser traffic is routed through the custom OS layer so the browser profile stays consistent with the network path.
01
Start Chrome
Create a real Chrome session for the agent instead of attaching to a user browser or launching a fork.
02
Connect MCP
Give the agent MCP-native browser actions for navigation, observation, clicking, typing, and extraction.
03
Use the page state
Return the elements that are actually available through the current page layers, including modal and banner state.
04
Keep the session
Persist cookies and session data so repeat workflows do not restart from a blank browser every time.
FAQ
Short answers for evaluators.
Is ClawChrome a Chrome fork?
No. ClawChrome is built around official Google Chrome with a custom OS control layer around it.
Does ClawChrome replace Playwright?
For agent browsing workflows, yes. Playwright and CDP are still useful for testing, but ClawChrome is designed for agents driving real sites where page state, overlays, sessions, and browser profile consistency matter.
Why does page-layer handling matter?
Agents need to know what can actually be interacted with. If a cookie banner blocks a button, returning the underlying button as clickable makes the workflow brittle. ClawChrome scopes the output to the current interactive state.
Can I use my own proxy?
Yes. The important difference is that proxy routing is handled below Chrome, rather than only by setting Chrome proxy flags.
Start with the setup path.
Connect an MCP client, start a Chrome session, and test the workflow that currently breaks under raw browser automation.