[Bug]: MCP createUserDataDir writes profile data to PLAYWRIGHT_BROWSERS_PATH, fails when path is read-only

[Jozef833]

Version

1.59.1 (also present in 1.60.0)

Steps to reproduce

1. Clone https://github.com/Jozef833/playwright-mcp-bug-repro
2. npm install
3. npm run reproduce
4. You should see Error: EACCES: permission denied, mkdir '<PLAYWRIGHT_BROWSERS_PATH>/mcp-chrome-for-testing-<hash>'

Expected behavior

The MCP server should launch a browser and navigate to the requested URL.

Actual behavior

The MCP server fails with:
Error: EACCES: permission denied, mkdir '<PLAYWRIGHT_BROWSERS_PATH>/mcp-chrome-for-testing-<hash>'

Additional context

createUserDataDir creates browser profile directories inside registryDirectory, which resolves to PLAYWRIGHT_BROWSERS_PATH when that env var is set. Without it, registryDirectory defaults to defaultRegistryDirectory ($XDG_CACHE_HOME/ms-playwright or ~/.cache/ms-playwright), which is writable and works correctly.

This means any environment where PLAYWRIGHT_BROWSERS_PATH points to a read-only location will fail: NixOS (immutable Nix store), read-only Docker mounts, shared filesystem browser caches, etc. The nixpkgs playwright-mcp wrapper is one such case.

The only current workaround is PWMCP_PROFILES_DIR_FOR_TEST, which is only referenced in browserFactory.ts and tests/fixtures.ts.

Environment

System:
  OS: Linux 6.6.114.1-microsoft-standard-WSL2, NixOS 26.05 (Yarara)
  CPU: (32) x86_64
Binaries:
  Node: v24.14.1
Packages:
  playwright-core: 1.59.1
  playwright-mcp: 0.0.69 (via nixpkgs)

[dgozman]

@Jozef833 You can pass the --user-data-dir or PLAYWRIGHT_MCP_USER_DATA_DIR manually in the mcp config. See https://github.com/microsoft/playwright-mcp. Please let me know whether this works for you.

[Jozef833]

@Jozef833 You can pass the --user-data-dir or PLAYWRIGHT_MCP_USER_DATA_DIR manually in the mcp config. See https://github.com/microsoft/playwright-mcp. Please let me know whether this works for you.

I just tried this on my machine but it caused playwright mcp servers in different directories (projects) to fight over a lock. Setting the user data dir in this way seems to bypass createUserDataDir entirely, so the per-workspace hashing (mcp-${channel}-${hash(cwd)}) never runs. All projects share one profile directory and collide on SingletonLock. If nixpkgs set this, it would be a regression.

The user data dir needs to use a writeable base path that isn't tied to (overridden by) PLAYWRIGHT_BROWSERS_PATH (indirectly through registryDirectory). Instead, user data dir could be set to defaultRegistryDirectory:

--- a/packages/playwright-core/src/tools/mcp/browserFactory.ts
+++ b/packages/playwright-core/src/tools/mcp/browserFactory.ts
@@ -20,7 +20,7 @@
 import path from 'path';
 
 import * as playwright from '../../..';
-import { registryDirectory } from '../../server/registry/index';
+import { defaultRegistryDirectory } from '../../server/registry/index';
 import { testDebug } from './log';
 import { outputDir } from '../backend/context';
 import { createExtensionBrowser } from './extensionContextFactory';
@@ -174,7 +174,7 @@
 }
 
 async function createUserDataDir(config: FullConfig, clientInfo: ClientInfo) {
-  const dir = process.env.PWMCP_PROFILES_DIR_FOR_TEST ?? registryDirectory;
+  const dir = process.env.PWMCP_PROFILES_DIR_FOR_TEST ?? defaultRegistryDirectory;
   const browserToken = config.browser.launchOptions?.channel ?? config.browser?.browserName;
   // Hesitant putting hundreds of files into the user's workspace, so using it for hashing instead.
   const rootPathToken = createHash(clientInfo.cwd);

This would still cause playwright mcp servers within the same directory to collide on SingletonLock, but that is the default behavior anyways, and --isolated can be used if this is an issue.

For me, --isolated is the solution I need, but I still think this issue is worth resolving since it affects anyone trying to use playwright-mcp from nixpkgs.