Playwright MCP v0.0.73: How to Configure Browser Paths via Environment Variables

Published: · 4 min read

Playwright MCP v0.0.73 fixes a critical gap where extension channels and executable paths couldn't be resolved from CI/CD environment variables. This release enables true containerized test pipelines—configure browser installations once in your Dockerfile, override per job via environment variables, no hardcoded paths required.

Playwright MCP v0.0.73: How to Configure Browser Paths via Environment Variables

TL;DR

Playwright MCP v0.0.73 fixes a critical gap where extension channels and executable paths couldn't be resolved from CI/CD environment variables. This release enables true containerized test pipelines—configure browser installations once in your Dockerfile, override per job via environment variables, no hardcoded paths required.

The Release

Playwright MCP v0.0.73 shipped two interconnected bug fixes that resolve a pain point I have seen break containerized test pipelines at scale.

The first fix resolves extension channel and executablePath from CLI flags and environment variables (#40572). The second propagates --browser channel flags on the --extension path (#40567). Combined, these changes mean your Playwright MCP setup can now be fully environment-driven—critical for organizations running tests in Docker, Kubernetes, or ephemeral CI workers.

Additionally, the package is now published to the official MCP Registry, which simplifies enterprise procurement and governance for teams evaluating AI-assisted testing infrastructure.

Why This Matters for Engineers and QA

If you are running Playwright in containers, you have probably hit the hardcoded path problem. You install Chromium in your Dockerfile at /usr/bin/chromium-browser, but your CI system runs on macOS runners where the path is /Applications/Chromium.app, and your staging environment uses a custom Brave installation somewhere in /opt/brave. Without environment variable support, you end up maintaining per-environment Dockerfiles, CI configs with conditional logic, or wrapper scripts that fragment your test infrastructure.

This is not a theoretical problem. I have seen teams abandon containerized Playwright testing entirely because the path resolution complexity outweighed the benefits of ephemeral environments. The fix in v0.0.73 closes that gap.

How to Use It

With this release, you can configure browser channels and executable paths through environment variables, making your Playwright MCP configuration portable across environments. Here is the working pattern:

# Set browser channel via environment variable
export PLAYWRIGHT_BROWSERS_CHANNEL=chromium
export PLAYWRIGHT_EXTENSION_PATH=/path/to/browser-extension

# Run your MCP-enabled test suite
npx playwright test

Or in your Node.js test runner:

import { chromium } from '@playwright/test';

async function resolveBrowserConfig() {
  // Environment variables now resolve correctly in v0.0.73
  const channel = process.env.PLAYWRIGHT_BROWSERS_CHANNEL || 'chromium';
  const executablePath = process.env.PLAYWRIGHT_EXECUTABLE_PATH;

  const browser = await chromium.launch({
    channel: channel,
    executablePath: executablePath,
  });

  return browser;
}

For CI/CD pipelines, the pattern becomes environment-agnostic:

# .gitlab-ci.yml example
test:chromium:
  variables:
    PLAYWRIGHT_BROWSERS_CHANNEL: chromium
    PLAYWRIGHT_EXECUTABLE_PATH: ""
  script:
    - npm test

test:brave:
  variables:
    PLAYWRIGHT_BROWSERS_CHANNEL: brave
    PLAYWRIGHT_EXECUTABLE_PATH: "/opt/brave/brave"
  script:
    - npm test

The --browser channel now propagates correctly when --extension paths are specified, meaning parallel test workers can target different browsers without configuration conflicts.

The Gotcha Nobody Is Talking About

Here is the honest gotcha: this fix only works if your environment variables are being read by the Playwright process, not the MCP server subprocess. If you are running Playwright MCP as a standalone server (common in AI-assisted testing setups), environment variables set in your shell may not propagate to the MCP process spawned by your AI tool.

Test this before assuming it works:

# Debug: verify environment is visible to the MCP process
PLAYWRIGHT_BROWSERS_CHANNEL=firefox node -e "
  console.log('Channel:', process.env.PLAYWRIGHT_BROWSERS_CHANNEL);
  console.log('Executable:', process.env.PLAYWRIGHT_EXECUTABLE_PATH);
"

If your AI coding assistant spawns the MCP server, you may need to pass environment variables through the MCP configuration file or your AI tool's environment settings, not just the shell.

What This Changes in Your CI Pipeline

With v0.0.73, you can standardize your Playwright MCP configuration across all environments. The path resolution hierarchy is now:

  1. CLI flags (highest priority)
  2. Environment variables
  3. Config file defaults
  4. Built-in channel defaults

This means your Docker base image can ship with a sensible default browser path, your CI jobs override it via environment variables, and your local development uses the config file. No more per-environment Dockerfile maintenance.

For teams targeting faster deployments, this also removes a class of environment-specific debugging that typically consumes 15-30 minutes per incident. The 50% faster deployment metric I have seen at CooperVision includes eliminating these friction points from CI pipelines.

Verdict

Playwright MCP v0.0.73 is a quiet but significant release for teams running containerized test infrastructure. The MCP Registry publication is nice for enterprise discoverability, but the bug fixes around environment-driven browser resolution are the substantive change. If you are managing Playwright across multiple environments, update now and audit your environment variable configuration to take full advantage of the new resolution order.

The gotcha about subprocess environment propagation is real—test your specific setup before deploying to production. Environment variables that work in your shell may not propagate correctly through MCP server spawns in AI tooling contexts.

https://x.com/aiwithanton/status/2051411902216163582?s=20

For full release details, see the official release notes.

Anton Gulin is an AI QA Architect — the first person to claim this title on LinkedIn. He builds AI-powered test automation systems where AI agents and human engineers collaborate on quality. Former Apple SDET, current Lead Software Engineer in Test at CooperVision. Find him at anton.qa or on LinkedIn.

Playwright · AI · MCP

Subscribe

Get notified when I publish something new, and unsubscribe at any time.

Related articles

Read all my blog posts

·5 min read

browser_run_code_unsafe: The Naming Change That Forces Honest Architecture

Playwright MCP v0.0.72 renamed browser_run_code to browser_run_code_unsafe, making sandbox escape risk explicit. The new browser_network_request tool enables indexed request inspection. Teams using this MCP server in CI pipelines need to update tool references and security documentation now.

browser_run_code_unsafe: The Naming Change That Forces Honest Architecture

·5 min read

Playwright CLI v0.1.10 Brings Spec-Driven Testing Skills for AI Agents

Playwright CLI v0.1.10 introduces a spec-driven testing skill that guides AI agents through plan/generate/heal workflows for maintaining test suites from written specifications. Network inspection now uses stable request indexing, and raw output is default for all data-fetching commands—eliminating preprocessing steps in CI pipelines.

Playwright CLI v0.1.10 Brings Spec-Driven Testing Skills for AI Agents

·3 min read

The MCP Ecosystem Just Collapsed Into Playwright

AI agents made it worse. They still get stuck at login screens. This month, that changed. MCP (how AI talks to tools) is changing how we test. Two teams at Microsoft shipped a fix. They released two ways to share your browser with AI. Playwright core added browser.bind(). The CLI team added an MCP Bridge. Both land in the same month. This is not a test. It is the new way.

The MCP Ecosystem Just Collapsed Into Playwright