Playwright connect_over_cdp Firefox Supported Official Docs Guide

# Playwright connect_over_cdp Firefox Supported Official Docs: What You Need to Know

If you've searched for "playwright connect_over_cdp firefox supported official docs," you've likely hit a wall. The Playwright documentation clearly states that connectOverCDP is only supported in Chromium-based browsers. Firefox does not support the Chrome DevTools Protocol (CDP) natively, which means you cannot use playwright.connectOverCDP() to attach to a running Firefox instance. This is a hard limitation, not a configuration issue.

This guide explains exactly what the official docs say, why Firefox is excluded, what your alternatives are for remote Firefox automation, and how to architect a production-grade browser runtime that works across browsers without fighting framework limitations.

The Official Stance: Chromium Only

The Playwright documentation for `browserType.connectOverCDP` is unambiguous. The method signature is:

browserType.connectOverCDP(endpointURL: string, options?: ConnectOverCDPOptions): Promise<Browser>

The critical note in the official docs states that this method is only supported for Chromium-based browsers. Firefox and WebKit are not supported. The reason is architectural: CDP is a protocol developed by Google for Chrome. Firefox uses a different remote debugging protocol (Remote Debugging Protocol, or RDP), and WebKit has its own Web Inspector protocol.

Attempting to call connectOverCDP with a Firefox endpoint will throw an error. The Playwright team has not indicated any plans to add CDP support for Firefox because it would require implementing a Chrome-specific protocol inside Firefox, which is neither practical nor desirable.

Why This Matters for Production Automation

This limitation creates a significant problem for teams that want to standardize on Playwright but need Firefox coverage. Many organizations require Firefox testing for compliance, user-agent diversity, or specific geographic markets where Firefox usage is higher.

The typical workaround—launching Firefox via playwright.firefox.launch()—works for local or same-host scenarios but breaks down when you need:

• Remote execution: Running browsers on separate infrastructure or cloud workers.
• Session persistence: Keeping a browser alive across multiple requests or workers.
• Live debugging: Watching and interacting with a browser session in real time.
• Centralized management: Scaling browser instances without managing individual VMs.

The CDP vs. WebDriver Disconnect

To understand the Firefox gap, you need to understand the protocol landscape:

Playwright's connectOverCDP is a thin wrapper around CDP. Since Firefox doesn't speak CDP, the method cannot work. Playwright does support Firefox through its own driver implementation, but that requires launching the browser via Playwright's binaries, not connecting to an existing instance.

What About playwright.connect()?

If you need to connect to a remote Firefox instance, connectOverCDP is not your only option. Playwright also offers playwright.connect(), which uses the Playwright protocol (a proprietary protocol over WebSocket) rather than CDP.

The key difference:

• `connectOverCDP`: Connects to a browser that is already running and was launched outside of Playwright (e.g., Chrome with --remote-debugging-port=9222).
• `connect()`: Connects to a browser launched by a Playwright server (via playwright-server or a cloud service that exposes the Playwright protocol).

For Firefox, connect() works if the remote endpoint is running a Playwright server that manages the Firefox instance. However, this requires the remote server to have Playwright installed and configured to launch Firefox, which brings you back to infrastructure management.

The Practical Alternative: Hosted Chromium with CDP

Given that Firefox does not support connectOverCDP, most production teams choose one of two paths:

1. Use Chromium for everything: Standardize on Chromium and accept the Firefox gap.
2. Use a browser runtime service: Delegate browser management to a hosted service that handles protocol translation, session persistence, and scaling.

The second option is increasingly popular for AI agents and automation workloads because it removes the infrastructure burden entirely. Services like Remote Browser provide hosted Chromium instances that are accessible via CDP, Playwright, Puppeteer, and Selenium.

How Remote Browser Solves the Firefox Problem

Remote Browser does not claim to make Firefox work with connectOverCDP. Instead, it solves the underlying problem: giving you reliable, scalable browser access without managing local infrastructure.

Here is how it works:

1. Hosted Chromium: Remote Browser provisions Chromium instances in the cloud. Each instance is isolated, has a persistent profile option, and is accessible via a secure WebSocket endpoint.
2. CDP Compatibility: Because the instances are Chromium-based, playwright.connectOverCDP() works exactly as documented. You get the full CDP feature set without running a local Chrome process.
3. Session Persistence: Browser sessions stay alive across multiple cloud workers. You can start a session, perform some actions, disconnect, and reconnect later without losing state.
4. Live Debugging: A live viewer lets you watch the browser in real time, which is invaluable for debugging AI agent behavior or complex automation flows.

For teams that genuinely need Firefox, the recommendation is to run Firefox locally or on dedicated infrastructure using Playwright's native Firefox support. For everyone else, hosted Chromium via CDP is the more practical path.

Code Example: Connecting to a Remote Browser with connectOverCDP

Here is a TypeScript example that connects to a Remote Browser instance using playwright.connectOverCDP. This pattern works for any CDP-compatible endpoint, including locally launched Chrome with remote debugging enabled.

import { chromium } from 'playwright';

async function connectToRemoteBrowser() {
  // The WebSocket endpoint from your Remote Browser session
  const cdpEndpoint = 'wss://remote-browser.dev/cdp/your-session-id';

  // Connect to the existing browser via CDP
  const browser = await chromium.connectOverCDP(cdpEndpoint);

  // Get the default context or create a new one
  const context = browser.contexts()[0] || await browser.newContext();

  // Use the page as you normally would
  const page = await context.newPage();
  await page.goto('https://example.com');
  await page.fill('input[name="q"]', 'playwright connectOverCDP');
  await page.click('button[type="submit"]');

  // Wait for navigation and extract data
  await page.waitForLoadState('networkidle');
  const title = await page.title();
  console.log(`Page title: ${title}`);

  // Keep the session alive for other workers
  // Do NOT close the browser if you need persistent state
  // await browser.close();
}

connectToRemoteBrowser().catch(console.error);

Notice the comment about not closing the browser. With connectOverCDP, closing the browser connection does not necessarily terminate the underlying browser process. This is a key advantage for multi-worker workflows where you need to maintain state across requests.

Keeping Browser Sessions Alive Across Cloud Workers

One of the most common questions we hear is: *"How do I keep browser sessions alive across multiple cloud workers?"*

The answer depends on your architecture:

For serverless or ephemeral workers (AWS Lambda, Cloudflare Workers, etc.), a local browser is often impossible or impractical. The browser process is too heavy and the execution environment is too short-lived. A central browser server or hosted runtime is the only viable option.

Remote Browser's hosted sessions are designed for this exact use case. Each session runs on dedicated infrastructure and remains accessible as long as the session is active. Multiple workers can connect to the same session via CDP, enabling patterns like:

• Multi-step workflows: Worker A performs step 1 and disconnects. Worker B connects, verifies state, and performs step 2.
• Human-in-the-loop approval: An AI agent navigates to a checkout page, then a human reviews and approves via the live viewer before the agent submits.
• Long-running scraping: A session stays logged in to a target site for hours or days, rotating through tasks without re-authenticating.

Scaling Playwright Browser Workloads Reliably

Scaling browser automation is hard because browsers are resource-hungry. A single Chromium instance can consume 500MB to 1GB of RAM, and CPU usage spikes during page rendering and JavaScript execution.

When you run browsers locally, scaling means adding more machines or containers. Each machine needs Playwright installed, browser binaries downloaded, and system dependencies configured. This is manageable for a few instances but becomes a maintenance nightmare at scale.

Hosted browser runtimes solve this by abstracting the browser lifecycle. You request a session, get a CDP endpoint, and connect. The service handles:

• Resource allocation: Matching browser instances to available CPU and memory.
• Session isolation: Ensuring one workload cannot interfere with another.
• Proxy and network configuration: Routing traffic through specific IPs or geographies.
• Usage controls: Setting timeouts, concurrent session limits, and spending caps.

For AI agents that need browser access in production, this abstraction is critical. The agent should focus on task completion, not on managing browser processes.

Giving Your AI Agent Browser Access in Production

AI agents that interact with the web need a reliable browser interface. The naive approach—launching a browser on the same machine as the agent—works for prototypes but fails in production for several reasons:

1. Resource contention: The agent's LLM inference and the browser compete for CPU and memory.
2. Session volatility: If the agent crashes or restarts, the browser session is lost.
3. Security: Giving an agent local browser access creates a vector for prompt injection or malicious site interactions.
4. Concurrency: Multiple agent instances need isolated browser sessions, which is hard to manage locally.

A hosted browser runtime addresses all four issues. The agent connects to a remote session via CDP, performs its tasks, and disconnects. The session persists independently of the agent's lifecycle.

For example, an AI agent that monitors competitor pricing might:

1. Connect to a persistent browser session.
2. Navigate to a competitor's pricing page.
3. Extract the data.
4. Disconnect.

If the agent needs to check again in an hour, it reconnects to the same session, which may still be logged in and have cookies intact. This is far more efficient than launching a fresh browser each time.

Selenium and Playwright: A Note on Compatibility

While this article focuses on Playwright, the same CDP limitation applies to Selenium. Selenium's WebDriver protocol is different from CDP, and Selenium 4 supports CDP for Chromium-based browsers through the DevTools interface. Firefox uses GeckoDriver, which implements the WebDriver protocol but not CDP.

If you are migrating from Selenium to Playwright, or using both in the same codebase, the connectOverCDP pattern is consistent for Chromium. For Firefox, you must use the native driver approach in both frameworks.

Resource Usage: Headless vs. Headful

A common misconception is that headless browsers use significantly fewer resources than headful browsers. While headless mode does reduce overhead (no rendering to screen), the difference is smaller than most people expect. The browser still needs to parse HTML, execute JavaScript, and maintain a DOM.

For production workloads, the more important factor is session management. A browser that stays alive across multiple tasks is more efficient than launching and tearing down a browser for each task. The startup cost of Chromium is typically 1-3 seconds, which adds up over thousands of tasks.

Remote Browser sessions are designed to be long-lived. You pay for browser time, not per task, which incentivizes efficient session reuse. See our pricing page for current rates and session limits.

The Bottom Line on Firefox and connectOverCDP

To summarize the official docs and practical implications:

1. `connectOverCDP` is Chromium-only. Firefox and WebKit are not supported, and this will not change.
2. For Firefox automation, use Playwright's native launch or connect() with a Playwright server.
3. For production scale, hosted Chromium via CDP is the most reliable path. It gives you the full Playwright API without infrastructure management.
4. Session persistence is the key differentiator. Keeping a browser alive across workers enables complex workflows that are impossible with per-task browser launches.

If you are building AI agents or large-scale browser automation, the question is not whether to use connectOverCDP with Firefox—it's whether to manage your own browser infrastructure at all. Hosted runtimes like Remote Browser eliminate the operational overhead and let you focus on your core product.

For a deeper dive into how remote browsers work in practice, see our guides on remote browser online and remote web browser. If you are evaluating whether to build or buy your browser infrastructure, our comparison of remote control browser options provides a useful framework.

The Playwright documentation is clear: Firefox does not support connectOverCDP. Plan accordingly, and choose a runtime that works with the protocol, not against it.