Use your daily browser with flexible tab scope.
Best when an Agent should reuse an existing signed-in Chrome or Edge session and the user needs to authorize the current tab or all supported tabs, with active control visible and releasable.
Existing-browser automation · honest comparison
The right approach depends on whether you need an existing login, a clean isolated environment, raw debugging control, or user-facing tab scope. Panerelay is built for the case where the everyday browser should stay yours while an Agent works inside an explicit, visible boundary.
Claims, measurements, and source links reviewed 11 August 2026.
01 · QUICK DECISION
Best when an Agent should reuse an existing signed-in Chrome or Edge session and the user needs to authorize the current tab or all supported tabs, with active control visible and releasable.
Best for isolated profiles, launch-time proxies, remote execution, test repeatability, or scale—especially when reusing the user’s everyday browser is not the goal.
Best for custom integrations that can deliberately expose and secure a debugging endpoint. It is a protocol connection, not a user-facing tab authorization manager.
Best when Playwright MCP is the chosen tool and its native extension flow for selecting a browser tab and approving connections fits the workflow.
02 · COMPARISON MATRIX
“Can it connect?” is only the first question. Scope, approval, visible control, and browser ownership determine whether an approach fits everyday use.
| Approach | Existing logged-in browser | User-facing scope | Connection approval | Visible active control | Browser ownership | Best fit |
|---|---|---|---|---|---|---|
| Panerelay | Yes—reuses the current Chrome or Edge session | Current tab or all supported tabs | Local setup, then explicit browser and tab scope | Dedicated controlled state with Release | Does not own or close the browser process | Daily-browser work across supported automation engines |
| Managed / isolated | Usually a separate or supplied profile | Browser context, profile, or remote session | Tool-specific; not existing-tab authorization | Depends on the tool’s UI | Owns the launched or remote environment | Clean environments, proxies, repeatability, and scale |
| Raw Chrome CDP | Only when intentionally launched or made discoverable | Endpoint and discoverable targets | No built-in end-user tab approval layer | Must be supplied by the integrating tool | You own debugging setup and endpoint security | Debugging and custom low-level integration |
| Playwright Extension | Yes—uses the existing browser state | A user-selected tab at initial interaction | Approval by default; optional token for repeat access | Playwright connection/session state | Does not own the browser process | Playwright MCP with its native selected-tab flow |
“Managed / isolated” covers a category, so exact behavior varies by provider. Raw CDP rows describe protocol-level behavior; tools layered on CDP may add their own policy and UI.
03 · AUTHENTICATED FETCH
Panerelay Fetch and OpenCLI overlap when an Agent needs an HTTP API with browser login state, but they take different execution paths. OpenCLI is the broader tool: it also covers public HTTP, page interaction, interception, and desktop workflows.
Comparison scope. Panerelay Fetch is compared with OpenCLI’s
browser-backed, page-context fetch() path. OpenCLI PUBLIC
commands can use direct HTTP and are intentionally excluded.
| Approach | Request path | Login state | Target-tab dependency | Browser UI | Parallel work | Best fit |
|---|---|---|---|---|---|---|
| Panerelay Fetch | Agent CLI → local Bridge → Extension background fetch | Browser cookies, plus explicit adapter bindings when needed | None—the page can be closed | No CDP attachment or debugging banner | Independent short-lived sessions, bounded by the Extension | Fast API, feed, and data calls with current login state |
| OpenCLI browser-backed | CLI → daemon / Extension → CDP Runtime.evaluate → page fetch | Credentials available to the prepared browser page | Requires a live, addressable page target |
Uses chrome.debugger; Chrome may show its debugging indicator
|
Parallel calls traverse the shared page and CDP command path | Adapters combining requests with page inspection or action |
LOCAL BENCHMARK SNAPSHOT · COMPLETE CLI INVOCATIONS
Measured 11 August 2026 on an Apple M4 Pro with Chrome 151, Panerelay 0.9.0, and OpenCLI 1.8.6. Five warm-ups were discarded; the fixture then ran 30 sequential calls and 10 × 8 concurrent calls against a loopback 1 KiB JSON response protected by a synthetic HttpOnly cookie. The OpenCLI page was prepared before timing. Results are a local snapshot, not a universal product benchmark. Read the method, aggregate results, and limitations.
REAL ADAPTER SNAPSHOT · BILIBILI ME
OpenCLI first prepares and settles a page, then this command makes three page-context API calls. Panerelay uses Extension-background Fetch and caches the navigation data, so it makes two API calls without preparing a target page.
Ten alternating measured invocations after one warm-up, on the same machine, browser profile, and logged-in account; all 20 invocations succeeded. This includes live Bilibili network, page preparation, and adapter implementation differences, so it is an illustrative field snapshot—not a prediction for other sites or strategies. See p95, timing boundaries, source paths, and limitations.
04 · PANERELAY MODEL
Which origins the Extension is eligible to access.
Choose the current tab or all supported tabs. Focus alone grants nothing.
A mutating Agent needs current control, and that controlled state stays visible.
End active control without silently changing the authorization scope you selected.
05 · WHEN NOT TO CHOOSE PANERELAY
Panerelay deliberately does not pretend an Extension-backed connection owns the browser process. Its job is the local routing and policy boundary for explicitly authorized tabs.
06 · SOURCES
OPEN SOURCE · MIT