---
title: "OpenClaw browser automation with Chrome"
description: "OpenClaw automations stall at captchas, 2FA, and bot walls. HolaClaw lets the agent drive the real Chrome on your Mac, in a separate profile, so sites trust it."
updated: 2026-08-18
canonical: https://holaclaw.ai/blog/openclaw-browser-automation
---

OpenClaw is often used to automate web-based workflows: logging in to a site to pull data, downloading documents, filling in a form, checking on an account. It works well right up until the website is non-trivial. Then, it needs to read, act, and review in a loop. In addition to that, the agent might get trapped in captchas, two-factor prompts, and "this browser looks automated" bot checks.

HolaClaw makes it easy to install and run OpenClaw on your Mac. Now it can also let the agent drive the Google Chrome you already have installed in your Mac, while keeping the assistant sandboxed. It is the same Chrome application, but **the agent never touches your personal profile**. HolaClaw creates a separate, dedicated profile for it, with its own logins, cookies, history, and cache. Yours stay exactly where they are.

What you gain is that the agent is now driving a **real Chrome**, which is what websites are willing to trust. When a site does ask for a password or a 2FA code, the window is right there on your screen: HolaClaw pauses, you authenticate once in the agent's profile, and the automation continues.

> **Note: the lightweight browser is still here.** In [our last post](/blog/agent-browsers-for-openclaw) we went looking for the *lightest* browser we could hand the agent: a small, purpose-built one of its own that runs out of sight. That option hasn't gone anywhere, and it is still the right pick if your assistant barely touches the web, or only reads pages that don't need an account. What changed is that it is no longer the only option.

## Which browser should your assistant use?

The choice is part of creating an assistant: Step 3 of the wizard asks *"How should HolaClaw browse the web?"*, and whatever you pick there is set up for you before the assistant ever starts.

![Step 3 of the Create Assistant wizard, showing the Host option selected with Google Chrome detected, and the Isolated option below it](/images/blog/openclaw-browser-automation/browser-wizard-step.webp)

There are two options, depending on what you plan to do with the assistant.

- **Isolated.** A self-contained Chromium we install and run inside the sandboxed environment (a virtual machine). Zero setup, fully sandboxed, invisible to you. The right choice for simple web automations, such as retrieving data from public websites.
- **Chrome (host).** The real Google Chrome on your machine, with a profile just for the agent. You can log in, solve captchas, and sites stop treating it as a bot. The agent drives it, and you can watch it happen if you wish.

**Host mode is the one we recommend for most people.** The agent works in a window that is open on your desk, so you can watch a workflow run, take the wheel when a site asks for something only you can give it, and see immediately what went wrong when something didn't work.

## How does host mode work?

Everything in this section happens under the hood, when you create an assistant and when it starts. There is nothing here you have to set up, and nothing you can misconfigure. It is worth explaining anyway, because host mode has to solve something that sounds contradictory: the agent does not live on your Mac. It lives inside its own isolated VM, and that isolation is the whole point of HolaClaw. Your Chrome sits on the *other side* of that boundary.

### Same Chrome, totally different profiles

The first job is launching Chrome so that "use your real browser" never turns into "let the agent touch your real profile".

So HolaClaw starts Chrome with a hardened set of launch arguments. Two of them do the separating: an isolated `--user-data-dir` and its own `--disk-cache-dir`. That pair is what makes the wall real. A profile directory is where Chrome keeps logins, cookies, history, and saved passwords; point it somewhere else and you have, for every practical purpose, a different browser that happens to share the same engine. Websites see a completely ordinary Chrome. **Your own profile is never opened, never read, never modified.**

Three more arguments turn on CDP, the Chrome DevTools Protocol: the same debugging interface your browser exposes to its own developer tools, and the channel OpenClaw uses to drive the browser programmatically. Clicking a link, filling in a field, and reading the page all travel over it. Because CDP is effectively full control of the browser, we bind its listener to loopback (`127.0.0.1`), so nothing off your machine can reach it.

```text
--user-data-dir=<isolated profile>      # never your real Chrome profile
--disk-cache-dir=<isolated cache>       # its own cache, its own cookies
--remote-debugging-port=<free port>     # CDP listener…
--remote-debugging-address=127.0.0.1    # …bound to loopback only
--remote-allow-origins=*
--use-mock-keychain                     # no macOS Keychain prompts
--install-autogenerated-theme=191,116,252
```

The last flag paints the agent's Chrome a distinct purple, and the window opens on a page that says what it is. The moment a purple-tinted Chrome appears on your screen, you know exactly whose it is.

![The agent browser window, tinted purple, showing the HolaClaw agent browser landing page](/images/blog/openclaw-browser-automation/browser-chrome-instance.webp)

### Reaching across the boundary without opening it

Chrome's CDP endpoint is bound to `127.0.0.1` on the *host*. OpenClaw is inside the *guest*. Loopback on the host is, by design, not reachable from the VM, and we very much want to keep it that way. Punching a routable hole from the guest to a host debugging port would be exactly the kind of thing the isolation is there to prevent.

The answer is a **reverse SSH tunnel**, the same pattern HolaClaw already uses for local LLM and speech services. We open an SSH session *to the guest* and ask its `sshd` to listen on a fixed guest-local port. Every connection that port accepts is forwarded back over the encrypted SSH transport, and on the host side we splice it onto a fresh TCP stream to Chrome's real CDP port. From OpenClaw's point of view there is simply a CDP server at a stable, guest-local address that never changes. It has no idea the bytes are crossing a VM boundary at all.

### Telling OpenClaw where to look

The last piece is trivial by comparison, and deliberately so. OpenClaw picks its browser from configuration. Left alone, it launches and manages a local CDP endpoint itself. Point it at a CDP URL instead and it flips to remote attach, dialing whatever endpoint you give it rather than starting a browser of its own.

Because the tunnel's guest-side address is fixed, we can settle the whole browser configuration **once, at onboarding**, before any host browser or tunnel exists. Host mode points the assistant at the tunnel's CDP endpoint and nothing else; isolated mode points it at the bundled in-VM browser and nothing else. The two are mutually exclusive, and each is written as a single atomic change, so there is never a half-configured moment (a stale launch path left sitting next to a remote endpoint) where the assistant can't tell who owns the browser.

## How can OpenClaw avoid captchas and bot protections?

HolaClaw does not solve captchas or bypass bot protections. What host mode changes is how often they appear. Websites decide whether a visitor looks human from signals like the browser build, its fingerprint, and the state of its profile. A headless browser inside a VM fails several of those checks from the start, so automations get challenged more often, and some sites block them outright.

**The agent in host mode browses from a standard Chrome with a persistent profile, so most sites treat the session as ordinary browsing.** When a site still shows a captcha or asks for a 2FA code, the window is on your screen: you complete the check yourself and the automation continues. Because the agent's profile keeps its cookies and logins between runs, a check you pass once usually stays valid for the next run.

## Summary

HolaClaw now supports two browsers for OpenClaw: an isolated Chromium inside the VM, and the Google Chrome already installed on your Mac. Host mode runs that Chrome with a dedicated profile, binds CDP to loopback, and connects it to the sandboxed agent through a reverse SSH tunnel. Your own profile is never opened, and the agent's window stays visible on your screen.

Use the isolated browser for automations on public pages, and host mode when the workflow involves accounts, logins, or more complex interactions.

If you want to try it, [download HolaClaw](/download) and pick host mode in Step 3 when you create your assistant.