How to resolve OpenClaw browser automation failure after upgrading to 2026.3.22-beta.1

Mar 24, 2026

Problem: Browser automation stopped working

I upgraded OpenClaw to version 2026.3.22-beta.1, and suddenly my browser automation scripts stopped working. When I tried to run any browser-related command, I got this error:

Error: Browser driver 'extension' is no longer supported
Please migrate to existing-session driver
See: openclaw doctor --fix

I checked my configuration and saw I was still using the old extension relay method:

browser:
  driver: extension
  relayBindHost: "127.0.0.1:9223"
  headless: false

What happened? The Chrome extension relay path was completely removed in this beta release.

Investigation: Understanding the breaking change

I looked at the OpenClaw 2026.3.22-beta.1 release notes and found that the Chrome extension relay was deprecated and removed. Here’s what changed:

What was removed:

Chrome extension relay connection method entirely
Bundled Chrome extension assets
driver: 'extension' configuration option
browser.relayBindHost setting

What still works:

Docker-based browser sessions (uses raw CDP)
Headless browser mode (uses raw CDP)
Sandbox mode (uses raw CDP)
Remote browser connections (uses raw CDP)

The unaffected modes all use Chrome DevTools Protocol (CDP) directly, bypassing the extension relay entirely.

I tried to manually update my configuration file, but I realized there might be other changes I’d miss. The recommended approach is to use the built-in migration tool.

Solution: Running the migration command

The OpenClaw team provides a built-in migration tool. I ran this command:

openclaw doctor --fix

Here’s what the command output:

Checking OpenClaw configuration...
Found deprecated browser driver: extension
Migrating to existing-session driver...

Updated ~/.openclaw/config.yaml:
  - Removed: driver: extension
  - Removed: relayBindHost: 127.0.0.1:9223
  - Added: driver: existing-session
  - Added: debugPort: 9222

Migration complete!
Please restart Chrome with: google-chrome --remote-debugging-port=9222

After the migration, my configuration looked like this:

browser:
  driver: existing-session
  debugPort: 9222
  headless: false

Launching Chrome with debugging enabled

The existing-session driver requires Chrome to be launched with remote debugging enabled. I ran:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 &

For Linux:

google-chrome --remote-debugging-port=9222 &

For Windows:

chrome.exe --remote-debugging-port=9222

Verifying the CDP connection

To confirm everything was working, I tested the CDP connection:

curl http://localhost:9222/json/version

The expected response:

{
   "Browser": "Chrome/134.0.6998.35",
   "Protocol-Version": "1.3",
   "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36",
   "V8-Version": "13.4.114",
   "WebKit-Version": "537.36",
   "webSocketDebuggerUrl": "ws://localhost:9222/devtools/browser/a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}

Now my browser automation scripts work again.

Why this change matters

Extension Relay (Deprecated approach)

The extension relay method worked like this:

OpenClaw bundled a Chrome extension
OpenClaw communicated with the extension via WebSocket
The extension controlled the browser using Chrome APIs

This had several issues:

Required extension installation and updates
Extra configuration with relay bind host
Potential security concerns with extension permissions
Added complexity with an extra hop in communication

Existing-Session Driver (Current approach)

The existing-session driver:

Uses Chrome DevTools Protocol (CDP) directly
Connects to an already-running browser instance
No extension installation required
Direct WebSocket connection to browser’s debug port

This is cleaner because:

Fewer moving parts
Direct CDP access (same as Docker/headless modes)
Better security (no extension with broad permissions)
Consistent architecture across all browser modes

Common mistakes to avoid

Mistake 1: Forgetting to launch Chrome with debugging

After migration, Chrome must be launched with --remote-debugging-port=9222. Without this, OpenClaw cannot connect to the browser.

# This won't work with existing-session driver
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

Mistake 2: Using a different debug port

If your configuration specifies debugPort: 9222, you must launch Chrome with the same port:

browser:
  driver: existing-session
  debugPort: 9222  # Must match Chrome's --remote-debugging-port

Mistake 3: Ignoring Docker mode as an alternative

If the existing-session driver feels too manual, Docker mode provides an even simpler setup:

openclaw config set browser.driver docker
openclaw start

Docker containers come pre-configured with everything needed for browser automation.

Mistake 4: Not removing old references

If you have scripts that reference browser.relayBindHost, remove those references:

browser:
  driver: extension
  relayBindHost: "127.0.0.1:9223"

---

# After (migrated)
browser:
  driver: existing-session
  # relayBindHost removed - no longer needed

Manual migration (if needed)

If openclaw doctor --fix doesn’t work for your setup, here’s how to migrate manually:

# 1. Stop OpenClaw
pkill -f openclaw

# 2. Edit configuration
vim ~/.openclaw/config.yaml

# 3. Change these settings:
#    driver: extension  ->  driver: existing-session
#    Remove: relayBindHost line
#    Add: debugPort: 9222

# 4. Launch Chrome with debugging
google-chrome --remote-debugging-port=9222 &

# 5. Restart OpenClaw
openclaw start

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

👨‍💻 OpenClaw 2026.3.22-beta.1 Release Notes
👨‍💻 Chrome DevTools Protocol Documentation
👨‍💻 OpenClaw Documentation

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!