Bug type

Behavior bug (incorrect output/state without crash)

Summary

[Bug]: Browser tool forces Extension Relay mode even when using standalone profile

Summary

On desktop GUI environments (macOS/Windows/Linux with display), the browser tool defaults to the "chrome" extension relay profile — even when:

• The Chrome extension is not installed
• No relay connection has ever been established
• The user did not explicitly select the "chrome" profile

This results in a 10-minute timeout and a misleading error message.

More critically: even when the standalone "openclaw" profile is available and fully functional, the browser tool still forces Extension Relay mode. This makes the browser tool non-functional out-of-the-box for fresh desktop installs.

Steps to reproduce

1. Fresh OpenClaw install on macOS (GUI desktop, no headless, no Docker)
2. Do not install the Chrome Browser Relay extension
3. Do not add any browser config to openclaw.json
4. Ask the agent to use the browser tool (e.g. "open https://example.com")
5. Wait ~10 minutes

Expected behavior

• The browser tool should default to "openclaw" (standalone CDP mode)
• The tool should launch a managed Chrome instance immediately
• No extension should be required
• Relay mode should be opt-in

Actual behavior

The system:

1. Always creates a "chrome" profile (driver: "extension")
2. Defaults to "chrome" if it exists
3. Waits for extension relay connection
4. Times out after ~10 minutes

Error shown:

Chrome extension relay is running, but no tab is connected.
Click the OpenClaw Chrome extension icon on a tab to attach it (profile "chrome").

This is misleading because the extension was never installed and the user never chose relay mode.

Root cause

Layer 1 — Profile selection always picks relay:

ensureDefaultChromeExtensionProfile() unconditionally creates a "chrome" profile:

result.chrome = {
    driver: "extension",
    cdpUrl: `http://127.0.0.1:${relayPort}`,
    color: "#00AA00"
};

Then default selection logic does:

const defaultProfile = defaultProfileFromConfig
    ?? (profiles["chrome"] ? "chrome" : "openclaw");
//                           ^^^^^^^^ always true after auto-creation

Since "chrome" always exists, standalone is never chosen.

Layer 2 — Driver instantiation assumes relay (deeper issue):

Even when "openclaw" profile IS selected, parts of the browser tool internally assume extension relay mode. The tool layer does not strictly respect the resolved profile.driver. This suggests the bug is not only in profile resolution, but also in how the browser driver is instantiated.

Why this keeps regressing

Previous fixes addressed specific symptoms:

But none enforced the underlying invariant:

Standalone mode must never depend on relay state.

Because "chrome" profile is auto-created, future refactors will keep reintroducing this behavior unless the invariant is enforced at the driver layer.

Proposed fix

Instead of:

profiles["chrome"] ? "chrome" : "openclaw"

The system should:

1. Default to standalone ("openclaw")
2. Only activate relay if:
   • Extension driver is selected explicitly by the user
   • AND a relay connection has been observed
3. The browser tool must instantiate driver strictly from profile.driver, not from assumed relay availability

Temporary workaround

Add to ~/.openclaw/openclaw.json:

{
  "browser": {
    "defaultProfile": "openclaw"
  }
}

Then restart: openclaw gateway restart

Impact and severity

• Affected: All GUI desktop users without the Browser Relay extension (majority of new users)
• Severity: High — browser tool completely non-functional out-of-the-box
• Frequency: 100% reproducible on fresh installs
• Consequence: 10-minute blocking timeout → misleading error → recurring regression
• Type: Behavior Bug (Default Strategy Fault)

Environment

• OpenClaw: 2026.2.17 (build 4134875) — confirmed same behavior on 2026.3.1 without the config workaround
• OS: macOS 26.2 (Apple Silicon)
• Node: v22.21.1
• Chrome: 145.0.7632.117
• Install method: npm global

Steps to reproduce

1. Fresh OpenClaw install on macOS (GUI desktop, no headless, no Docker)
2. Do not install the Chrome Browser Relay extension
3. Do not add any browser config to openclaw.json
4. Ask the agent to use the browser tool (e.g. "open https://example.com")
5. Wait ~10 minutes

Expected behavior

• The browser tool should default to "openclaw" (standalone CDP mode)
• The tool should launch a managed Chrome instance immediately
• No extension should be required
• Relay mode should be opt-in

Actual behavior

The system:

1. Always creates a "chrome" profile (driver: "extension")
2. Defaults to "chrome" if it exists
3. Waits for extension relay connection
4. Times out after ~10 minutes

Error shown:

Chrome extension relay is running, but no tab is connected.
Click the OpenClaw Chrome extension icon on a tab to attach it (profile "chrome").

This is misleading because the extension was never installed and the user never chose relay mode.

OpenClaw version

2026.2.17

Operating system

macOS 26.2

Install method

npm global

Logs, screenshots, and evidence

### Logs, screenshots, and evidence

**Gateway error log** (`~/.openclaw/logs/gateway.err.log`):


2026-03-02T23:18:54.371+08:00 [tools] browser failed: Can't reach the OpenClaw browser control service.
  (Error: Chrome extension relay is running, but no tab is connected.
   Click the OpenClaw Chrome extension icon on a tab to attach it (profile "chrome").)

2026-03-02T23:39:22.312+08:00 [tools] browser failed: [...same error...] (profile "chrome")
2026-03-02T23:57:51.341+08:00 [tools] browser failed: [...same error...] (profile "chrome")
2026-03-02T23:59:47.284+08:00 [tools] browser failed: [...same error...] (profile "chrome")
2026-03-03T00:07:42.776+08:00 [tools] browser failed: [...same error...] (profile "chrome")


**Session-level statistics** (single session, ~12 hours):

| Metric | Count |
|--------|-------|
| Total browser tool calls | 126 |
| Relay timeout failures | 25 |
| Calls with no profile specified (→ falls back to default) | 35 |
| Calls with explicit `profile: "openclaw"` | 88 |

**Key pattern observed**: The agent starts standalone browser with `profile: "openclaw"` successfully, then on the *next* action (e.g. `snapshot`, `open`) omits the profile parameter → gateway falls back to `"chrome"` → relay timeout. This cycle repeats:


07:25:35 | CALL | action=start   profile=openclaw     ← standalone starts OK
07:25:41 | CALL | action=open    profile=DEFAULT       ← no profile → falls back to "chrome"
07:25:41 | FAIL | relay timeout error                  ← 💥 fails

07:28:58 | CALL | action=start   profile=openclaw     ← agent retries with openclaw
07:29:03 | CALL | action=open    profile=DEFAULT       ← forgets profile again
07:29:03 | FAIL | relay timeout error                  ← 💥 same failure


This pattern repeats **25 times** in a single session. Each failure costs ~10 minutes of wall-clock time due to relay timeout.

**Gateway log confirms standalone was always available**:


2026-03-02T15:18:14.843Z [browser/chrome] 🦞 openclaw browser started (chrome)
  profile "openclaw" on 127.0.0.1:18800 (pid 17948)


The standalone browser was running and reachable the entire time, but the tool kept routing requests to the relay.

Impact and severity

Impact and severity

• Affected: All GUI desktop users without the Browser Relay Chrome extension (majority of new users)
• Severity: High — browser tool completely non-functional out-of-the-box; each relay timeout blocks the agent for ~10 minutes
• Frequency: 100% reproducible. In my session: 25 out of 35 "no profile specified" calls failed (71% failure rate on the default path)
• Consequence:
  • Fresh installs cannot use browser tool without manual config workaround
  • Even after agent learns to specify profile: "openclaw", any follow-up call that omits the profile reverts to relay → fails again
  • Each failure wastes ~10 minutes of wall-clock time (relay timeout) plus API token cost for the retry loop
  • The misleading error message ("Click the OpenClaw Chrome extension icon") sends users on a wild goose chase for an extension they never installed

Additional information

Additional information

Regression context: This is not a regression from a specific version — the behavior exists since the "chrome" extension relay profile was introduced as auto-created. Prior fixes (#28687, #14895) addressed adjacent issues but left the GUI desktop default path untouched.

Related issues:

• [Bug]: Browser profile selection bug: chrome profile overrides openclaw even when explicitly specified #28687 — Profile from POST body was silently dropped (fixed in PR fix(gateway): honor browser profile from request body for node proxy calls #28852, merged 3 days ago)
• Browser snapshot/screenshot fails on Ubuntu Server headless environment #14895 / fix(browser): prefer openclaw profile in headless/noSandbox environments #14944 — Headless/noSandbox environments now prefer "openclaw" (merged)
• [Bug] Built-in browser (profile="openclaw") fails to start unless Chrome extension is connected (ON) #13166 — Built-in browser fails to start unless Chrome extension is connected
• Browser Control Broken #14215 — "Browser Control Broken" (likely same root cause, different surface)

Design observation: The current architecture has two independent default-selection paths that interact poorly:

1. resolveBrowserConfig() picks the default profile name ("chrome")
2. ensureBrowserAvailable() checks profile.driver === "extension" and routes to relay

A single-source-of-truth design where the profile's driver field alone determines the connection strategy would prevent this class of bug from recurring.