* feat(browser): import Chrome-family system-profile cookies into managed profiles
Import cookies from a real Chrome/Brave/Edge/Chromium system profile (macOS)
into a fresh OpenClaw-managed browser profile so the agent can browse as the
signed-in user. Reads the source Cookies DB via a coherent VACUUM INTO snapshot,
decrypts v10 AES-128-CBC values with the Safe Storage Keychain key (one Touch ID
consent), maps rows to Playwright cookies (FILETIME expiry, SameSite, M124+
domain-hash prefix strip, CHIPS skipped), and best-effort injects them via
addCookies into a mock-keychain profile so they persist without further prompts.
Decrypted values are never logged or returned.
Exposed as agent tool action=importprofile, CLI system-profiles/import-profile,
and POST /profiles/import; action=profiles surfaces importable systemProfiles.
Listing and import are pinned host-local at every surface (gateway, browser
tool, node proxy) since they read the local Keychain and Chrome profiles.
Malformed domain filters fail closed via a shared validator. Gated by
browser.allowSystemProfileImport (default on). Imports cookies only.
* fix(browser): satisfy CI lint (OpenClaw temp dir, Unicode control-char class)
Use resolvePreferredOpenClawTmpDir() instead of os.tmpdir() for the cookie DB
snapshot (messaging/channel runtime tmpdir guard), and match control characters
via the Unicode \p{Cc} class instead of a literal control-char range so the
CLI table sanitizer passes the no-control-regex lint.
* fix(browser): reject ambiguous tab references
Co-authored-by: llagy007 <0668001470@xydigit.com>
* fix(browser): close tracked tabs by raw target id
* fix(browser): harden raw tab cleanup routing
* test(browser): type raw close request mock
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(browser): remove hardcoded profile="user" suggestion from browser tool description
The browser tool description hardcoded a suggestion to use profile="user"
for logged-in sessions, even when the operator has configured a different
default profile (e.g. browser.defaultProfile: "openclaw").
Replace with profile-agnostic guidance that references the configured
browser.defaultProfile setting instead of prescribing a specific value.
Fixes#102566
* test: update browser tool description assertion for profile-agnostic wording
* refactor(browser): unify tool profile guidance
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(browser): preserve strict CDP discovery policy on target-list lookup
findPageByTargetIdViaTargetList fetched the CDP /json/list endpoint without
passing an ssrfPolicy argument, so the caller's discovery policy was dropped at
the fetch layer while the sibling tryTerminateExecutionViaCdp scoped it. Build
the scoped control policy with scopeCdpPolicyToConfiguredEndpoint and pass it to
fetchJson, matching the sibling lookup path.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* test(browser): tighten target-list CDP policy test comment
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* test(browser): consolidate target-list SSRF coverage
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* feat(browser): direct extension→gateway relay path for remote Chrome (#53599)
Let the OpenClaw Chrome extension pair directly to a remote gateway over
wss:// with no OpenClaw node host on the browser machine — the managed-hosting
path from #53599 (extension is the only thing installed on the laptop).
- Gateway route /browser/extension registered by the browser plugin with
auth:"plugin" + no nodeCapability, so the gateway does not pre-enforce token
auth (browser WebSockets cannot send an Authorization header). The upgrade
handler self-validates the host-local relay secret from ?token=, origin-checks
chrome-extension://, resolves the extension profile, then attaches the socket
to the same ExtensionRelayBridge the loopback relay uses. All CDP synthesis,
tab-group scoping, and the in-process Playwright /cdp client are unchanged.
- `openclaw browser extension pair --gateway-url wss://host` prints a
wss://host/browser/extension#<secret> string; the path ends in /extension so
the extension's existing pairing parser accepts it with zero extension code
changes.
- relay-server: extract attachExtensionWebSocket + export requestToken /
isAllowedExtensionOrigin / EXTENSION_RELAY_MAX_PAYLOAD_BYTES so loopback and
gateway paths share one bind + one frame cap.
- runtime-lifecycle: dispose the shared gateway WebSocketServer on shutdown.
- docs: three remote topologies (same host / direct-to-gateway / via node host).
Coverage: 6 unit tests for the handler's path/503/403/404/401/attach branches.
The full extension→bridge→CDP→Chrome loop over /browser/extension was live-proven
with a real Chrome + the built extension. The real gateway upgrade→handleUpgrade
dispatch for an auth:"plugin" unprotected route is verified against core
(server-http.ts, plugins-http.ts, route-auth.ts).
* fix(browser): harden remote extension pairing
* fix(browser): guard readFields JSON.parse against malformed user input
Wraps JSON.parse(payload) in readFields() with try/catch, throwing a
descriptive Error when CLI --fields or --fields-file input contains
malformed JSON instead of raw SyntaxError.
8/8 proof assertions pass using standalone script that imports and
calls the real exported readFields() with malformed field strings.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: lsr911 <liao.shirong@xydigit.com>
* fix(browser): add vitest malformed JSON tests, remove standalone proof
ClawSweeper feedback: added 2 vitest tests (malformed JSON, empty fields)
to the existing shared.test.ts, removed standalone proof script.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: lsr911 <liao.shirong@xydigit.com>
* fix(browser): cover malformed fields at CLI boundary
---------
Signed-off-by: lsr911 <liao.shirong@xydigit.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
