Firefox CDP: How to Connect Playwright and Selenium to Remote Browsers

# Firefox CDP: How to Connect Playwright and Selenium to Remote Browsers

Firefox CDP (Chrome DevTools Protocol) support is a common pain point for teams building browser automation pipelines. While Playwright and Selenium both support Firefox, the protocol-level differences between Firefox and Chromium create confusion when you try to connect to remote instances. This guide explains what Firefox CDP actually supports, how to connect Playwright and Selenium to remote Firefox browsers, and when you should use a hosted browser runtime instead of managing your own infrastructure.

The Firefox CDP Situation in 2026

Firefox does not natively speak Chrome DevTools Protocol. Mozilla maintains its own remote debugging protocol called the Remote Debugging Protocol (RDP), which predates CDP. However, Playwright implements a translation layer that allows you to connect to Firefox via CDP-compatible commands. Selenium has similar support through its WebDriver BiDi implementation.

The practical implication: when you see "Firefox CDP" in documentation, it usually means one of two things:

1. Playwright's `connectOverCDP` method with a Firefox browser instance
2. Selenium's BiDi protocol which provides CDP-like functionality for Firefox

Neither is a drop-in replacement for Chromium CDP. The commands, event payloads, and session management differ enough that you need to test your automation code against the actual browser engine.

Connecting Playwright to Firefox via CDP

Playwright's connectOverCDP method works with both Chromium and Firefox, but the connection string and behavior differ. For Firefox, you need to launch the browser with remote debugging enabled and then connect to it.

Here's a TypeScript example that connects to a remote Firefox instance:

import { chromium } from 'playwright';

// For Firefox, Playwright uses the same connectOverCDP API
// but the browser must be launched with remote debugging enabled
const browser = await chromium.connectOverCDP('http://localhost:9222');

// Get the default context and page
const defaultContext = browser.contexts()[0];
const page = defaultContext.pages()[0];

// Navigate and interact
await page.goto('https://example.com');
await page.fill('input[name="search"]', 'firefox cdp');
await page.click('button[type="submit"]');

// Take a screenshot to verify the session
await page.screenshot({ path: 'firefox-session.png' });

// Don't close the browser - you're connected to a remote instance
// await browser.close();

Key differences when working with Firefox over CDP:

• Context handling: Firefox creates a default context that you must access via browser.contexts()[0]. You cannot create new contexts the same way you do with Chromium.
• Event timing: Firefox's event loop is slower for some CDP commands, especially network interception and DOM mutations.
• Session persistence: Firefox sessions are more sensitive to network interruptions. A dropped WebSocket connection often requires a full browser restart.

Selenium Firefox CDP: WebDriver BiDi

Selenium 4+ uses WebDriver BiDi for Firefox automation. This protocol provides CDP-like capabilities but with a different API surface. If you're migrating from Chrome CDP to Firefox, expect these changes:

The table above shows why "Firefox CDP" is a misnomer. You're not using CDP at all—you're using a different protocol with similar goals.

Production Considerations for Firefox CDP

When you run Firefox automation in production, several issues surface that don't appear in local development:

Memory and Resource Usage

Firefox consumes more memory per tab than Chromium, especially with modern web applications. A typical Firefox session with 5-10 tabs can use 1.5-2GB of RAM. If you're running multiple concurrent sessions, this adds up quickly.

Session Stability

Firefox sessions are less stable than Chromium over long-running WebSocket connections. The browser's garbage collector can pause JavaScript execution, causing CDP commands to time out. You need robust retry logic in your automation code.

Proxy and Network Configuration

Firefox handles proxies differently than Chromium. The --proxy-server flag works, but SOCKS5 support is inconsistent. If your automation requires rotating proxies or residential IPs, test thoroughly with Firefox before committing.

Headless Mode Limitations

Firefox's headless mode (-headless) has fewer features than Chromium's. Some rendering features, particularly WebGL and certain CSS animations, behave differently. This can cause flaky selectors in your tests.

When to Use a Hosted Browser Runtime

Managing Firefox infrastructure for CDP connections is a full-time job. You need to handle:

• Browser version updates and security patches
• Memory leaks and zombie processes
• Network isolation and proxy configuration
• Session persistence across restarts
• Concurrent session management

A hosted browser runtime like Remote Browser solves these problems by providing managed Chromium sessions with CDP access. While the focus is on Chromium, the same infrastructure principles apply to Firefox if you need multi-engine support.

The key advantage of a hosted runtime is session persistence. When you connect to a remote browser via CDP, the session survives network interruptions and cloud worker restarts. This is critical for AI agents that need to maintain state across multiple steps.

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?" This is particularly relevant for Firefox CDP because Firefox sessions are more fragile than Chromium.

The answer lies in separating the browser process from the automation logic. Instead of launching Firefox inside your worker, you connect to a persistent remote browser instance:

1. Launch a browser instance that runs independently of your worker processes
2. Connect via CDP from any worker that needs browser access
3. Maintain the session across worker restarts by keeping the browser process alive
4. Reconnect to the same session using the connection URL

This pattern works with both Playwright and Selenium. The critical piece is that the browser process must be managed separately from your application code.

Browser Use CDP: What It Means for AI Agents

For AI agents that need browser access, CDP provides a clean interface for controlling browser behavior. The browser-use CDP integration shows how to connect AI agents to hosted Chromium instances.

The same principles apply to Firefox, but with additional complexity:

• Tool calling: Firefox's CDP implementation has gaps in accessibility tree support, which affects how AI agents perceive page structure
• Screenshot quality: Firefox screenshots are lower resolution by default; you need to configure deviceScaleFactor explicitly
• DOM serialization: Firefox serializes DOM nodes differently, which can break agent prompts that expect Chromium-style output

If your AI agent uses browser-use or similar frameworks, test with Firefox early. The differences in DOM representation and event handling will affect your agent's success rate.

Playwright connectOverCDP: Firefox vs Chromium

Playwright's connectOverCDP method is the most common way to connect to remote browsers. Here's how Firefox compares to Chromium:

The practical takeaway: if you're building a production system, Chromium is the safer choice for CDP automation. Firefox support is improving, but it's not yet at parity.

Virtual Browser with API: The Production Alternative

A virtual browser with API provides the same CDP functionality without the infrastructure burden. Instead of managing Firefox instances, you get:

• Instant provisioning: Spin up a browser session in milliseconds
• Persistent profiles: Save cookies, localStorage, and session state
• Live debugging: Watch sessions in real-time via a web viewer
• Usage controls: Set timeouts and concurrency limits

This approach is particularly useful for teams that need browser automation but don't want to become browser infrastructure experts.

Automated Browsercore: The Runtime Layer

The concept of "browsercore" refers to the core browser runtime that automation tools connect to. In a hosted environment, this runtime is managed for you:

• Session isolation: Each connection gets its own browser profile
• Resource limits: Memory and CPU are capped per session
• Network controls: Proxy and stealth settings are configurable
• Monitoring: Session health and performance metrics are available

For Firefox CDP specifically, a managed runtime handles the quirks we've discussed—session stability, memory usage, and protocol differences—so your automation code doesn't have to.

Practical Recommendations

Based on our experience with browser automation, here are concrete recommendations for Firefox CDP:

1. Use Chromium for production workloads unless you have a specific requirement for Firefox (e.g., testing Firefox-specific behavior)
2. Test your automation code against both engines if you must support Firefox; the differences are significant enough to cause failures
3. Implement retry logic for CDP commands, especially network operations and DOM queries
4. Monitor memory usage closely; Firefox leaks memory over long sessions
5. Use a hosted runtime if you need persistent sessions or multi-worker support

The Bottom Line on Firefox CDP

Firefox CDP support is functional but not equivalent to Chromium. The protocol differences, session stability issues, and performance characteristics make Firefox a secondary choice for most automation workloads.

If you're building AI agents or browser automation pipelines, start with Chromium and add Firefox support only if you have a specific use case. For production deployments, consider a hosted browser runtime that handles the infrastructure complexity for you.

The Playwright CDP documentation provides the most up-to-date information on connecting to remote browsers. For Firefox-specific details, check the Mozilla Remote Debugging Protocol documentation.

If you're evaluating browser automation infrastructure, start with a simple proof of concept. Connect to a remote browser, run your core automation flows, and measure session stability over time. That data will tell you more than any benchmark or comparison table.