Skip to content

PATTERN Cited by 1 source

CDP proxy for headless browser

CDP proxy for headless browser is the pattern of standing up a local Chrome DevTools Protocol endpoint inside an agent / application / sandbox that forwards CDP frames through an out-of-environment proxy to a managed headless- browser service — so an unmodified agent that was written against a locally-running Chromium can instead drive a managed remote browser, with no application-level rewrites.

Why CDP specifically

CDP is the de-facto protocol for Chromium-based browser automation (Puppeteer, Playwright, Stagehand, Playwright MCP all speak it). The protocol layer is the one surface every agent ecosystem already speaks, so keeping the agent's connection at CDP and swapping what sits behind it is the lowest-disruption integration point:

Agent ──(local CDP port)──▶ thin CDP proxy ──(network)──▶ managed browser service
                                      (e.g. Puppeteer HTTP API)

Variants

  • Sandbox-internal proxy + external relay. The proxy runs inside the agent's container/sandbox on localhost; an outer middleware layer (typically a Worker or gateway) authenticates to the managed browser service. Moltworker does this.
  • Inject a skill to redirect the agent. When the agent doesn't auto-discover the local CDP port, inject a small adapter/"skill" into the agent's runtime at startup that points CDP methods at the proxy.

Why this is a pattern, not a library

The value isn't the proxy code (typically a few hundred lines). The value is the shape: agent stays unchanged, platform service stays generic, integration is a localhost port + one skill file. The same shape applies to any protocol-native managed service (SSH, databases, Redis, object storage) — see patterns/protocol-compatible-drop-in-proxy for the general case; CDP proxy is the pattern specialised to the headless-browser category.

Seen in

Last updated · 200 distilled / 1,178 read