What the Playwright Sandbox Debate Means for Your AI Agent

What the Two Posts Said, Checked Against the Source

At 8:43 AM UTC on November 3, the Spanish security creator Iván Pérez (@IvanPerezF_) warned "vibecoders" that:

• Playwright 1.64.1 uses a Chromium build from before Google's October 27 security update;
• the Chromium sandbox is off by default;
• an agent browsing a crafted page could get to your .env files, SSH keys, and sessions on your laptop.

The post hit more than 100k views and 1000 bookmarks.

Approximately seven hours later, Playwright's official account (@playwrightweb) got back to us. They stated that no Playwright package includes a browser and that MCP and the CLI both run your stable Chrome with the sandbox on. They confirmed that the test runner and library API default to a pinned Chrome for Testing build with the sandbox off (which is fine for "your own trusted app") but not for "the hostile web".

Playwright's answer stands up to the source code and confirms the one thing that actually matters to agent users.

What checks out in the original post:

• The version gap. Playwright 1.64.0 (October 7) and 1.64.1 (October 14) pin Chromium 156.0.8078.4, revision 1248. Chromium rates all four bugs Critical, and all four are fixed in Chrome 156.0.8078.73, released October 27.
• The sandbox detail. Unless chromiumSandbox is true, Playwright launches Chromium with --no-sandbox. Three of the four bugs are described as code execution "inside the sandbox". With the sandbox off, nothing contains them.
• The fix (channel: 'chrome' plus chromiumSandbox: true) is precisely what Playwright recommends.

What needed correcting:

• Playwright isn't a browser at all. It's an automation library, and no package comes with a browser. The test runner will download one for you when you run npx playwright install.
• Coding agents don't ship Playwright. Claude Code, Cursor and Codex don't ship it. You add Playwright MCP, and when you do that, it kicks off your installed Chrome.
• Deleting Playwright doesn't fix anything. The risk is one configuration being used for a job it wasn't designed for.

The timing is also important. When 1.64 shipped on 7th October, its pinned Chromium 156 was in fact ahead of stable Chrome 155 (which Playwright also tested against). That's the whole point of pinning.

The pin fell behind on 27th October when stable 156 came out with those fixes. Every pinned build is going to be behind on security fixes between releases. Playwright 1.65 is in pre-release and will move the pin.

Is Playwright MCP Impacted by the Chrome CVEs?

Agents with their own built-in browser tools aren't covered by this table, so check what yours launches. The question behind every row is the same: whose content does the browser load, and what else can it reach?

Two cases are easily missed.

If you've pinned an @playwright/mcp version prior to 0.0.25 (May 13 2025) then you need to upgrade it. The older versions just launched Chrome without the sandbox.

The other case is dev containers, CI images, and cloud agent sandboxes. These often have a google-chrome that was installed once and never updated, and they often run as root, where the sandbox can't even start. That's how you end up with --no-sandbox.

"MCP uses stable Chrome" just protects you in the case where Chrome is up to date.

Note: Moving your agent's open-web browsing off your laptop? TestMu AI Browser Cloud records video, console logs and network logs for every session, so you can see what a page showed the agent before it acted. Start free, and see Browser Cloud debugging for where each log lives.

How to Enable the Chromium Sandbox in Playwright

Node.js / TypeScript, for untrusted pages

import { chromium } from 'playwright';

const browser = await chromium.launch({
  channel: 'chrome',      // installed Google Chrome, which gets security updates
  chromiumSandbox: true,  // Playwright's default is false
});
const context = await browser.newContext(); // fresh, empty profile

Python, Java, .NET

browser = p.chromium.launch(channel="chrome", chromium_sandbox=True)

Browser browser = playwright.chromium().launch(
    new BrowserType.LaunchOptions().setChannel("chrome").setChromiumSandbox(true));

var browser = await playwright.Chromium.LaunchAsync(new() { Channel = "chrome", ChromiumSandbox = true });

Test runner: keep the pin for your app, and harden external pages

The channel is a use option. chromiumSandbox is a launch option, so it goes in launchOptions.

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    { name: 'app-e2e', use: { ...devices['Desktop Chrome'] } }, // pinned, reproducible
    {
      name: 'external-pages',
      use: {
        ...devices['Desktop Chrome'],
        channel: 'chrome',
        launchOptions: { chromiumSandbox: true },
      },
    },
  ],
});

Playwright MCP: pinned version, in-memory profile, no page-defined tools

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@0.0.84", "--isolated", "--no-webmcp"]
    }
  }
}

--browser chrome is already the default.

0.0.84 was the latest release as of 3rd November 2026.

Pin a version you've reviewed. --no-webmcp is optional (see step 5 below).

On Linux and Docker, the sandbox can't run as root. The Playwright Docker docs actually recommend a separate non-root user and their seccomp profile for untrusted sites.

That's also the historical reason the default is off (it was very difficult to reliably detect sandbox support across CI and containers - issue #4084).

How to Check if Your Agent's Browser Is Exposed

# 1. Playwright version in this project
npx playwright --version

# 2. Downloaded pinned builds (chromium-1248 = 156.0.8078.4, pre-fix)
ls ~/.cache/ms-playwright            # Linux
ls ~/Library/Caches/ms-playwright    # macOS

# 3. Installed Chrome: you want 156.0.8078.73 or later
google-chrome --version                                                   # Linux
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --version  # macOS

# 4. Anything launching on the pinned build or without the sandbox?
grep -rnE 'chromium\.launch\(|--no-sandbox|chromiumSandbox"?: ?false|chromium_sandbox=False|"--browser", ?"chromium"|--browser[= ]chromium' \
  --include='*.ts' --include='*.js' --include='*.mjs' --include='*.py' --include='*.json' --include='*.toml' \
  . ~/.cursor ~/.claude.json ~/.codex ~/.gemini .vscode 2>/dev/null

# 5. While the agent's browser is open: any process without the sandbox? 0 is what you want
ps -ef | grep -E 'chrome|chromium' | grep -c -- '--no-sandbox'

:: Windows (cmd)
dir %USERPROFILE%\AppData\Local\ms-playwright
:: Chrome version: open chrome://settings/help

For a live answer, ask your agent to open chrome://sandbox and read out the result. That will show you the sandbox status of the browser that the agent is actually driving. If step 4 finds a chromium.launch( with no channel, then fix that first.

The two launch modes are easy to tell apart from the arguments Playwright passes to the browser. launchServer() takes the same options as launch() and exposes the spawned process, so this script prints the version, the binary and the sandbox flag for the default launch and the hardened one:

import path from 'node:path';
import { chromium } from 'playwright';

for (const options of [{}, { channel: 'chrome', chromiumSandbox: true }]) {
  const server = await chromium.launchServer(options);
  const args = server.process().spawnargs;
  const browser = await chromium.connect(server.wsEndpoint());
  console.log('options:     ', JSON.stringify(options));
  console.log('version:     ', browser.version());
  console.log('binary:      ', path.basename(args[0]));
  console.log('--no-sandbox:', args.includes('--no-sandbox'));
  await browser.close();
  await server.close();
}

On Playwright 1.64.1, with Google Chrome already updated past the fix, the output looks like this. The default launch picks the pinned, pre-fix build and passes --no-sandbox; the hardened launch picks the patched Chrome and leaves the sandbox on.

options:      {}
version:      156.0.8078.4
binary:       chrome-headless-shell.exe
--no-sandbox: true
options:      {"channel":"chrome","chromiumSandbox":true}
version:      156.0.8078.80
binary:       chrome.exe
--no-sandbox: false

Pin for Tests, Patch for Agents

Playwright's defaults are designed for deterministic end-to-end testing of an app that you own. Pinning keeps every laptop and every CI runner on the same browser.

Google built Chrome for Testing for precisely that use case: no auto-update, and it's only to be used to consume trusted content.

Turning the sandbox off is to avoid container breakage when the content is yours.

AI agents have flipped both of those assumptions without a single config file being touched. The same libraries are now powering browsers that are loading pages that nobody has had any involvement in at all, on machines that have .env files, SSH keys, and logged-in sessions. The agents are also taking instructions from what they've read.

That last point is what the thread missed. The CVEs are the obvious risk, and a patched, sandboxed Chrome addresses that.

Prompt injection is a subtle risk, and you don't need an exploit at all. A page just needs to persuade the agent.

• In August 2025, Brave demonstrated hidden page text that was steering Perplexity's Comet towards account takeover.
• In March 2026, Zenity Labs' PleaseFix research revealed zero-click agent hijacking, including file:// exfiltration.
• In April 2026, Google reported a 32% relative increase in malicious prompt injection detections in Common Crawl between Nov 2025 and Feb 2026.

Sandbox escapes too. CVE-2025-2783 was exploited in the wild in March 2025, and the only thing the victim had to do was click a link.

There are two jobs, and they need different solutions. You can isolate the browser so that a page that is exploiting it ends up in some sandbox with nothing to steal. You can constrain the agent so that a page which is able to talk it into doing something can't get at your secrets or act without your authorisation.

Patching and the sandbox approach deal with the first of those. Permissions, approvals and where the agent actually runs deal with the second.

How to Run Agent Browsing Safely

Job 1: keep a hostile page from owning the machine.

1. Use a patched, sandboxed browser. Run branded Chrome or Edge with the sandbox on, updated and relaunched. On Linux and in containers, update via your package manager or rebuild the image.

2. Run open-web browsing away from your secrets. Use a non-root container with no home directory mounts, a disposable VM or a cloud browser. A browser exploit then lands somewhere with nothing to take.

3. Start each task clean. Use --isolated for MCP or a fresh context for each individual task. Load a logged-in storage state only for the one site you trust to need it, and absolutely don't use your daily Chrome profile.

Job 2: keep a persuasive page from steering the agent. The sandbox can't help here, because the agent reads the page by design.

4. Limit what the agent can reach. An agent on your laptop with shell and file access can be talked into using them. Run open-web agent tasks in a dev container or remote workspace with no SSH keys, .env files, or cloud credentials. Require approval before the agent reads outside the workspace, uses credentials, or sends anything out.

5. Turn off what you don't need. Since 1.64, Playwright MCP has had the agent tools that pages register via WebMCP (as webmcp_<tool>) and marks them as untrusted. A hostile page can now both provide tools and provide text. --no-webmcp turns this off.

--allowed-origins reduces the attack surface, but Playwright notes "it does not serve as a security boundary," so you need to enforce egress at the network level.

6. Pin and review MCP versions. @latest means unreviewed code will run on your next start. Pin a version you've read and ensure it's 0.0.25 or later.

Steps 2 and 4 are the ones where teams invariably get stuck, as "just use a container" becomes a side project. For step 2, we built TestMu AI Browser Cloud. Each session is a real Chrome instance in the cloud, isolated from all others.

Your Playwright, Puppeteer or Selenium code (or your agent) connects to it and then releases it when the task is complete. That's got the browser off your laptop. It doesn't get you to step 4, though.

What the agent is allowed to touch is still your call.

For testing your own app, just carry on with what Playwright recommends i.e., pinned builds and reproducible runs. On the Playwright cloud at TestMu AI, you can pin the browser version to match your local and your CI, and you can pick a specific browser version for each run.

Conclusion

Run the checks above first. If anything launches on the pinned build or with --no-sandbox and visits pages you don't control, move it to channel: 'chrome' with chromiumSandbox: true, and leave your own end-to-end suite on the pinned build.

Then limit what the agent can reach, because a patched, sandboxed browser does nothing against prompt injection.

Giving an AI agent a browser? TestMu AI's Browser Cloud runs each task in a real, isolated Chrome session in the cloud, so the browser stays off your laptop.

To run your first session, start free, or

book a demo

for a full walkthrough of the product.

Sources

• Iván Pérez on X
• Playwright on X
• Chrome Releases, Oct 27, 2026
• Debian security tracker:
  • CVE-2026-118306
  • CVE-2026-118331
  • CVE-2026-118348
  • CVE-2026-118344
• Playwright release notes
• Playwright browsers.json at v1.64.1
• Playwright launch options
• Playwright browsers and cache paths
• Playwright test options
• Playwright Docker
• Playwright agents: network and security
• Playwright MCP
• Playwright CLI
• Playwright issue #4084
• Chrome for Testing
• Brave on Comet
• Zenity Labs, PleaseFix
• Google, prompt injections on the web
• Kaspersky, Operation ForumTroll