Self-hosted infrastructure for a fleet of long-lived AI agents. Each agent runs in its own sandboxed container with a persistent workspace, internet access, and a pluggable driver.

Yes. Single-VM deploy on plain Docker with your own keys and data. No vendor lock-in, no per-seat SaaS tax, nothing leaves your stack.

Which agent engines (drivers) are supported?

One identical API across swappable brains: Vanilla, Opencode, Codex, and Claude Code. The driver is part of an agent's config and can be swapped anytime.

How do you keep my data and agents secure?

Every agent runs in a hardened container: read-only root filesystem, dropped capabilities, network egress filtering, and CPU/memory limits. LLM keys are stored server-side, encrypted, and never sent to the browser.

Can I watch what an agent is doing?

Yes. Every task streams over Server-Sent Events (assistant messages, tool calls, results, file changes, a live token meter), and reconnects resume where they left off.

Accounts are provisioned by admins; you self-host the stack. Use Get started, or sign in if you already have an account.

Playwright CLI vs MCP for Claude Code in production

<article> <header> <p>Claude Code can drive a browser in more than one way. That is useful, but it also creates a decision that teams should make deliberately: should the agent use Playwright tests and CLI commands, or should it connect to Playwright MCP and operate through browser tools?</p> <p>The short answer is clear. For production engineering work, default to Playwright tests and the Playwright command line. Use Playwright MCP when Claude needs to investigate a live page interactively, reuse a browser session, or reason over the structure of a page it cannot understand from code alone.</p> </header>

<section> <span id="production-default"></span> <h2>Playwright CLI vs MCP for Claude Code is a production choice</h2> <p>A common workflow starts innocently. A developer asks Claude Code to fix a failing checkout flow. Claude opens the app, clicks through the page, spots a broken selector, changes a component, and says the problem is fixed.</p> <p>That may be enough for a local investigation. It is not enough for a production merge.</p> <p>The question in <strong>Playwright CLI vs MCP for Claude Code</strong> is not which tool feels more impressive in a demo. The question is which tool leaves behind evidence that another engineer, CI job, or release process can trust after the browser session is gone.</p> <p>That distinction matters because Claude Code has limited context, your CI system needs repeatable signals, and browser sessions often contain sensitive state. A tool that is excellent for exploration can be the wrong default for regression coverage.</p> </section>

<section> <span id="three-playwright-surfaces"></span> <h2>There are three Playwright surfaces in this decision</h2> <p>Teams often collapse the conversation into "Playwright". In practice, there are three separate surfaces.</p> <h3>1. Playwright Test and the standard CLI</h3> <p>This is the production testing layer: <code>npx playwright test</code>, project configuration, headed and debug modes, test filters, reporters, traces, screenshots, videos, and CI integration.</p> <p>Claude Code can write these tests, update selectors, run a focused spec, inspect traces, and commit the result. The important part is that the final asset is ordinary code. It can be reviewed, rerun, sharded, reported, and blocked in CI.</p> <h3>2. <code>playwright-cli</code> for coding agents</h3> <p>This is the newer agent-oriented shell interface. It gives coding agents commands for opening pages, clicking elements, taking snapshots, saving screenshots and PDFs, watching console or network output, managing named sessions, saving and loading state, and producing traces or videos.</p> <p>The official Playwright guidance positions it as a strong fit for coding agents because it keeps more work in concise shell commands and files instead of pushing large browser state into the model context.</p> <h3>3. Playwright MCP</h3> <p>Playwright MCP runs as a Model Context Protocol server. Claude Code connects to it and receives browser tools that operate through structured accessibility snapshots. That makes it powerful for live page inspection, form interaction, visible login flows, and long-running browser loops.</p> <p>It also makes MCP part of the team's agent tool surface. Server configuration, scopes, permissions, output size, secrets, and browser profile behavior all become operational concerns.</p>  </section>

<section> <span id="decision-table"></span> <h2>The decision table</h2> <table> <thead> <tr> <th>Use case</th> <th>Best default</th> <th>Reason</th> </tr> </thead> <tbody> <tr> <td>Regression tests before merge</td> <td>Playwright Test CLI</td> <td>Produces versioned specs, reports, traces, screenshots, videos, and CI results.</td> </tr> <tr> <td>Agent probes a page while coding</td> <td><code>playwright-cli</code></td> <td>Keeps the workflow in shell commands and saves artifacts to disk without requiring a full MCP loop.</td> </tr> <tr> <td>Claude must inspect a live UI it cannot infer from code</td> <td>Playwright MCP</td> <td>Accessibility snapshots and persistent page state help the agent reason through the browser interactively.</td> </tr> <tr> <td>Authenticated CI flow</td> <td>Playwright Test with storage state</td> <td>Auth can be generated by setup code and reused in isolated browser contexts. Storage state still needs strict handling.</td> </tr> <tr> <td>Manual login during debugging</td> <td>Playwright MCP or headed <code>playwright-cli</code></td> <td>A visible browser session is convenient when a human needs to complete SSO or inspect an account state.</td> </tr> <tr> <td>Evidence for a pull request</td> <td>Playwright Test CLI</td> <td>Reviewers need stable artifacts after the agent session ends.</td> </tr> </tbody> </table> </section>

<section> <span id="context-cost"></span> <h2>Context cost is not a small detail</h2> <p>Browser automation can flood an agent conversation. Snapshots, console logs, network events, tool schemas, and screenshots all compete with source code, test output, and reasoning space.</p> <p>This is where the CLI default becomes practical. A command can return concise output while saving the heavy evidence as files: a screenshot path, a trace zip, an HTML report, or a test artifact directory. Claude can inspect only what it needs.</p> <p>MCP has improved here. Claude Code can defer MCP tool definitions through tool search, so the full server surface does not have to enter context upfront. But deferred tools do not make browser work free. Once Claude uses Playwright MCP, tool outputs and accessibility snapshots still consume context. Claude Code also warns on large MCP outputs and has a default maximum output size.</p> <p>The operational rule is simple: if the task can be expressed as a command, a test, or an artifact, prefer that. If Claude needs iterative page-structure reasoning, MCP earns its cost.</p>  </section>

<section> <span id="auth-and-session-state"></span> <h2>Authentication changes the risk profile</h2> <p>Authenticated browser automation is where convenience and security start pulling in different directions.</p> <p>For tests, Playwright's authentication model is explicit. You create storage state, usually under a path such as <code>playwright/.auth</code>, and reuse it in browser contexts. The important warning is that storage state can contain cookies and headers that impersonate an account. It should not be committed to the repository.</p> <p>For ad hoc work, MCP and headed CLI sessions can be faster. A developer can log into a visible browser, let Claude continue from that state, and investigate the failing page. Simon Willison's reported experience with Claude Code and Playwright MCP is a useful example of that workflow: manual browser login made authenticated exploration practical for the session.</p> <p>That convenience should stay in its lane. Personal login state does not belong in shared artifacts, committed state files, or unattended CI. For CI, use test accounts and generated storage state. For local debugging, use short-lived sessions and know where the browser profile or state file is stored.</p> </section>

<section> <span id="ci-artifacts"></span> <h2>CI should be owned by Playwright tests</h2> <p>Production confidence comes from evidence that survives the chat. Playwright Test already has the pieces teams need: HTML reports, JSON and JUnit reporters, GitHub annotations, traces, screenshots, videos, output directories, sharding, and report merging.</p> <p>MCP can help Claude discover a bug. <code>playwright-cli</code> can help Claude capture a screenshot or trace while debugging. But the final signal should usually be a Playwright spec that reproduces the behavior and runs through <code>npx playwright test</code>.</p> <p>A good agent-created browser fix should leave behind four things:</p> <ul> <li>The committed Playwright spec or spec update.</li> <li>The command used to verify it.</li> <li>The browser or project target, including any auth account class.</li> <li>Relevant artifacts such as report path, trace path, screenshots, or video when the result needs review.</li> </ul> <p>That evidence bundle is the difference between "Claude clicked through it once" and "the team can trust this in a merge gate".</p>  </section>

<section> <span id="security-controls"></span> <h2>MCP needs explicit permissions</h2> <p>Playwright MCP expands what Claude Code can do. That is the point of MCP, and it is also the reason platform teams should treat it as governed tooling.</p> <p>The Playwright MCP docs include options for allowed hosts, allowed or blocked origins, file-access controls, headless mode, isolated browser contexts, storage state, output directories, session saving, and secrets. Those controls are useful, but the MCP repository also states that Playwright MCP is not a security boundary. Origin filters and local server settings reduce accidental reach. They do not turn an untrusted browser agent into a trusted sandbox.</p> <p>The highest-risk paths are the ones that execute code or inject privileged behavior. <code>browser_run_code_unsafe</code>, <code>playwright-cli run-code</code>, eval-style helpers, init scripts, dynamic headers, and secrets files should sit behind explicit prompts, sandboxing, and review.</p> <p>For governed Claude Code repositories, a sensible baseline is deny-by-default for MCP tools, then allow only the server and tool patterns the workflow needs. Project-scoped <code>.mcp.json</code> should be reviewed like other configuration-as-code, because it changes what agents can connect to and how they authenticate.</p>  </section>

<section> <span id="when-to-use-mcp"></span> <h2>When MCP is the right tool</h2> <p>MCP is not the fallback for teams that have not written tests yet. It is the right tool when the browser session itself is the work.</p> <p>Use Playwright MCP when Claude Code needs to:</p> <ul> <li>Investigate a live page whose behavior is not obvious from the repository.</li> <li>Navigate an authenticated app with a visible browser and human-assisted login.</li> <li>Inspect the accessibility tree to choose elements or understand a dynamic UI.</li> <li>Run a long exploratory loop where persistent browser state matters.</li> <li>Create a first-pass reproduction that will later become a committed Playwright test.</li> </ul> <p>That last point is important. MCP is often the beginning of the workflow, not the end. Once the bug is understood, promote the finding into a spec, artifact, or documented fix.</p> </section>

<section> <span id="production-defaults"></span> <h2>Recommended production defaults</h2> <p>For platform teams, the default stack should be boring on purpose: Playwright Test in the repo, normal CLI commands, trace-on-failure configuration, CI artifact upload, and clear instructions for Claude Code to use tests first.</p> <p>Add <code>playwright-cli</code> as the agent browsing tool when Claude needs to inspect a page, capture a screenshot, save state, or produce a trace during development. It fits the shell workflow and keeps artifacts inspectable.</p> <p>Add Playwright MCP as an explicit mode for exploratory browser control. Keep it local-scoped for individuals unless the team has reviewed the project configuration, versioning approach, permissions, browser profile behavior, and secrets posture.</p> <p>For security teams, the control points are direct:</p> <ul> <li>No committed storage state or personal login artifacts.</li> <li>No broad MCP allow rules in governed repositories.</li> <li>No unchecked code-execution browser tools.</li> <li>Explicit artifact retention rules for screenshots, traces, videos, logs, and state files.</li> <li>Separate policy for local debugging and CI execution.</li> </ul> <p>For engineering leaders, the metric is not whether Claude can click through the app. The metric is whether the workflow reduces time to reproduce defects without increasing flaky tests, hidden credential risk, or unreviewable release evidence.</p> </section>

<section> <span id="final-verdict"></span> <h2>Verdict</h2> <p>The practical answer to <strong>Playwright CLI vs MCP for Claude Code</strong> is a split default.</p> <p>Use Playwright tests and CLI commands for production confidence. Use <code>playwright-cli</code> when Claude needs browser probing that still belongs in a shell-and-artifact workflow. Use Playwright MCP when Claude needs an interactive browser loop with persistent state and page-structure reasoning.</p> <p>That gives each tool a job it is actually good at. Tests protect the release. CLI keeps agent work concise and reviewable. MCP gives Claude a live browser when the page, session, or accessibility tree is the missing context.</p> </section> </article>

Deploy your fleet.