browser: drop chrome-relay auto-creation, simplify to user profile only by odysseus0 · Pull Request #45777 · openclaw/openclaw

odysseus0 · 2026-03-14T05:54:30Z

Summary

Stop auto-creating the chrome-relay (extension relay) browser profile. The auto-created user profile (existing-session / Chrome MCP) is the sole default user-browser path. Extension relay still works if explicitly configured.

Why: Chrome MCP (--autoConnect) works with zero setup on Chrome 146+ — no extension install, no chrome://inspect toggle, just Chrome running. Auto-creating chrome-relay alongside user added a profile that required manual setup (install extension, click toolbar icon) and caused resolution ambiguity.

Changes

src/browser/config.ts — Remove ensureDefaultChromeRelayProfile function and its call. Remove unused getUsedPorts import.
src/agents/tools/browser-tool.ts — Simplify tool description: remove chrome-relay references. Fix isHostOnlyProfileName to use capability check instead of hardcoded names.
src/agents/tools/browser-tool.actions.ts — Add user to stale-target retry check. Use dynamic profile name in error message.
src/browser/chrome-mcp.ts — Simplify error message: "Make sure Chrome (v146+) is running." (remove toggle guidance).
Tests — Update all tests referencing auto-created chrome-relay to use explicit fixtures or user profile.

What still works

Extension relay driver is not removed — users can still explicitly add an extension profile
user profile auto-creation unchanged
openclaw (managed sandbox) auto-creation unchanged
All relay startup/shutdown lifecycle code intact

Testing

66 browser tests pass (37 tool + 29 config)
Build clean, lint clean
Pre-existing failures only (tlon module, subagents)

greptile-apps · 2026-03-14T05:56:19Z

Greptile Summary

This PR removes the auto-creation of the chrome-relay browser profile, leaving user (Chrome MCP / --autoConnect) as the sole default user-browser path. The change is well-motivated: Chrome 146+ --autoConnect eliminates the need for a pre-installed extension, and the auto-created chrome-relay profile created resolution ambiguity. The core simplification in config.ts, browser-tool.ts, and chrome-mcp.ts is clean and correct.

Key issues:

Misleading error message for user profile (browser-tool.actions.ts:338): isChromeStaleTargetError was correctly extended to match profile === "user", but the !tabs.length fallback still says "No Chrome tabs are attached via the OpenClaw Browser Relay extension. Click the toolbar icon on the tab you want to control (badge ON), then retry." This message is only correct for the extension relay flow; a user hitting this path with profile="user" (Chrome MCP) receives wrong troubleshooting guidance. The error should branch on whether the profile is relay-based or MCP-based.

Minor observations (no action required):

The stale-target comment on browser-tool.actions.ts:317 ("Some Chrome relay targetIds…") still refers only to the relay, though it now also applies to the user profile.
isChromeStaleTargetError keeps hardcoded names ("chrome-relay", "chrome", "user") rather than using the capability-based approach now used by isHostOnlyProfileName. This is inconsistent but not incorrect, as "chrome" and "chrome-relay" are legacy-compatibility names rather than auto-created profiles.

Confidence Score: 3/5

Mostly safe to merge; one logical issue with a misleading error message that could confuse users troubleshooting profile="user" stale-target errors.
The core refactoring (removing ensureDefaultChromeRelayProfile, simplifying isHostOnlyProfileName, updating tests and descriptions) is clean and correct. The only real issue is the !tabs.length error message in executeActAction which is now reachable for profile="user" but still gives extension-relay-specific guidance, which will mislead users. This is a user-facing UX bug, not a data-loss or security issue, so it doesn't block merging but should be fixed before shipping.
src/agents/tools/browser-tool.actions.ts — the !tabs.length error branch at line 338 needs to be conditioned on the profile type.

Comments Outside Diff (1)

src/agents/tools/browser-tool.actions.ts, line 336-340 (link)

Misleading error message for user profile

Now that isChromeStaleTargetError includes profile === "user" (line 77), the !tabs.length branch (line 336) can be reached for the user profile. However, the error message still says "No Chrome tabs are attached via the OpenClaw Browser Relay extension. Click the toolbar icon on the tab you want to control (badge ON), then retry." — guidance that is exclusively relevant to the extension relay flow.

A user hitting a stale-target error with profile="user" (Chrome MCP / --autoConnect) would receive incorrect instructions to click a toolbar icon that has no effect in their workflow.

The fix should branch on whether the profile uses the relay extension vs. Chrome MCP:
```
if (!tabs.length) {
  const isRelayProfile = profile === "chrome-relay" || profile === "chrome";
  if (isRelayProfile) {
    throw new Error(
      "No Chrome tabs are attached via the OpenClaw Browser Relay extension. Click the toolbar icon on the tab you want to control (badge ON), then retry.",
      { cause: err },
    );
  }
  throw new Error(
    `No Chrome tabs found for profile="${profile}". Make sure Chrome (v146+) is running and has open tabs, then retry.`,
    { cause: err },
  );
}
```

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/agents/tools/browser-tool.actions.ts
Line: 336-340

Comment:
**Misleading error message for `user` profile**

Now that `isChromeStaleTargetError` includes `profile === "user"` (line 77), the `!tabs.length` branch (line 336) can be reached for the `user` profile. However, the error message still says "No Chrome tabs are attached via the OpenClaw Browser Relay extension. Click the toolbar icon on the tab you want to control (badge ON), then retry." — guidance that is exclusively relevant to the extension relay flow.

A user hitting a stale-target error with `profile="user"` (Chrome MCP / `--autoConnect`) would receive incorrect instructions to click a toolbar icon that has no effect in their workflow.

The fix should branch on whether the profile uses the relay extension vs. Chrome MCP:

```
if (!tabs.length) {
  const isRelayProfile = profile === "chrome-relay" || profile === "chrome";
  if (isRelayProfile) {
    throw new Error(
      "No Chrome tabs are attached via the OpenClaw Browser Relay extension. Click the toolbar icon on the tab you want to control (badge ON), then retry.",
      { cause: err },
    );
  }
  throw new Error(
    `No Chrome tabs found for profile="${profile}". Make sure Chrome (v146+) is running and has open tabs, then retry.`,
    { cause: err },
  );
}
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: eca7a2e}

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: eca7a2ec32

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

src/agents/tools/browser-tool.actions.ts

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: abe848dd9d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-03-14T06:07:55Z

src/browser/config.ts

+  const profiles = ensureDefaultUserBrowserProfile(
+    ensureDefaultProfile(
+      cfg?.profiles,
+      defaultColor,
+      legacyCdpPort,


Preserve legacy chrome-relay defaultProfile configs

Dropping ensureDefaultChromeRelayProfile makes previously valid configs like browser.defaultProfile: "chrome-relay" resolve to a default profile name that no longer exists in resolved.profiles, and createBrowserRouteContext.forProfile() will then throw Profile "chrome-relay" not found when callers omit profile. This breaks existing installs that relied on the old built-in relay default, so we should either migrate/fallback missing defaults or synthesize compatibility for this legacy setting.

Useful? React with 👍 / 👎.

chatgpt-codex-connector · 2026-03-14T06:07:55Z

src/agents/tools/browser-tool.actions.ts


 function isChromeStaleTargetError(profile: string | undefined, err: unknown): boolean {
-  if (profile !== "chrome-relay" && profile !== "chrome") {
+  if (profile !== "chrome-relay" && profile !== "chrome" && profile !== "user") {


Generalize stale-target handling beyond fixed profile names

After moving extension-relay usage to explicitly named profiles, this hardcoded allowlist (chrome-relay|chrome|user) means custom extension profiles (for example the new my-chrome flow) no longer enter stale-target recovery on 404: tab not found. In that case act skips the safe retry/helpful guidance path entirely even when a single tab is still available, so this should be keyed to resolved profile capabilities/driver instead of profile name literals.

Useful? React with 👍 / 👎.

…on (#16511) feat(cron): support persistent session targets for cron jobs (#9765) Add support for `sessionTarget: "current"` and `session:<id>` so cron jobs can bind to the creating session or a persistent named session instead of only `main` or ephemeral `isolated` sessions. Also: - preserve custom session targets across reloads and restarts - update gateway validation and normalization for the new target forms - add cron coverage for current/custom session targets and fallback behavior - fix merged CI regressions in Discord and diffs tests - add a changelog entry for the new cron session behavior Co-authored-by: kkhomej33-netizen <[email protected]> Co-authored-by: ImLukeF <[email protected]>

… errors (#11972)

…back)

@mukhtharcm

) Merged via squash. Prepared head SHA: 2846a6c Co-authored-by: teconomix <[email protected]> Co-authored-by: mukhtharcm <[email protected]> Reviewed-by: @mukhtharcm

* refactor: make OutboundSendDeps dynamic with channel-ID keys Replace hardcoded per-channel send fields (sendTelegram, sendDiscord, etc.) with a dynamic index-signature type keyed by channel ID. This unblocks moving channel implementations to extensions without breaking the outbound dispatch contract. - OutboundSendDeps and CliDeps are now { [channelId: string]: unknown } - Each outbound adapter resolves its send fn via bracket access with cast - Lazy-loading preserved via createLazySender with module cache - Delete 6 deps-send-*.runtime.ts one-liner re-export files - Harden guardrail scan against deleted-but-tracked files * fix: preserve outbound send-deps compatibility * style: fix formatting issues (import order, extra bracket, trailing whitespace) * fix: resolve type errors from dynamic OutboundSendDeps in tests and extension * fix: remove unused OutboundSendDeps import from deliver.test-helpers

…45531) Move all Signal channel implementation files from src/signal/ to extensions/signal/src/ and replace originals with re-export shims. This continues the channel plugin migration pattern used by other extensions, keeping backward compatibility via shims while the real code lives in the extension. - Copy 32 .ts files (source + tests) to extensions/signal/src/ - Transform all relative import paths for the new location - Create 2-line re-export shims in src/signal/ for each moved file - Preserve existing extension files (channel.ts, runtime.ts, etc.) - Change tsconfig.plugin-sdk.dts.json rootDir from "src" to "." to support cross-boundary re-exports from extensions/

* refactor: move WhatsApp channel from src/web/ to extensions/whatsapp/ Move all WhatsApp implementation code (77 source/test files + 9 channel plugin files) from src/web/ and src/channels/plugins/*/whatsapp* to extensions/whatsapp/src/. - Leave thin re-export shims at all original locations so cross-cutting imports continue to resolve - Update plugin-sdk/whatsapp.ts to only re-export generic framework utilities; channel-specific functions imported locally by the extension - Update vi.mock paths in 15 cross-cutting test files - Rename outbound.ts -> send.ts to match extension naming conventions and avoid false positive in cfg-threading guard test - Widen tsconfig.plugin-sdk.dts.json rootDir to support shim->extension cross-directory references Part of the core-channels-to-extensions migration (PR 6/10). * style: format WhatsApp extension files * fix: correct stale import paths in WhatsApp extension tests Fix vi.importActual, test mock, and hardcoded source paths that weren't updated during the file move: - media.test.ts: vi.importActual path - onboarding.test.ts: vi.importActual path - test-helpers.ts: test/mocks/baileys.js path - monitor-inbox.test-harness.ts: incomplete media/store mock - login.test.ts: hardcoded source file path - message-action-runner.media.test.ts: vi.mock/importActual path

…5621) Move all Slack channel implementation files from src/slack/ to extensions/slack/src/ and replace originals with shim re-exports. This follows the extension migration pattern for channel plugins. - Copy all .ts files to extensions/slack/src/ (preserving directory structure: monitor/, http/, monitor/events/, monitor/message-handler/) - Transform import paths: external src/ imports use relative paths back to src/, internal slack imports stay relative within extension - Replace all src/slack/ files with shim re-exports pointing to the extension copies - Update tsconfig.plugin-sdk.dts.json rootDir from "src" to "." so the DTS build can follow shim chains into extensions/ - Update write-plugin-sdk-entry-dts.ts re-export path accordingly - Preserve extensions/slack/index.ts, package.json, openclaw.plugin.json, src/channel.ts, src/runtime.ts, src/channel.test.ts (untouched)

* refactor: move Telegram channel implementation to extensions/telegram/src/ Move all Telegram channel code (123 files + 10 bot/ files + 8 channel plugin files) from src/telegram/ and src/channels/plugins/*/telegram.ts to extensions/telegram/src/. Leave thin re-export shims at original locations so cross-cutting src/ imports continue to resolve. - Fix all relative import paths in moved files (../X/ -> ../../../src/X/) - Fix vi.mock paths in 60 test files - Fix inline typeof import() expressions - Update tsconfig.plugin-sdk.dts.json rootDir to "." for cross-directory DTS - Update write-plugin-sdk-entry-dts.ts for new rootDir structure - Move channel plugin files with correct path remapping * fix: support keyed telegram send deps * fix: sync telegram extension copies with latest main * fix: correct import paths and remove misplaced files in telegram extension * fix: sync outbound-adapter with main (add sendTelegramPayloadMessages) and fix delivery.test import path

openclaw-barnacle · 2026-03-14T21:38:03Z