fix(browser): default to openclaw profile when unspecified by liuxiaopai-ai · Pull Request #31913 · openclaw/openclaw

liuxiaopai-ai · 2026-03-02T16:45:06Z

Summary

Problem: Browser default profile routing could prefer the auto-created chrome extension-relay profile when browser.defaultProfile was unset, causing no-profile tool calls to hit relay timeout paths.
Why it matters: Fresh desktop installs without relay attachment can see repeated browser-tool failures and long timeout loops.
What changed: Switched the default browser profile fallback to openclaw (managed local browser) and kept the chrome profile available for explicit opt-in.
What changed: Updated browser config tests to assert new default behavior while still validating chrome profile creation.
What did NOT change (scope boundary): Explicit browser.defaultProfile continues to override defaults; extension relay behavior and availability checks are unchanged.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

When browser.defaultProfile is not configured, browser actions now default to openclaw instead of chrome.
The built-in chrome relay profile is still auto-created and can still be selected explicitly.

Security Impact (required)

New permissions/capabilities? (No)
Secrets/tokens handling changed? (No)
New/changed network calls? (No)
Command/tool execution surface changed? (No)
Data access scope changed? (No)
If any Yes, explain risk + mitigation:

Repro + Verification

Environment

OS: macOS (dev)
Runtime/container: local CLI tests
Model/provider: N/A
Integration/channel (if any): Browser tool runtime config path
Relevant config (redacted): default browser config with no explicit browser.defaultProfile

Steps

Resolve browser config with default settings and no explicit defaultProfile.
Read resolved default profile and resolved openclaw/chrome profile definitions.
Validate explicit defaultProfile: "chrome" overrides still work.

Expected

Unset default uses openclaw.
chrome relay profile remains available for explicit usage.

Actual

Matches expected after patch.

Evidence

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Human Verification (required)

Verified scenarios:
- Default config resolves defaultProfile = "openclaw".
- chrome profile still resolves as extension-driver relay profile.
- Explicit defaultProfile: "chrome" remains honored.
Edge cases checked:
- Headless/noSandbox paths still resolve to openclaw.
- Profile deletion/status tests still pass under new default.
What you did not verify:
- End-to-end desktop relay attach flow in a live GUI session.

Compatibility / Migration

Backward compatible? (Yes)
Config/env changes? (No)
Migration needed? (No)
If yes, exact upgrade steps:

Failure Recovery (if this breaks)

How to disable/revert this change quickly:
- Set browser.defaultProfile: "chrome" in config.
- Or revert this commit.
Files/config to restore:
- src/browser/constants.ts
- src/browser/config.ts
- src/browser/config.test.ts
Known bad symptoms reviewers should watch for:
- Unexpected fallback to extension-relay when browser.defaultProfile is unset.

Risks and Mitigations

Risk: Operators who implicitly depended on chrome default behavior may observe changed routing.
- Mitigation: Explicit browser.defaultProfile: "chrome" continues to force legacy behavior.

aisle-research-bot · 2026-03-02T16:45:14Z

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

#	Severity	Title
1	🔵 Low	Insecure default: unauthenticated local Chrome CDP becomes default profile (openclaw)

1. 🔵 Insecure default: unauthenticated local Chrome CDP becomes default profile (openclaw)

Property	Value
Severity	Low
CWE	CWE-1188
Location	`src/browser/config.ts:267-271`

Description

The change makes the built-in openclaw profile the default browser profile (previously chrome, which uses the authenticated extension relay). As a result, OpenClaw will now commonly launch/control a local Chrome instance via a plain CDP port that has no authentication layer.

Why this matters:

The openclaw driver launches Chrome with --remote-debugging-port=... (CDP HTTP + WebSocket) and does not add any auth/token checks.
Any other local process on the same machine can connect to that loopback port and issue CDP commands (full browser control within that profile).
Previously, the default chrome profile used the extension relay, which enforces an auth token for /json/* and WebSocket upgrades.

Code references:

Default changed to openclaw:
- src/browser/constants.ts sets DEFAULT_BROWSER_DEFAULT_PROFILE_NAME = "openclaw".
Default selection now prefers that value unconditionally when present:
- src/browser/config.ts picks DEFAULT_BROWSER_DEFAULT_PROFILE_NAME as the default profile.
openclaw driver launches Chrome exposing CDP:
- src/browser/chrome.ts uses --remote-debugging-port=${profile.cdpPort}.
In contrast, the extension relay requires a token for /json/* routes:
- src/browser/extension-relay.ts checks getRelayAuthTokenFromRequest() before serving /json/*.

Vulnerable behavior is introduced by making the unauthenticated CDP-backed profile the default, increasing exposure in default installs/configs.

Recommendation

Avoid making an unauthenticated CDP endpoint the default, or add an authentication boundary in front of it.

Options:

Keep the authenticated extension relay as the default and require explicit opt-in for openclaw:

// Prefer extension relay by default
export const DEFAULT_BROWSER_DEFAULT_PROFILE_NAME = "chrome";

If openclaw must remain default, introduce an authenticated local proxy for Chrome CDP (similar to the extension relay token gating) and have the rest of the system talk only to that proxy, not directly to Chrome’s raw CDP port.

Additionally, consider explicitly pinning loopback binding via Chrome flags (defense-in-depth):

args.push("--remote-debugging-address=127.0.0.1");
args.push(`--remote-debugging-port=${profile.cdpPort}`);

This does not add auth, but reduces the risk of unexpected non-loopback binding across platforms/versions.

Analyzed PR: #31913 at commit 106ab55

_{Last updated on: 2026-03-02T17:03:22Z}

greptile-apps · 2026-03-02T16:49:58Z

Greptile Summary

Changes the default browser profile from chrome (extension relay) to openclaw (managed local browser) when browser.defaultProfile is not explicitly configured. This prevents timeout issues on fresh desktop installs where the extension relay isn't available. The chrome profile remains auto-created and accessible for explicit opt-in via config.

Confidence Score: 5/5

This PR is safe to merge with minimal risk
The change is straightforward with well-defined scope: updates a single constant and simplifies config resolution logic. Tests are comprehensive and verify both default behavior and backward compatibility with explicit config overrides. The change maintains full compatibility - users can still explicitly set defaultProfile: "chrome" to preserve legacy behavior.
No files require special attention

_{Last reviewed commit: 106ab55}

greptile-apps

_{4 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-03-02T16:50:02Z

src/browser/config.ts

  const defaultProfile =
    defaultProfileFromConfig ??
-    (preferOpenClawProfile && profiles[DEFAULT_OPENCLAW_BROWSER_PROFILE_NAME]
-      ? DEFAULT_OPENCLAW_BROWSER_PROFILE_NAME
-      : profiles[DEFAULT_BROWSER_DEFAULT_PROFILE_NAME]
-        ? DEFAULT_BROWSER_DEFAULT_PROFILE_NAME
-        : DEFAULT_OPENCLAW_BROWSER_PROFILE_NAME);
+    (profiles[DEFAULT_BROWSER_DEFAULT_PROFILE_NAME]
+      ? DEFAULT_BROWSER_DEFAULT_PROFILE_NAME
+      : DEFAULT_OPENCLAW_BROWSER_PROFILE_NAME);


Ternary is now redundant since DEFAULT_BROWSER_DEFAULT_PROFILE_NAME and DEFAULT_OPENCLAW_BROWSER_PROFILE_NAME are both "openclaw". Could simplify to:

Suggested change

const defaultProfile =

defaultProfileFromConfig ??

(preferOpenClawProfile && profiles[DEFAULT_OPENCLAW_BROWSER_PROFILE_NAME]

? DEFAULT_OPENCLAW_BROWSER_PROFILE_NAME

: profiles[DEFAULT_BROWSER_DEFAULT_PROFILE_NAME]

? DEFAULT_BROWSER_DEFAULT_PROFILE_NAME

: DEFAULT_OPENCLAW_BROWSER_PROFILE_NAME);

(profiles[DEFAULT_BROWSER_DEFAULT_PROFILE_NAME]

? DEFAULT_BROWSER_DEFAULT_PROFILE_NAME

: DEFAULT_OPENCLAW_BROWSER_PROFILE_NAME);

const defaultProfile = defaultProfileFromConfig ?? DEFAULT_BROWSER_DEFAULT_PROFILE_NAME;

Prompt To Fix With AI

This is a comment left during a code review. Path: src/browser/config.ts Line: 267-271 Comment: Ternary is now redundant since `DEFAULT_BROWSER_DEFAULT_PROFILE_NAME` and `DEFAULT_OPENCLAW_BROWSER_PROFILE_NAME` are both `"openclaw"`. Could simplify to: ```suggestion const defaultProfile = defaultProfileFromConfig ?? DEFAULT_BROWSER_DEFAULT_PROFILE_NAME; ``` How can I resolve this? If you propose a fix, please make it concise.

velamints2 · 2026-03-02T17:20:58Z

"Thanks for the quick PR! I've been doing a deeper dive into the logs and realized that the bug actually exists at two levels. While this PR addresses the Layer 1 (config fallback), there’s a Layer 2 (driver instantiation) issue in ensureBrowserAvailable() that will still cause relay timeouts even with your change.

To ensure a complete fix and prevent regressions, I’ve prepared a comprehensive PR that refactors both layers. I'll link it here shortly so the maintainers can compare."

velamints2 · 2026-03-02T17:52:00Z

"Update: I've submitted PR #31972which comprehensively fixes this. It cleans up the underlying config logic and fixes the outdated documentation. Ready for review!"

liuxiaopai-ai · 2026-03-02T18:12:48Z

Thanks for the detailed follow-up and for opening #31972 with the broader fix.

Closing this PR as superseded so review can stay focused in #31972.

fix(browser): default to openclaw profile

106ab55

openclaw-barnacle bot added size: XS experienced-contributor labels Mar 2, 2026

greptile-apps bot reviewed Mar 2, 2026

View reviewed changes

velamints2 mentioned this pull request Mar 2, 2026

fix(browser): default to openclaw profile and simplify default selection logic #31972

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(browser): default to openclaw profile when unspecified#31913

fix(browser): default to openclaw profile when unspecified#31913
liuxiaopai-ai wants to merge 1 commit intoopenclaw:mainfrom
liuxiaopai-ai:codex/browser-default-openclaw-31907

liuxiaopai-ai commented Mar 2, 2026

Uh oh!

aisle-research-bot bot commented Mar 2, 2026 •

edited

Loading

Uh oh!

greptile-apps bot commented Mar 2, 2026

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Mar 2, 2026

Uh oh!

velamints2 commented Mar 2, 2026

Uh oh!

velamints2 commented Mar 2, 2026

Uh oh!

liuxiaopai-ai commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

liuxiaopai-ai commented Mar 2, 2026

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Uh oh!

aisle-research-bot bot commented Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔒 Aisle Security Analysis

1. 🔵 Insecure default: unauthenticated local Chrome CDP becomes default profile (openclaw)

Description

Recommendation

Uh oh!

greptile-apps bot commented Mar 2, 2026

Greptile Summary

Confidence Score: 5/5

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Mar 2, 2026

Choose a reason for hiding this comment

Uh oh!

velamints2 commented Mar 2, 2026

Uh oh!

velamints2 commented Mar 2, 2026

Uh oh!

liuxiaopai-ai commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

aisle-research-bot bot commented Mar 2, 2026 •

edited

Loading