Playwright security warning: check the browser your AI agent actually runs

If Claude Code, Cursor or another coding assistant uses Playwright to open web pages, check the browser it actually launches. Update that browser, explicitly request Chromium sandboxing where supported, and restart the automation before browsing untrusted content again. Updating your everyday Chrome installation is useful only if the automation uses it.

The security warning circulating on November 3 points to real Chromium vulnerabilities. The right remediation depends on your installed browser and configuration. You do not need to delete Playwright indiscriminately, and a cache cleanup alone does not establish that the problem is fixed.

What was disclosed, and what needs patching?

Google's October 27 Chrome security release delivered version 156.0.8078.73/.74 for Windows and macOS and 156.0.8078.73 for Linux. It included these four critical vulnerabilities:

These records concern the browser engine processing a page. They do not establish a compromise of every Playwright user or a flaw caused by AI-generated application code. They do establish why enabling a sandbox cannot substitute for installing browser fixes.

There is also a newer baseline to consider. Google's October 29 release shipped additional security fixes in 156.0.8078.79/.80 for Windows and macOS and .79 for Linux. Use the current vendor-supported stable update for your platform; do not deliberately stop at .73 because a social post named it.

Why “I updated Playwright” is an incomplete answer

There are several independently versioned components:

A browser manifest identifies a build; it is not an exploit test or a complete inventory of backported patches. The practical requirement is evidence about the distribution you actually execute.

First, identify who launches the browser

Start with the workflow you use: an assistant's MCP server, a project test command, a browser extension connection, or a remote browser service. Record its package version, launch configuration, executable path and running browser version. An unused directory is different from a process currently opening pages.

For a Node project, inspect installed dependencies without changing them:

npm ls playwright playwright-core @playwright/test @playwright/mcp --depth=0

Run this in the project or package that owns the automation. Global tools and MCP servers started through another client can have different dependencies. Ask your assistant to report its configured MCP command and browser selection without displaying environment variables, API keys, cookies or saved login state.

Playwright documents an installed-browser inventory command:

npx --no-install playwright install --list

Use your existing local CLI; if it lacks this option, consult that release's help instead of installing an arbitrary package to make the command work. The inventory is a starting point. Correlate it with launch logs and the version reported by a newly launched session. Check a custom executable path, remote connection or container separately.

For Playwright MCP, make the intended settings explicit

Microsoft's MCP documentation provides integrations for Claude Code and Cursor, along with browser, sandbox and isolated-session options. For an MCP server that launches its own browser, a configuration to review is:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "-y", "@playwright/mcp@0.0.84",
        "--browser", "chrome",
        "--sandbox",
        "--isolated"
      ]
    }
  }
}

This example names the MCP release checked for this article; it is not a promise that the version remains current. Review updates through your normal process. Adapt the configuration format to your client, edit the existing entry, and remove contradictory sandbox-disabling settings. Update installed Chrome before using this configuration.

The MCP configuration source we checked already selects Chrome when no browser name is supplied. It also enables Chromium sandboxing by default on macOS and Windows when no override is supplied; Linux defaults depend on the browser channel. We checked that logic against the published dependency's compiled code. “Every MCP browser has its sandbox off” is therefore too broad.

Explicit settings make the intent easier to audit, but inspect the resulting process. Custom configuration can change the behavior. If you connect through an extension, CDP or another remote endpoint, the browser was launched elsewhere; changing launch flags in this entry does not retroactively reconfigure it.

Restart the MCP server and its browser session after the change. An isolated profile reduces persistent session state; it is not an operating-system sandbox. Microsoft explicitly says MCP itself is not a security boundary.

For project scripts, use the library's launch options

The library has different defaults. Its launch API documents chromiumSandbox as defaulting to false. A project that calls chromium.launch() needs its own review, even if the assistant's MCP configuration is correct.

For a project with Playwright already installed, this is a small verification example using installed Chrome:

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch({
    channel: 'chrome',
    chromiumSandbox: true,
    headless: true
  });
  try {
    console.log('Browser version:', browser.version());
    const page = await browser.newPage();
    await page.goto('about:blank');
    await page.evaluate(() => {
      const button = document.createElement('button');
      button.textContent = 'Check';
      button.onclick = () => { document.title = 'passed'; };
      document.body.append(button);
    });
    await page.getByRole('button', { name: 'Check' }).click();
    if (await page.title() !== 'passed') throw new Error('Interaction failed');
    const cdp = await browser.newBrowserCDPSession();
    const { arguments: argv } = await cdp.send('Browser.getBrowserCommandLine');
    console.log('Executable:', argv[0]);
    console.log('Has --no-sandbox:', argv.includes('--no-sandbox'));
  } finally {
    await browser.close();
  }
})().catch(error => {
  console.error(error);
  process.exitCode = 1;
});

This uses a fresh browser session and a synthetic local page. It avoids signing into real services or opening a suspected exploit. Check the executable and version against the intended update. A successful click confirms basic compatibility; absence of --no-sandbox confirms that flag is absent, not that every sandbox mechanism has been independently audited.

Playwright warns that compatibility with other browser builds is not guaranteed. Test your real application workflows on trusted development pages before rolling a browser change through your project. Where reproducible bundled Chromium is required, use a release whose browser fixes are verified, reinstall its matching binaries, and confirm the resulting version. Reinstalling an unchanged pinned release can simply restore the same older build.

What we tested locally

On one macOS ARM64 machine, we launched installed Chrome 156.0.8078.80 through Playwright with channel: 'chrome' and chromiumSandbox: true. A synthetic button interaction passed, and the browser-reported command line contained neither --no-sandbox nor --disable-setuid-sandbox. We also tested the verification example above against that local installation.

This was a configuration and compatibility smoke test. We did not reproduce any CVE, establish absence of compromise, certify other operating systems, or validate a production browser fleet. We did not delete caches or change existing agent settings as part of the test.

Containers need their own remediation

A container image can carry its own older browser even when the host's Chrome is updated. Rebuild or replace the image, verify the browser inside the new container, and restart the workload.

The official Playwright Docker guide says its image is intended for testing and development and is not recommended for visiting untrusted websites. It also explains that running as root disables Chromium sandboxing, and recommends a separate user and an appropriate seccomp profile for crawling.

Treat a sandbox startup failure as a configuration problem to resolve. Adding --no-sandbox to make the failure disappear removes a protection you were trying to restore. Keep untrusted browsing isolated from production credentials and unnecessary host mounts as an additional operational precaution.

Electron applications are a separate update task

The social post also names Electron. Its 43.8.6, 44.10.1 and 45.2.1 release notes describe upstream backports; 45.2.1 also updates Chromium to 156.0.8078.75.

Those release notes do not prove every installed editor has shipped the fixes, or map every CVE to every older branch. Electron explains that applications ship their own framework components. Update an affected desktop application through its publisher and check that publisher's security guidance. Updating system Chrome does not replace Electron inside an editor. Do not overwrite application binaries or classify every older Chromium version as unpatched without checking branch-specific backports.

Clean up last, and keep evidence of the result

After changing the browser that will run, decide which unused binaries can be removed. Playwright's browser documentation describes version-specific installations, automatic stale-browser removal and uninstall commands. Broad removal can affect other projects; an older pinned tool can download its browser again. Prefer a reviewed inventory and scoped cleanup over an assistant deleting every matching cache directory.

Record the owning tool, package version, executable, browser version, relevant launch settings, restart time and smoke-test result. Repeat for each separate MCP server, project and container. Keep credentials out of that record.

If you observe suspicious activity, pause the affected workflow and investigate separately. Patching changes future exposure; this verification procedure does not determine whether a previous page compromised the machine. A clean app scan cannot answer that workstation question either.

Sources and configurations were checked on November 3, 2026. The original browser fixes date to October 27, followed by the October 29 update. Recheck vendor releases before applying or publishing this guidance.