Back to Blog

How to Connect Claude Code to Your Active Browser Session with Chrome DevTools MCP

Reuse your logged-in Chrome tabs, cookies, and live web context instead of forcing Claude Code to start from a cold browser sandbox.

DV

Dzianis Vashchuk

7 min read

If you want Claude Code to work with the browser you already use every day, the important idea is simple:

you do not need a separate cold browser sandbox for every task.

OpenClaw can attach to your live Chrome session through Chrome DevTools MCP, which means the agent can reuse:

  • tabs that are already open
  • cookies that are already set
  • sites where you are already signed in
  • the real page state you are looking at right now

That is exactly what the built-in user browser profile is for.

Why this matters

A cold browser is fine for anonymous browsing.

But many real tasks are not anonymous:

  • reading a dashboard after login
  • working in GitHub, Linear, Notion, or Slack
  • checking an admin panel
  • continuing work in a tab you already prepared manually

In those cases, starting from a brand-new isolated browser is the wrong model.

You want the agent to attach to the browser session that is already carrying your context.

The OpenClaw browser profile you want

For an active local browser session, use:

  • profile="user"

This is different from the managed openclaw profile:

  • openclaw is isolated and launched by OpenClaw
  • user attaches to your existing signed-in Chrome session through Chrome MCP

That makes user the right choice when you want Claude Code to keep working inside your real browser state.

What to configure

The built-in user profile is already the correct starting point.

In ~/.openclaw/openclaw.json, keep the browser feature enabled:

{
  browser: {
    enabled: true
  }
}

If you want active-browser attach to be the default browser mode, you can set:

{
  browser: {
    enabled: true,
    defaultProfile: "user"
  }
}

After any browser config change, restart the gateway:

openclaw gateway restart

Prepare Chrome on macOS

Before OpenClaw can attach, Chrome needs to allow the Chrome DevTools MCP connection.

On your Mac:

  1. Open your normal Google Chrome
  2. Open chrome://inspect/#remote-debugging
  3. Enable remote debugging
  4. Keep Chrome open
  5. Approve the attach consent prompt when OpenClaw asks

Do not try to turn user into a raw CDP profile.

For this mode:

  • do not set cdpUrl
  • do not treat it like a remote browser service
  • do not expect OpenClaw to launch the browser for you

It attaches to an already-running browser session only.

How to verify the connection

These commands are the shortest useful smoke test:

openclaw browser --browser-profile user start
openclaw browser --browser-profile user status
openclaw browser --browser-profile user tabs
openclaw browser --browser-profile user snapshot --format ai

What success looks like:

  • status shows driver: existing-session
  • status shows transport: chrome-mcp
  • status shows running: true
  • tabs shows the tabs already open in Chrome
  • snapshot returns refs from the selected live tab

At that point, Claude Code can work against your active browser state instead of a fresh blank browser.

If you use Brave instead of Chrome

This is the main place people get confused.

For the existing-session path, user is meant for the default local Google Chrome profile.

If you want the same behavior for Brave, create a separate existing-session profile with userDataDir:

{
  browser: {
    profiles: {
      brave: {
        driver: "existing-session",
        attachOnly: true,
        userDataDir: "~/Library/Application Support/BraveSoftware/Brave-Browser",
        color: "#FB542B"
      }
    }
  }
}

Then enable remote debugging in:

brave://inspect/#remote-debugging

and verify with:

openclaw gateway restart
openclaw browser --browser-profile brave start
openclaw browser --browser-profile brave status
openclaw browser --browser-profile brave tabs

The important distinction is:

  • browser.executablePath changes the managed browser executable
  • userDataDir changes which live browser profile Chrome MCP attaches to

They solve different problems.

Common failures

1. The browser commands seem disabled

Check:

  • browser.enabled is true
  • the bundled browser plugin is not disabled
  • if you use plugins.allow, it includes "browser"

Then restart the gateway:

openclaw gateway restart

2. user still does not attach

Check these in order:

  1. Chrome is open
  2. remote debugging is enabled in chrome://inspect/#remote-debugging
  3. you approved the attach prompt
  4. you are using Chrome 144+

Then rerun:

openclaw browser --browser-profile user start
openclaw browser --browser-profile user status
openclaw browser --browser-profile user tabs

3. You changed config but nothing happened

Restart the gateway:

openclaw gateway restart

Browser config changes are not hot-reloaded into the running browser service.

The short recommendation

If your goal is to let Claude Code use your real local browser context:

  • keep the browser feature enabled
  • use profile="user" for your signed-in Chrome session
  • use defaultProfile: "user" only if you want that mode all the time
  • use a separate existing-session profile with userDataDir for Brave or another Chromium browser
  • restart the gateway after config changes

Official references: