Overview

Lightpanda Browser exposes shared page state through CDP, WebDriver BiDi, MCP, native agent mode, and saved scripts. This chapter compares their command levels, session lifetimes, worker and inbox boundaries, compatibility scope, cancellation, and side effects. CDP and BiDi suit networked clients, MCP packages higher-level intent, agents help explore uncertain paths, and replay makes a discovered workflow more repeatable without making it permanently correct or authorized.

Learning outcomes

CDP and WebDriver BiDi control the same Lightpanda state through different concepts and supported surfaces, not through automatic Chrome equivalence.
MCP and native agent tools reduce protocol assembly, but session routing, node state, cancellation, credentials, and side effects still require explicit control.
Agent exploration and saved replay serve different jobs: replay can improve repeatability, but selectors, page changes, permissions, and browser support remain dependencies.

Keywords

Lightpanda BrowserCDPBiDiMCPAgentReplay

From browser state to automation tools

Lightpanda Browser exposes the same page state through several control surfaces, and this chapter asks which one fits a real automation job. The choice is not a contest between protocol brands. CDP and WebDriver BiDi serve networked automation clients; MCP and native agent mode turn browser state into higher-level tools; saved scripts turn exploration into replay. Comparing their ownership, session, and side-effect boundaries helps you choose deliberately rather than treating every interface as interchangeable.

CDP and BiDi are different views of a networked browser

Chrome DevTools Protocol is the most direct fit when an existing automation client already speaks CDP. Lightpanda’s CDP server accepts a WebSocket connection, creates an inspector-enabled browser, parses commands, dispatches supported domains, and emits events from the same browser notifications that track navigation, frames, network activity, runtime output, and protocol state. A client can ask for DOM or runtime operations, control input, observe network requests, and coordinate page lifecycle events without embedding a second browser.

WebDriver BiDi approaches the same underlying state through a standards-oriented session and browsing-context model. The implementation has session, browser, browsing-context, script, and input modules, with event subscriptions and a WebSocket path. An HTTP-created WebDriver session can outlive one WebSocket link and be connected again later. That lifecycle is useful when a test runner or service separates session creation from the connection that drives it.

The practical difference is not that one protocol sees a “real” browser and the other sees a fake one. Both are control planes over Lightpanda’s browser state. Their concepts, command shapes, event models, and client ecosystems differ. The right choice depends first on the software that must connect and second on the operations that the current Lightpanda surface actually supports.

Lightpanda’s compatibility boundary matters here. The CDP dispatcher exposes a specific set of domains rather than every command available in Chrome, and the BiDi implementation documents a constrained browser/session model. A client that uses common navigation, runtime, DOM, input, or network operations may fit well; a client that assumes every Chrome target type, multi-context pattern, or obscure domain exists may not. “CDP-compatible” or “BiDi-compatible” should therefore mean compatible with the supported surface, not automatically interchangeable with every browser implementation.

That constraint can be an advantage for a focused service because it makes the resource model easier to reason about, but it changes migration work. A test suite that assumes many independent browser contexts, persistent targets, or a particular Chrome-only domain needs an explicit compatibility check before it is moved. The right comparison is between the workflow’s actual commands and Lightpanda’s supported state model, not between protocol names on a feature matrix.

Why the server uses workers and inboxes

A protocol connection is an external event source, but V8 and page state have an ownership thread. Lightpanda’s server separates the socket-facing loop from protocol workers.

Published by DeepMox

FAQ

Are Lightpanda CDP and BiDi implementations interchangeable with Chrome?

No; Lightpanda’s CDP and BiDi implementations expose supported subsets and constrained browser or session models rather than automatic Chrome equivalence. A migration should check the workflow’s actual commands, targets, contexts, and events against the available surface.

What is the difference between Lightpanda MCP and protocol clients?

Lightpanda MCP offers higher-level tools for navigation, extraction, semantic inspection, form actions, waiting, evaluation, screenshots, and session management, while CDP or BiDi clients assemble lower-level commands and events. The higher level still acts on sessions, frames, pages, and side effects.

Why save a Lightpanda script after agent exploration?

Saving a Lightpanda script after agent exploration turns a discovered sequence into a replayable path that does not need model inference at runtime. It can improve repeatability and observability, but it still depends on selectors, page structure, login state, origins, and supported browser behavior.

Previous9 minLightpanda Browser Output Views

Next11 minLightpanda Browser Fit and Limits

Lightpanda Browser Automation Interfaces

From browser state to automation tools

CDP and BiDi are different views of a networked browser

Why the server uses workers and inboxes

FAQ