Skip to content

Re-evaluate browser_* tools for a click-through install (Playwright bundling overhead) #118

Open

Description

@chaodu-agent

Challenge

The goal is that browser_* tools (DOM-tree level control) work right after a click-through install of the .app.

Today browser_* depends on a separately installed @playwright/mcp (Node + Chromium), reached via --upstream browser=http://127.0.0.1:8794/mcp (poc/pw-mcp, loopback only). This has two problems:

  • Asking users to install and run Playwright, or bundling Node + Chromium inside the .app, has high install, size and maintenance overhead.
  • A double-click (no-flag) launch adds no upstream, so installed users get no browser tools at all.

Both the Chrome-extension route (Muse style) and Playwright are intrusive to some degree.

Wizard plan: add a "Browser tools" page between the permissions page and the tailnet page.

Options considered

Approach Intrusion Capability
Apple Events execute-JavaScript on Chrome and Safari No extension. User enables Chrome "View > Developer > Allow JavaScript from Apple Events" (Safari: Develop menu) plus a one-time macOS Automation consent. Uses the user's real logged-in browser. Can read document.documentElement.outerHTML, query, click and fill. No event subscription, limited cross-frame detail.
Chrome remote debugging opt-in toggle (our survey noted Chrome 144+; version not verified on a real machine) No extension, no separate profile. User enables it at chrome://inspect and confirms a per-connect dialog. Chrome 136+ blocks remote debugging on the default profile otherwise. Full CDP: DOM, a11y tree, network.
Accessibility API web a11y tree (existing ui_snapshot / ui_action) Zero install. Safari exposes the web AX tree by default; Chrome needs renderer accessibility enabled. Semantic tree, not raw DOM (no CSS selectors, no hidden nodes).
Embedded WKWebView in our own window No intrusion on the user's browser. Full DOM control, but no user cookies or logins.
safaridriver / Firefox WebDriver BiDi Standard WebDriver. Needs "Allow remote automation" and a separate automation window. Intrusion close to Playwright. Standard WebDriver / BiDi capabilities.
Chrome extension + native messaging host (Muse approach: Apple Events on Chrome plus an extension relaying over a Unix socket with an auth secret) Works with the real profile, but needs an extension install and a Web Store listing. Full in-page DOM access through the extension.
Playwright (current) Isolated headed Chromium with a persistent profile. Heavy to install or bundle. Full DOM, 32 tools today.

Current leaning (not decided)

This is a leaning, not a decision.

A layered approach:

  • Default tier (zero install): Apple Events JS plus the Accessibility API.
  • Advanced tier (opt-in): Chrome remote debugging.
  • Optional: the extension and Playwright.

Security notes to keep:

  • Owner profile only (the observe profile sees none of this).
  • Playwright stays loopback-only, with no tailnet mapping.
  • No secrets or tokens in logs.

Open questions / next steps

  • Verify the Chrome remote-debugging toggle behaviour on a real Chrome, and find its minimum version.
  • Verify Apple Events JS on current Chrome and Safari, and check what the macOS consent prompts look like.
  • Decide how browser_* tool names map onto the lighter tiers, i.e. which of the 32 Playwright tools can be supported.
  • A design draft already exists at .agents/tasks/browser-tools-install/ (extension-first, under review). It would be revised based on the outcome here.

Activity

  1. added
    enhancementNew feature or request
    p2Priority 2: real bug or scoped planned work
    on Nov 14, 2026
  2. chaodu-agent commented on Nov 14, 2026

    @chaodu-agent
    ContributorAuthor

    Decision update

    Owner decision: we will not build a Chrome extension. The "extension + native messaging host" option is out.

    Decision council result: option 1, the layered approach, with these amendments:

    1. One backend interface. Every browser_* tool sits behind a single internal backend interface. tools/list shows only the tools the active tier supports.
    2. Default tier. Apple Events "execute JavaScript" on Chrome and Safari, plus the existing AX ui_snapshot / ui_action. A wizard page walks the user through the "Allow JavaScript from Apple Events" toggle and the macOS Automation consent, then runs a live probe.
    3. Advanced tier. Chrome remote debugging (CDP) ships only after a spike confirms the minimum Chrome version and its behaviour on a real machine.
    4. Playwright stays optional. It is loopback-only (127.0.0.1:8794, behind --upstream, no tailnet mapping).

    Rationale: no Web Store listing, no publisher account, no bundled Node or Chromium. It matches the zero-install goal. It is reversible and medium risk.

    Next steps

    1. Spike: verify Apple Events JavaScript on current Chrome and Safari, and the consent prompts.
    2. Spike: verify the Chrome remote-debugging opt-in toggle and the minimum version.
    3. Decide which of the Playwright browser_* tool names the Apple Events tier can support.
    4. Design the wizard "Browser tools" page and the backend interface.

    The earlier extension-first design draft in .agents/tasks/browser-tools-install/ is superseded.

  3. chaodu-agent commented on Nov 14, 2026

    @chaodu-agent
    ContributorAuthor

    Spike results and second council decision

    Spike results

    Source: the browser-tools-install spike report.

    Chrome remote debugging (CDP)

    • The chrome://inspect toggle works on the default profile from Chrome 144.
    • Chrome shows an Allow dialog on every connection, plus an automation banner. This makes it attended-only.
    • Chrome 136+ ignores --remote-debugging-port on the default profile.

    Apple Events JavaScript

    • The Chrome View > Developer toggle and the Safari Develop toggle are GUI switches. I found no managed policy for either, but this is unverified.
    • macOS asks for one Automation consent per target browser.
    • Chrome runs the script in the main frame only, in an isolated world.
    • Events are untrusted.
    • A page alert() blocks execution.

    Playwright

    • It needs no human authorization, but it is heavy to install.

    Live testing was skipped because it needs human consent dialogs.

    Still unverified

    • The actual consent prompt text.
    • Whether NSAppleEventsUsageDescription is needed in Info.plist.
    • Whether the CDP Allow choice is remembered.

    Second council decision (option 4)

    Sol and Opus agreed:

    • Apple Events + AX is the default browser_* backend. Its consent is collected once in the install wizard.
    • The wizard also offers an optional one-click, on-demand Playwright install. Nothing is bundled: no Node or Chromium in the .app. It downloads only if the user chooses.
    • CDP stays attended-only.
    • All browser_* tools sit behind one internal backend interface. tools/list shows only what the active tier supports.

    Risk: medium. Reversible.

    Next

    A design workflow covering:

    • the backend interface
    • the wizard "Browser tools" page
    • the on-demand Playwright download flow and its security
  4. chaodu-agent commented on Nov 14, 2026

    @chaodu-agent
    ContributorAuthor

    Clarification: on-demand Playwright install in the wizard

    The wizard gets an OPTIONAL step to install Playwright on demand.

    Nothing is bundled. The .app contains no Node or Chromium. Nothing is downloaded and no files are left on disk unless the user presses the install button.

    If the user presses it, the plan is:

    1. Download Node, @playwright/mcp and Chromium.
    2. Verify the checksum or signature.
    3. Install under ~/Library/Application Support/oab-computer/, never inside the .app.
    4. Start Playwright MCP bound to 127.0.0.1:8794 only, and connect it through --upstream to browser_*.

    This is a design direction, not final.

    Open points handed to the design workflow:

    • Download size shown with progress (likely a few hundred MB).
    • Download sources and verification. This is a supply-chain risk, so an unverified download presented as safe is a blocking finding.
    • Failure paths (offline, interrupted download, Gatekeeper quarantine), each with retry and skip.
    • Update and removal.

    The Apple Events default tier needs no download.

    Unattended use by tier:

    • Playwright needs no human authorization.
    • Apple Events needs the one-time wizard consent.
    • CDP needs a per-connection Allow dialog.
  5. chaodu-agent commented on Nov 14, 2026

    @chaodu-agent
    ContributorAuthor

    Recording owner decisions:

    1. When both the Apple Events and Playwright tiers are ready, Playwright is preferred. Apple Events becomes the fallback, and the choice for tasks that need the user's real logged-in browser.
    2. The wizard's Playwright install step is pre-checked by default; the user can opt out. A normal install therefore downloads a few hundred MB and needs network. The wizard must still complete offline or when the download fails.
    3. Logged-in sites: the user logs in once in the Playwright headed window, and the persistent profile keeps the session. No cookie import.
    4. The Linux installer is tracked in Linux installer: Playwright-based browser_* tier (design later) #119.

    Note: the design draft in .agents/tasks/browser-tiers-design/ assumed nothing is downloaded unless chosen, and Apple Events first. It will be revised.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestp2Priority 2: real bug or scoped planned work

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions