feat: Browser Companion extension for user-browser control + cookie sync hardening

[mrgoonie]

Summary

GoClaw already has a Chrome MV3 extension for Selected Cookie Sync (extensions/chrome-selected-cookie-sync) plus backend storage/injection for scoped browser sessions. This issue proposes a separate but related feature: Browser Companion, where an agent can operate the user's real browser through an explicitly approved extension session, similar in spirit to Claude for Chrome.

This should be designed as a new security model, not as a simple upgrade of cookie sync.

---

Current state found in source

Existing cookie sync pieces:

• Extension: extensions/chrome-selected-cookie-sync/
• Backend API:
  • POST /v1/browser/cookies/sync
  • GET /v1/browser/cookies
  • DELETE /v1/browser/cookies
• Backend files:
  • internal/http/browser_cookies.go
  • internal/http/browser_cookies_payload.go
  • internal/store/browser_cookie_store.go
  • internal/store/pg/browser_cookies.go
  • internal/store/sqlitestore/browser-cookies.go
  • cmd/browser_cookie_provider.go
  • pkg/browser/cookies.go
  • pkg/browser/browser_page.go
  • pkg/browser/browser_tabs.go
• Config:
  • tools.browser.cookie_sync_enabled
  • UI: ui/web/src/pages/config/sections/tools-browser-section.tsx

Current flow:

User Chrome tab -> extension selects cookies -> GoClaw Gateway -> encrypted scoped store -> GoClaw server-side browser session

Desired new flow:

GoClaw agent -> Gateway -> Chrome extension command channel -> user's real active tab/browser

---

Feature proposal: GoClaw Browser Companion

Create a dedicated extension mode that lets a user explicitly share/control their current browser tab with a selected GoClaw agent.

Goals

• Agent can inspect current user browser tab context.
• Agent can perform safe browser actions after user opt-in.
• User keeps control and can stop immediately.
• All actions are scoped, auditable, and permissioned by tenant/user/agent.
• Agent does not need raw cookie values for this mode.

Non-goals for MVP

• Do not control all browser tabs by default.
• Do not run hidden background automation.
• Do not expose raw cookies/session tokens to the LLM.
• Do not use chrome.debugger/CDP in MVP unless explicitly enabled as an advanced mode.
• Do not allow destructive actions without confirmation.

---

Proposed architecture

Agent tool call
  ↓
GoClaw Gateway
  ↓ WebSocket/SSE command channel
Chrome extension background service worker
  ↓
Active tab content script / chrome.scripting
  ↓
User browser page

New tool surface ideas

Potential tool namespace:

• user_browser.status
• user_browser.snapshot
• user_browser.screenshot
• user_browser.navigate
• user_browser.click
• user_browser.type
• user_browser.scroll
• user_browser.press
• user_browser.wait
• user_browser.stop_session

Session model

A session should require explicit user action:

1. User opens extension popup.
2. User selects GoClaw gateway + agent.
3. User clicks Start Browser Companion session.
4. Extension connects to Gateway with a short-lived token/pairing code.
5. Agent can operate only while the session is active.
6. User can click Stop at any time.

Session should be bound to:

• tenant_id
• user_id
• agent_id
• browser extension/device id
• active tab id/origin
• expiration time

---

MVP security constraints

Safe DOM mode first

Use:

• chrome.tabs
• chrome.scripting
• content scripts
• active tab snapshots
• DOM selectors / accessibility-ish element refs

Avoid chrome.debugger / CDP for MVP because it greatly increases browser-control power and store-review/security risk.

Required guardrails

• Explicit user opt-in per control session.
• Active tab/origin only for MVP.
• Visible indicator that GoClaw is controlling the browser.
• Immediate Stop button.
• Domain allowlist/denylist policy.
• Durable activity audit logs for every action.
• Confirmation before risky actions.
• Never expose raw cookies to LLM/tool responses.
• Redact sensitive inputs from snapshots where possible.
• No password/OTP/payment entry without explicit confirmation.

High-risk action confirmation

Require user confirmation for:

• form submit
• purchases/payments
• sending email/message/post
• deleting/updating data
• admin console operations
• entering password/OTP/API keys
• downloading/uploading files

Suggested default denylist categories

• Banking/finance/payment sites
• Password managers
• Identity providers / SSO:
  • accounts.google.com
  • login.microsoftonline.com
  • Okta/Auth0 tenant domains where identifiable
• Cloud/admin consoles:
  • AWS/GCP/Azure production consoles
  • Cloudflare dashboard
  • GitHub org/admin/security pages
• Crypto wallets/exchanges

---

Improvements for existing Selected Cookie Sync

While working on the companion feature, tighten the existing cookie sync feature too.

1. Reconsider default enablement

Currently tools.browser.cookie_sync_enabled defaults to enabled unless set false.

Consider:

• default false for hosted/multi-tenant deployments
• explicit tenant/admin opt-in
• separate UI warning before enabling

2. Short-lived pairing instead of long-lived token in extension

Current extension stores gateway URL/token/userId/agentId in chrome.storage.local.

Improve with:

• short-lived pairing code
• short-lived extension session token
• refresh/revoke flow
• device registration + revocation

3. Cookie management UI

Add UI to view/revoke synced cookie metadata:

• domain
• name
• path
• expires_at
• source
• updated_at
• agent_id
• delete single cookie
• clear by domain
• clear by agent
• clear all

Backend already supports list/delete metadata without returning value.

4. Durable audit logs

Beyond slog, write durable activity records for:

• cookie sync
• cookie delete
• cookie injection into browser session
• failed encryption/misconfig attempts

Audit fields:

• tenant_id
• user_id
• agent_id
• domain/path/name metadata
• source
• target URL for injection
• timestamp
• request/session id

5. Policy layer

Add policy checks before accepting/injecting cookies:

• denylist domains
• allowlist domains
• max TTL override
• high-risk domain warnings
• per-agent cookie access grant

6. UX warnings

Extension should clearly explain:

• cookies are equivalent to login sessions
• only select cookies for sites you trust this agent to access
• do not sync banking/payment/password-manager cookies

7. Extension permissions hardening

Current manifest uses:

"optional_host_permissions": ["<all_urls>"]

Runtime asks for active origin only, which is good. Still consider documenting why <all_urls> is needed or narrowing if possible.

---

Acceptance criteria

Browser Companion MVP

• New extension mode can start/stop a browser companion session explicitly.
• Gateway can register an active extension connection scoped to tenant/user/agent.
• Agent tool can request active tab status/snapshot.
• Agent tool can click/type/scroll/navigate only within active approved tab/origin.
• Risky actions require user confirmation.
• User has visible stop control.
• All actions are audit logged.
• Raw cookies/session tokens are never returned to model/tool output.
• Feature can be disabled globally/tenant-level.

Cookie Sync hardening

• Admin/user UI exists for listing/revoking synced cookie metadata.
• Durable audit logs cover sync/delete/injection.
• Domain policy layer exists.
• Hosted/multi-tenant default is reviewed; consider default false.
• Extension uses short-lived pairing/session token or documents risk of stored token.
• Tests cover scope isolation, policy denial, audit emission, and no value leakage.

---

Notes

This is inspired by the interaction pattern of Claude for Chrome, but should align with GoClaw's product strengths:

• self-hostable
• tenant/user/agent scoped
• auditable
• explicit permission model
• no raw secret exposure to LLM
• safe defaults for multi-tenant deployments